readathon-database-safety
Warn and protect against dangerous database operations on production database in the readathon project
When & Why to Use This Skill
This Claude skill implements a robust safety protocol for database management, specifically designed to prevent accidental data loss or corruption in production environments. It acts as an intelligent guardrail by monitoring SQL operations, identifying active databases, and enforcing mandatory confirmation steps for destructive actions like DELETE, DROP, or TRUNCATE on live datasets, ensuring high data integrity and operational security.
Use Cases
- Preventing accidental data deletion: Automatically intercepts and requires explicit 'yes' confirmation before executing destructive commands like DELETE, DROP TABLE, or TRUNCATE on the production database.
- Production environment awareness: Detects when the agent is connected to the live 'readathon_2025.db' and issues a high-visibility warning detailing the potential impact on real student records.
- Safe development guidance: Proactively suggests using a sample database for testing and experimentation to avoid any risk to the production environment.
- Registry protection: Safeguards the central registry database from unintended modifications that could disrupt the entire application's database catalog and statistics.
- Script execution safety: Blocks the execution of high-risk scripts like 'clear_all_data.py' unless the user provides explicit, informed consent.
| name | Readathon Database Safety |
|---|---|
| description | Warn and protect against dangerous database operations on production database in the readathon project |
Readathon Database Safety
TRIGGER: Before any database modification operation (INSERT, UPDATE, DELETE, DROP, TRUNCATE, or running clear_all_data.py)
Database Safety Protocol
1. Identify Current Database
Check which database is currently active:
# Check config file
grep -E "(active_db|database)" .readathon_config 2>/dev/null
# Or query registry
sqlite3 db/readathon_registry.db "SELECT filename, display_name FROM Database_Registry WHERE is_active = 1;"
2. Production Database Warning
If operating on production database (readathon_2025.db):
⚠️ WARNING: Operating on PRODUCTION database!
Database: readathon_2025.db (2025 Read-a-Thon)
Operation: [describe what's about to happen]
Impact: [estimated number of records affected]
Data: Real student data (411 students)
This operation will modify ACTUAL read-a-thon data.
Confirm operation on PRODUCTION database? (yes/no)
User must explicitly type "yes" to proceed.
3. Destructive Operation Protection
BLOCK these operations without explicit confirmation:
python3 clear_all_data.py(wipes all contest data)DELETE FROMqueries (removes records)DROP TABLE(destroys table structure)TRUNCATE(empties tables)UPDATEwithout WHERE clause (affects all records)
Require user to:
- Confirm they understand the impact
- Confirm they want to proceed
- Consider if backup exists
4. Sample Database Recommendation
For development and testing, always suggest:
python3 app.py --db sample
Benefits:
- Safe to experiment with fictitious data
- No risk to real student information
- Easily reset without consequences
- Yellow/amber banner provides visual reminder
5. Registry Database Protection
Extra caution for registry database (readathon_registry.db):
⚠️ REGISTRY DATABASE: This tracks ALL contest databases!
Modifying registry affects:
- Database catalog
- Active database selection
- Summary statistics
- Database availability
Proceed with registry modification? (yes/no)
Architecture Context
From CLAUDE.md:
- Registry Database:
db/readathon_registry.db(central catalog) - Production Database:
db/readathon_2025.db(real contest data) - Sample Database:
db/readathon_sample.db(safe for testing)
Default Behavior
- ✅ READ operations: Allow on any database
- ⚠️ WRITE operations on production: Warn and ask
- ❌ DESTRUCTIVE operations: Block and require explicit confirmation
- ✅ Operations on sample: Allow (safe environment)
When to Skip Warnings
Skip warnings only if:
- User explicitly said "use production database"
- Operation is clearly intended for production (e.g., "update production contest data")
- User has confirmed in same conversation
Otherwise, ALWAYS warn before production modifications.