菜单
Serialized DevOps audit using 15 deep framework subskills. Each framework runs in its own agent context with expert-level depth. Smart interview pre-fills from conversation context.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Keep a live interactive chat session coming back to itself, visibly, after a usage/session cap interrupts it, never a silent background process. Invoke with /qq-cap-resume, or say “keep this session alive,” “resume yourself after the cap,” “don’t go dark on me,” any time a long interactive burn needs to survive a 5-hour session cap or ride out to a weekly reset without leaving you staring at a dead thread.
The unbounded end of the AFK spectrum: spend whatever it takes for quality, budget isn’t the constraint. Stand up a self-healing, fully-autonomous “kitchen-sink max-effort” campaign for a big multi-day initiative: resilience first, creative meta strategy, workflows spawning workflows, audit-gated quality, a phone-glanceable status surface with a proud wins list, and a long living tasklist. Invoke when you say “go HAM”, “go-ham”, “go afk ham”, “qq-go-afk-ham”, “kitchen sink”, “blow me away”, “use all the quota”, or hand it a large ambitious build to run autonomously for hours or days. For the frugal end, use `qq-go-afk-lean`; for the adaptive middle, use `qq-go-afk-smart`.
The adaptive middle of the AFK spectrum: picks the right model task by task, moment by moment, instead of committing to either extreme. Stand up a calm, self-healing, fully-autonomous overnight worker for a well-scoped punch list: the top-tier model writes strict specs and does quality control, cheap and free models do the grunt work, one bounded task per cycle, each one deployed and live-verified, a phone-glanceable status surface, and a durable done log. Invoke when you say “go afk smart”, “go-afk-smart”, “qq-go-afk-smart”, “go smart”, “bounded overnight”, “delegate and verify overnight”, or hand it a finite, well-specified backlog (a punch list, a rollout, a sweep) to grind down autonomously while you sleep, without the kitchen-sink fan-out of go HAM. For the unbounded end, use `qq-go-afk-ham`; for the frugal end, use `qq-go-afk-lean`.
The moment a real, avoidable mistake happens, name it plainly, root-cause the general class of it rather than just this one instance, and fix it at a level that prevents a repeat, not a note that gets written and forgotten. Then, before starting work that looks like it could repeat that shape, check the log first. A second occurrence of the same mistake means the note wasn’t enough, and it needs to become a real check instead of a reminder. Invoke with /ww-mistake-ledger, or say “log this mistake,” “close the loop on this,” “add this to the mistake log,” “check the mistake log first,” right after a preventable error, or right before starting work that resembles one already logged.
Ask what would make this fail before you build it, not after. A one-question design-time gate, imagine it’s already broken three months from now, work backward to the most likely cause, and let the answer change the plan instead of just getting noted and ignored. Works on code, an automation, a process, or a decision. Invoke with /ww-premortem, or say “what breaks this in three months,” “pre-mortem this,” “why would this fail,” “before I build this,” at the moment you’re about to commit to an approach, not after you’ve already started.
Before filling a gap in what you know with a guess, check whether the guess is load-bearing. If getting it wrong would mean redoing real work, or building on a false premise, ask a real question with concrete options instead of assuming silently. If it’s genuinely low-stakes, state the assumption out loud and keep moving rather than stalling on it. Works on any ambiguous request, with or without an AI agent involved. Invoke with /ww-questioning, or say “wait, let me ask first,” “is this load-bearing,” “check before I guess,” “clarify before building,” whenever a request has more than one reasonable reading and you’re about to just pick one.
| name | qq-audit-devops |
| description | Serialized DevOps audit using 15 deep framework subskills. Each framework runs in its own agent context with expert-level depth. Smart interview pre-fills from conversation context. |
| version | 3.0.0 |
| triggers | ["devops audit","infrastructure audit","deployment audit","ops review","12 factor","run devops audit"] |
Part of Claude Code operator skills: a collection of skills for running a real Claude Code setup.
Audit DevOps by running 15 expert personas in serial, fixing critical issues per framework before verifying.
15 DevOps frameworks, each loaded as a deep expert persona into its own agent context. Serial execution: one framework → fix critical issues → verify → next. Each agent thinks like a 20-year specialist in that specific framework.
Expert lens: Is it deployable, operable, and resilient?
Supersedes: ad-hoc infrastructure reviews, one-off uptime checks.
This skill responds to three modes based on the args passed. Interpret intent loosely, using fuzzy matching, not exact phrasing.
Triggers: /qq-audit-devops, "run all", "full audit", "everything", no args at all.
Triggers: /qq-audit-devops 12-factor, "just run monitoring on the production stack", "check CI/CD pipeline", etc.
Match the framework name fuzzily: "12 factor", "twelve factor", "12factor" should all match 12-Factor App. "ci", "cicd", "pipeline", "github actions" should all match CI/CD Pipeline Maturity. If ambiguous, show the 2-3 closest matches and ask.
Triggers: "list", "what do you have", "what frameworks", "help", "which ones", "show me", etc.
Show the framework table from the framework inventory below, then ask which one(s) to run.
DO NOT ask dumb questions. Before asking anything, gather what you already know:
Pre-fill and present assumptions:
"Here’s what I know going in:
- Product: [name], [description from context]
- Hosting: [Vercel / AWS / GCP / self-hosted, inferred from project]
- CI/CD: [GitHub Actions / CircleCI / none, inferred from config files]
- Known ops concerns: [what the user has mentioned or what recent incidents suggest]
- Scope: [full infrastructure / specific service / specific pipeline]
Anything wrong or missing?"
Use AskUserQuestion with multiple choice ONLY for genuine gaps. For example, if you truly can’t tell what the hosting platform is, ask. If you can infer it, state the inference.
Interview output becomes the audit context: passed to every framework agent so they audit with purpose, not generically.
For each framework (in order 1-15):
Spawn one agent with these instructions:
~/.agents/skills/qq-audit-devops/frameworks/[NN-name].md"Collect the agent’s output:
Verify build if fixes were applied (rebuild container, re-run pipeline, etc.)
Update cumulative state:
Move to next framework
Save to project’s data directory:
data/audit-devops-[date].md: full reportdata/audit-devops-[date]-summary.md: scores + critical findings only| # | Framework | Expert lens | Subskill file |
|---|---|---|---|
| 1 | 12-Factor App | Application architecture fundamentals: does this app follow the patterns that make deployment, scaling, and maintenance predictable? | 01-twelve-factor.md |
| 2 | Infrastructure as Code | Infrastructure reproducibility: is every piece of infrastructure version-controlled, reviewable, and rebuildable from scratch? | 02-iac-audit.md |
| 3 | CI/CD Pipeline Maturity | Deployment pipeline health: are you shipping frequently, reliably, and with confidence that nothing is broken? | 03-cicd-maturity.md |
| 4 | Deployment Strategy | Release mechanics: can you ship to production with zero downtime, instant rollback, and controlled blast radius? | 04-deployment-strategy.md |
| 5 | Monitoring and Alerting Coverage | Operational visibility: do you know when something is broken before your users tell you, and does the alert tell you what to do about it? | 05-monitoring-alerting.md |
| 6 | Incident Response Readiness | Incident management: when production breaks at 3 AM, does the team know who responds, what to do, and how to communicate? | 06-incident-response.md |
| 7 | Backup and Disaster Recovery | Data protection and recovery: if you lost everything right now, how long until you’re back, and how much data is gone? | 07-backup-disaster-recovery.md |
| 8 | Log Aggregation and Search | Centralized logging: can you find the needle in the haystack when debugging a production issue at 3 AM? | 08-log-aggregation.md |
| 9 | Container/Runtime Health | Container hygiene: are your containers minimal, secure, health-checked, and resource-bounded? | 09-container-health.md |
| 10 | Secret Rotation and Management | Credential hygiene: can you rotate every secret in your system without downtime or redeployment? | 10-secret-rotation.md |
| 11 | Cost Optimization/Resource Efficiency | Cloud spend hygiene: are resources right-sized, unused resources cleaned up, and cost allocation visible to the teams that control it? | 11-cost-optimization.md |
| 12 | Observability Depth | Diagnostic capability: when something breaks, can you answer "why?" from your telemetry alone, without guessing or adding instrumentation? | 12-observability-depth.md |
| 13 | DNS and Domain Management | Name resolution reliability: are your DNS records correct, redundant, monitored, and managed as code? | 13-dns-management.md |
| 14 | SSL/TLS Configuration | Transport security: are connections encrypted with modern protocols, valid certificates, and secure defaults? | 14-tls-configuration.md |
| 15 | Dependency Update Cadence | Dependency freshness: are third-party libraries kept current, vulnerabilities patched promptly, and update costs kept low through regular small increments? | 15-dependency-update-cadence.md |