infra-ops
Skill1 starsChanged 7 months agoMITView on GitHub
Manages infrastructure, monitoring, backups, and incident response. Triggers ONLY when: user asks to set up monitoring, plan backup strategy, handle an incident, or review infrastructure security. Do NOT trigger during normal development.
2 other projects use a version of this.
Adopted by
Most recently taken up by
- liutaos/ops-skillstheir own version, first seen Sep 22, 2026
- abdullah1854/ClaudeSuperSkillstheir own version, first seen Dec 25, 2025
Other versions2 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 2
- abdullah1854/ClaudeSuperSkills★ 1same name
- liutaos/ops-skills★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository30 other files it gives its agents.
- claude.mdCLAUDE.md
- biz-thinkSkill
- biz-validateSkill
- brand-buildSkill
- community-engageSkill
- content-createSkill
- content-distributeSkill
- copy-craftSkill
- data-decideSkill
- finance-opsSkill
- growth-trackSkill
- issue-createSkill
- legal-guardSkill
- post-mergeSkill
- pre-codeSkill
- pre-commitSkill
- pre-prSkill
- product-evalSkill
- project-initSkill
- retroSkill
- roadmap-steerSkill
- sales-closeSkill
- search-evalSkill
- self-reviewSkill
- sopSkill
- staging-verifySkill
- support-opsSkill
- test-gateSkill
- ux-auditSkill
- work-breakdownSkill
The file
We split this skill into the rules it gives an agent
4 rules. About 0 are common, 4 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 49
Not deploying: check platform dashboard and CI/CD logs
- Distinctive: line 64
Critical: test restore monthly. A backup you've never restored is not a backup — it's a hope.
- Distinctive: line 70
Follow the NIST framework adapted for solo/small teams:
- Distinctive: line 126
Test the full DR plan quarterly — actually do a restore drill
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Infra-Ops SOP
1. Monitoring
Set up monitoring BEFORE you need it. Three layers, in priority order:
Uptime monitoring (must-have day 1):
- UptimeRobot (free, checks every 5 min) or BetterStack
- Monitor: main app URL, API health endpoint, database connectivity
- Alert chain: Slack/email for P1-P3 → phone call for P0
Error tracking (must-have day 1):
- Sentry free tier — captures stack traces with user context
- Set up source maps for frontend, proper error grouping
- Alert on new error types, not every occurrence
Performance baselines (set up by launch):
- Track p50/p95/p99 response times for key endpoints
- Set alerts when p95 > 2x baseline for 5+ minutes
- Database query time monitoring (slow query log)
Source: CloudEagle SaaS Security Checklist, DesignRevision SaaS Security Checklist
2. Staging/Preview Environments
Staging environments are required for the automated release gate (staging-verify). The dev branch must auto-deploy to a preview URL.
Platform Configuration:
| Platform | How to Enable Dev Preview | Stable Branch URL Pattern |
| Vercel | Automatic for all branches via Git Integration | <project>-git-dev-<scope>.vercel.app |
| Netlify | Site settings → Branch deploys → add dev | dev--<site-name>.netlify.app |
| Railway | Create environment per branch | Custom domain per environment |
| Render | Dashboard → Preview Environments | <service>-dev.onrender.com |
| Fly.io | Separate fly.staging.toml config | Custom staging subdomain |
Staging must have:
- Same monitoring as production (uptime checks, error tracking)
- Isolated data (separate database, separate API keys)
- Separate secrets from production
Troubleshooting:
- Not deploying: check platform dashboard and CI/CD logs
- URL returning 404: verify the build succeeded on the platform
- Out of date: compare deployed commit with
git rev-parse dev
3. Backup Strategy — 3-2-1 Rule
3 copies, 2 different media, 1 offsite. Non-negotiable.
| Data type | Backup method | Frequency | Retention |
| Database | Automated pg_dump / mysqldump to object storage | Daily | 30 days rolling + weekly for 90 days |
| User uploads | Replicated cloud storage (e.g., S3 cross-region) | Real-time replication | Match user data retention policy |
| Code | Git (already distributed) | Every push | Indefinite |
| Config/secrets | Encrypted export to separate secure store | On change | Last 10 versions |
Critical: test restore monthly. A backup you've never restored is not a backup — it's a hope.
Source: Cohesity — 3-2-1 Backup Rule, Rewind — 3-2-1 for SaaS
4. Incident Response
Follow the NIST framework adapted for solo/small teams:
Severity levels:
- P0 — Service down, all users affected → drop everything, fix now
- P1 — Major feature broken, many users affected → fix within 4 hours
- P2 — Minor feature broken, workaround exists → fix within 24 hours
- P3 — Cosmetic/low-impact issue → fix in next sprint
Response playbook:
- Detect — monitoring alert fires or user reports
- Triage — assign severity (P0-P3), estimate blast radius
- Communicate — update status page within 15 min for P0/P1
- Template: "We're aware of [issue]. Impact: [who's affected]. ETA: [time or 'investigating']."
- Fix — contain first (rollback, feature flag off), then root-cause fix
- Post-mortem (required for P0/P1, within 48 hours):
- What happened (timeline)
- Why it happened (root cause, not blame)
- How to prevent it (concrete action items with owners and deadlines)
Source: TechTarget — Incident Response Plan, Sygnia — SaaS Incident Response
5. Security Checklist
Transport & access:
- HTTPS everywhere (no mixed content, HSTS enabled)
- Secrets in env vars or secret manager — NEVER in code or git
- MFA for admin accounts and cloud provider console
- CORS configured to allow only your domains
Application:
- Rate limiting on auth endpoints (login, signup, password reset)
- CSP (Content Security Policy) headers configured
- Input validation and parameterized queries (prevent SQLi/XSS)
- Dependency audit weekly (
npm audit/pip audit/cargo audit)
Infrastructure:
- Minimal open ports — only 80/443 publicly accessible
- Database not publicly accessible (VPC/private network only)
- Automated security updates for OS packages
- Logging enabled for all access and auth events
6. Disaster Recovery
Define targets early, revisit quarterly:
- RTO (Recovery Time Objective): max acceptable downtime. Solo SaaS target: < 4 hours.
- RPO (Recovery Point Objective): max acceptable data loss. Solo SaaS target: < 24 hours (daily backups).
DR plan essentials:
- Documented runbook: "if X dies, do Y" for each critical component
- Database: can restore from backup to new instance in < 2 hours
- App server: infrastructure-as-code so you can spin up a new one in < 1 hour
- DNS: low TTL (300s) so failover propagates fast
- Test the full DR plan quarterly — actually do a restore drill
Source: ATOZDEBUG — Disaster Recovery for SaaS, MightyID — Optimizing RPO & RTO
7. Maintenance Schedule
| Frequency | Task |
| Weekly | Check error logs and alert trends, run dependency audit, review uptime reports |
| Monthly | Test backup restore, review access logs, update dependencies, check infrastructure costs |
| Quarterly | Full security audit, DR drill (test restore to new environment), review RTO/RPO targets, infrastructure cost optimization |
| Annually | Rotate all credentials/API keys, review and update incident response plan, evaluate monitoring stack |
Next Steps
Report to user: "Infrastructure: [what was set up/fixed]. Status: [healthy/issues]"
Suggested next steps (user decides):
- Monitoring done → "Resume development"
- Incident occurred → "Run data-decide for impact analysis"
- Security audit done → "Run legal-guard"
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.