Troubleshoot database/infra errors, compose commands/scripts, write runbook tutorials, capacity planning for DBA, SysOps, DevOps. Covers PostgreSQL, MongoDB, MySQL, ClickHouse, Apache Kafka, RabbitMQ, Linux log management, cron, logrotate. Uses MCP connectors (context7, deepwiki, ClickHouse Docs) for up-to-date official docs. Command and Script output is caveman-compressed (telegraphic prose, byte-exact code); Tutorial and Plan stay full prose. Trigger whenever the user mentions DBA, SysOps, DevOps, or infrastructure — error diagnosis, shell commands/scripts, cron expressions, log rotation, capacity estimation, migration planning, access/auth troubleshooting, or any operational database/infrastructure task. Also trigger on pasted database errors, stack traces, or log snippets. Trigger phrases: "compose a tutorial", "write a runbook", "fix this cron", "how to restore/enable", "compose a command/script", topic sizing, retention, partitions, replication, cluster planning.
83
91%
Does it follow best practices?
Impact
80%
1.12xAverage score across 2 eval scenarios
Advisory
Suggest reviewing before use
The operations team runs a nightly MongoDB cleanup job that trims old entries from a logs collection. After migrating to a new Linux server running cronie, the job started behaving erratically — sometimes deleting all records, sometimes nothing — even though the command ran fine when tested manually at the terminal. The sysadmin suspects the crontab entry itself is broken.
Current crontab entry:
0 2 * * * mongosh --eval "db.logs.deleteMany({ts: {$lt: new Date(date +%Y-%m-%d)}})" >> /var/log/mongo-cleanup.log 2>&1Compose a command: produce a fixed, complete crontab line the sysadmin can drop directly into crontab -e. The job must run at 2 AM every night against the logs collection on the local MongoDB instance, deleting documents where the ts field is before today's date.
Save the corrected crontab entry to fixed-crontab.txt.