runbook — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited runbook (Agent Skill) and scored it 96/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 1 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 1 flagged
The text {match} tells the agent to skip the normal "ask the user first" gate. Used adversarially it removes the human-in-the-loop check before destructive or sensitive actions, turning a normally-gated agent into a fire-and-forget executor.
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
You are in AUTONOMOUS MODE. Do NOT ask questions. Analyze the project's infrastructure and operations artifacts to produce a comprehensive runbook.
INPUT: $ARGUMENTS
Accepted arguments:
deployment: focus on deployment procedures only.incident: focus on incident response procedures only.database: focus on database maintenance procedures only.troubleshooting: focus on troubleshooting guides only.============================================================ PHASE 1: INFRASTRUCTURE DISCOVERY ============================================================
Step 1.1 -- Deployment Configuration
Scan for deployment artifacts:
| Type | Files to Check |
|---|---|
| Docker | Dockerfile, docker-compose.yml, docker-compose.*.yml |
| Kubernetes | k8s/, kubernetes/, manifests/, *.yaml with apiVersion: |
| Helm | Chart.yaml, values.yaml, templates/ |
| Terraform | *.tf, terraform/, infrastructure/ |
| Serverless | serverless.yml, SAM template.yaml |
| PaaS | Procfile, fly.toml, vercel.json, netlify.toml, app.yaml |
| PM2 | ecosystem.config.js |
Step 1.2 -- CI/CD Pipeline
Scan for: .github/workflows/*.yml, .gitlab-ci.yml, Jenkinsfile, .circleci/config.yml, bitbucket-pipelines.yml, cloudbuild.yaml, azure-pipelines.yml.
Read each pipeline file and extract build steps, deployment targets, environment variables, secrets referenced, and branch triggers.
Step 1.3 -- Database Configuration
Scan for: migration files (migrations/, prisma/migrations/, alembic/, db/migrate/), schema files (schema.prisma, models.py, *.entity.ts), seed files, database config (database.yml, knexfile.js), and backup scripts.
Step 1.4 -- Monitoring and Observability
Scan for: logging config (winston, pino, log4j), APM (newrelic, datadog, elastic-apm), metrics (prometheus, grafana), error tracking (sentry, bugsnag, rollbar), health check endpoints, and alerting rules.
Step 1.5 -- Environment Configuration
Scan for: .env.example, environment-specific configs, feature flags, and secrets management (vault, AWS SSM, sealed secrets).
============================================================ PHASE 2: RUNBOOK GENERATION ============================================================
Generate docs/runbook.md with these sections. Only include sections relevant to detected infrastructure. Every procedure must have copy-pasteable commands.
The runbook MUST cover these areas (skip if not applicable to project):
post-deploy verification checklist (health check, logs, smoke test, metrics).
full rollback with database revert if needed, verification checklist.
common diagnostic queries (table sizes, active connections, slow queries).
incident checklist (acknowledge, communicate, investigate, mitigate, resolve, postmortem), first-response diagnostic commands for logs, status, and resources.
guide (high CPU, memory, error rate, disk, health check failures with actions).
performance degradation) with step-by-step diagnosis. Error-to-solution lookup table.
Format: use markdown headers, numbered steps with fenced bash blocks for commands, checklists for verification, and tables for reference data.
If a runbook already exists, read it first and preserve manually-written sections.
============================================================ PHASE 3: VALIDATE AND WRITE ============================================================
For each command in the runbook:
Write the runbook to docs/runbook.md.
============================================================ SELF-HEALING VALIDATION (max 2 iterations) ============================================================
After producing documentation, validate completeness:
IF VALIDATION FAILS:
============================================================ OUTPUT ============================================================
docs/runbook.md============================================================ SELF-EVOLUTION TELEMETRY ============================================================
After producing output, record execution metadata for the /evolve pipeline.
Check if a project memory directory exists:
~/.claude/projects/skill-telemetry.md in that memory directoryEntry format:
### /runbook — {{YYYY-MM-DD}}
- Outcome: {{SUCCESS | PARTIAL | FAILED}}
- Self-healed: {{yes — what was healed | no}}
- Iterations used: {{N}} / {{N max}}
- Bottleneck: {{phase that struggled or "none"}}
- Suggestion: {{one-line improvement idea for /evolve, or "none"}}Only log if the memory directory exists. Skip silently if not found. Keep entries concise — /evolve will parse these for skill improvement signals.
============================================================ DO NOT ============================================================
(e.g., a library or CLI tool). Report that no runbook is needed and suggest /readme.
NEXT STEPS:
After generating the runbook:
/document to check overall documentation health."/diagram to generate infrastructure diagrams."/devops to review and improve the deployment pipeline."~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.