paqad-ai
Version:
Spec-driven development framework — AI agents that think before they type
43 lines (30 loc) • 2.07 kB
Markdown
verified: 2026-10-31
Fires when the request touches: config, env vars, secrets, build, CI, deploy, infra, scheduled jobs, feature flags.
- New configuration and its defaults, per environment.
- The flag and rollout plan for the change.
- The rollback path, and whether data changes make rollback unsafe.
- CI and checks impact: what new gate or job the change adds.
- Runtime dependencies added, and where they come from.
- Logs, metrics, and alerts for the new behaviour.
- Migration versus deploy ordering, so the two do not race.
- One config key and its default in one environment.
- The feature flag guarding the change.
- The rollback step, and whether it is safe.
- One metric or alert for the new behaviour.
- The order of one migration against one deploy.
- What new configuration does this need, and what are the defaults per environment?
- Is this behind a flag, and what is the rollout plan?
- Can we roll this back, or does the data change make that unsafe?
- What logs, metrics, or alerts tell us this is working?
- Does the migration run before or after the deploy?
See `runtime/capabilities/coding/agents/devops-engineer.md`, the review persona this lens is the request-time version of. This lens does not repeat its steps. The skill `rollback-safety-planner` works the rollback question when the data change looks risky.
- Read the `
- Never invent a synonym. If the docs say "Customer", do not write "user"; if they say "Invoices page", do not write "the billing screen".
- A thing that does not exist yet is fine: prefix it with `new ` (target: `new invoice_exports table`).
- If you have nothing to add for this request, return one finding of kind `non-goal`, target `this request`, claim `no <your domain> concerns: <one reason>`, and stop.