Help Center/DevOps Workflow

DevOps & IaC Workflow

The composed infrastructure workflow with Incident Fast Path, Blast Radius assessment, IaC-adapted quality gates, environment promotion, rollback checks, and production deployment.

New to Silver Bullet? Use /silver <anything> as your workflow composer — it reads your intent, classifies the task, and routes to the right SB, GSD, and plugin path.

How the DevOps Workflow Differs From Dev

The DevOps workflow follows the same overall structure as the software engineering workflow, but with three important additions:

  • Incident Fast Path — An emergency shortcut for active production incidents
  • Blast Radius assessment — Required before planning any infra change (replaces the application-level quality gate as the first gate)
  • Environment Promotion — After all phases complete in dev, the workflow must be re-run for staging, then again for production

The per-phase loop order also differs: Discuss → Blast Radius → DevOps Quality Gates → Plan → Execute → Verify → Code Review.

YAML and JSON files are infrastructure code here — not trivial changes. GitHub Actions workflows, Kubernetes manifests, Helm charts, Terraform files, and CI/CD pipeline definitions MUST follow the full DevOps workflow regardless of file extension. The trivial-change exemption that applies to .yml in the dev workflow does NOT apply here.

Step 0 — Session Mode

Every session starts with a mode selection before any project work begins. This is identical to the dev workflow.

0
Session mode selection

Interactive (default) — pauses at every phase gate for your approval. Autonomous — drives start-to-finish, logs decisions, surfaces only genuine blockers at end. Written to ~/.claude/.silver-bullet/mode. If unreadable, defaults to interactive.

Incident Fast Path

Use only when responding to an active production incident requiring an emergency change. Skip this section entirely for planned DevOps work.

Fast path criteria: Active incident with confirmed production impact AND the change cannot wait for the full cycle without extending the outage. Both conditions must be true.

Fast Path Steps

  1. Create or update the incident response runbook — Establish severity classification, timeline, communication protocol, and rollback trigger criteria before any changes.
  2. Document the incident — What is broken, what the proposed change is, expected outcome.
  3. Run /silver:blast-radius — Required even in incidents. A rushed unreviewed change can make incidents worse. If CRITICAL blast radius, escalate to CAB before proceeding.
  4. Apply the minimal change in the lowest affected environment first, verify, then promote.
  5. Create a post-incident review task — Full cycle review of the emergency change after the incident resolves, including /devops-quality-gates retroactively.
  6. Commit with [HOTFIX] prefix and reference the incident ticket.

Project Initialization

Runs once per project. Skip if .planning/PROJECT.md already exists.

1
Worktree decision

Strongly recommended for DevOps changes that touch production resources. A worktree isolates your IaC changes from the main branch until they're ready to apply.

2
/gsd:new-projectGSD

For DevOps projects, the roadmap phases typically map to infrastructure layers. GSD will ask about target environments, IaC toolchain, state backend, naming conventions, and tagging strategy.

→ Typical phase order: networking → storage → compute → monitoring → CI/CD

Per-Phase Loop

Repeat Steps 3–13 for each phase. Use /gsd:next to confirm which phase is current.

Phase: Discuss
3
/gsd:discuss-phaseGSDRequired

Captures implementation decisions for this infra phase. DevOps-specific topics to cover:

  • Target environments (dev / staging / prod) and promotion strategy
  • IaC toolchain (Terraform, Pulumi, CDK, Helm, raw manifests)
  • State backend and locking strategy
  • Naming conventions and tagging strategy
→ Produces: .planning/{phase}-CONTEXT.md

If a matching DevOps plugin skill exists for the IaC toolchain discussed (e.g., HashiCorp's terraform-code-generation for Terraform work, kubernetes-operations for k8s), it can be invoked here for best-practice guidance that feeds into quality gates. This is optional enrichment, not a gate.

Phase: Blast Radius
4
/silver:blast-radiusDevOpsRequired

Maps change scope, downstream dependencies, failure scenarios, rollback plan, and change window risk. Produces a rating that gates whether the phase can proceed.

→ Produces: blast radius rating + rollback plan
Low
Proceed normally
Medium
Proceed normally
High
User approval + runbook required
Critical
HARD STOP — CAB review required
Phase: DevOps Quality Gates
5
/devops-quality-gatesDevOpsRequired

Applies 7 IaC-adapted quality dimensions against the infrastructure design, excluding usability and AI/LLM safety when they do not apply. Same base framework as /silver:quality-gates, adapted for infrastructure: idempotency, least-privilege IAM, drift prevention, and infra reliability. All 7 dimensions must pass. is a hard stop.

Phase: Plan
6
/gsd:plan-phaseGSDRequired

Both the blast radius report and the quality gate report feed into the plan as hard requirements. For IaC phases, the wave order follows dependency direction:

  • Wave 1Networking and IAM — no dependencies on other new resources
  • Wave 2Storage and data — depends on networking/IAM
  • Wave 3Compute and services — depends on networking + storage
  • Wave 4Monitoring and alerting — depends on compute
  • Wave 5CI/CD pipeline updates — depends on all above
→ Produces: .planning/{phase}-RESEARCH.md, .planning/{phase}-{N}-PLAN.md

Skill gap check (post-plan): After the plan is written, cross-reference all installed skills against the plan content. Flag any skill covering a concern not explicitly in the plan.

Phase: Execute
7
/gsd:execute-phaseGSDRequired

Wave-based parallel execution. Each wave applies to the lowest environment only (dev or equivalent). Higher environments (staging, production) are promoted in the Environment Promotion section (steps 14–15) after all phases complete. TDD is explicitly skipped for IaC execution. Use plan output, policy checks, validation commands, secrets/IAM review, drift detection, and rollback verification instead of red-green-refactor. Commit atomically per task.

→ Produces: atomic git commits (one per task), .planning/{phase}-{N}-SUMMARY.md
Phase: Verify
8
/gsd:verify-workGSDRequired

Infrastructure verification — not UAT. For DevOps phases, verify:

  • Health checks passing on all new/modified resources
  • No configuration drift (plan shows no changes after apply)
  • Monitoring and alerting firing correctly
  • Rollback procedure tested in lower environment
  • Runbook updated to reflect actual applied state
→ Produces: .planning/{phase}-VERIFICATION.md

If step 8 fails: invoke /silver:forensics before retrying. If root cause is implementation: re-run steps 7–8 only. If root cause is design/plan: return to step 3 (discuss).

Phase: Code Review
9
/requesting-code-reviewSB helperRequired

Frames IaC review scope and dispatches superpowers:code-reviewer only when the active SB workflow selects that helper discipline. This helper does not replace GSD's authoritative code-review artifact.

10
/gsd:code-reviewGSDRequired

Produces the authoritative REVIEW.md through GSD reviewer agents. For IaC: hardcoded values that should be variables, missing tags/labels, overly permissive security groups, resources missing encryption, backups, or monitoring. Plan output is reviewed, not just source files.

11
/receiving-code-reviewSB helperRequired

Triage all feedback. Accepted items become the input for post-review execution (Steps 12–13).

12
/gsd:plan-phaseGSDConditional

Plan to address accepted review items. Only runs if items were accepted in Step 11.

13
/gsd:execute-phaseGSDConditional

Implement the review-driven plan with atomic commits. Only runs if items were accepted in Step 11.

Environment Promotion

Runs after all phases complete in the lowest environment. Repeat for each tier: dev → staging → production.

Never skip staging. Infrastructure changes must be verified in staging before production. Monitoring verification and rollback testing are mandatory before the production promotion step.
14
Promote to next environment

Re-run /gsd:execute-phase targeting the next environment using environment-specific tfvars or values files. Never rewrite infrastructure definitions — only the inputs change between environments.

15
Verify promoted environment

Re-run /gsd:verify-work for the promoted environment. Health checks, drift detection, and monitoring verification are mandatory before promoting to production.

Finalization

Runs once after all phases complete in all environments.

16
/testing-strategyRequired

Define the IaC verification strategy: module validation, policy-as-code, plan/apply review, smoke checks, drift detection cadence, rollback checks, and environment promotion evidence.

17
/tech-debt Required

Invoke /tech-debt to identify, categorize, and prioritize infrastructure technical debt. Appends structured items to docs/tech-debt.md. Format: | Item | Severity | Effort | Phase introduced |

18
/documentationRequired

Update documentation according to the SB doc scheme: README, docs/ARCHITECTURE.md, docs/TESTING.md, docs/internal/CICD.md or runbook docs when relevant, docs/CHANGELOG.md, monthly docs/knowledge/YYYY-MM.md and docs/lessons/YYYY-MM.md entries, task doc checklist, and the session log.

19
/finishing-a-development-branchRequired

Branch rebase, cleanup, and merge preparation. Same as the app workflow Step 16.

CI/CD + Deployment

Infrastructure pipeline rule: Infra pipelines must enforce plan → review → apply. Never auto-apply to production. Plan output must be stored as a pipeline artifact for audit.
20
CI/CD pipelineRequired

CI must be green before deploying. Check with gh run list --limit 1 --json status,conclusion. In Autonomous mode, polls every 30 seconds up to 10 minutes. If CI is red: fix, re-push, re-check. Do not proceed to Step 21 while CI is failing.

21
/deploy-checklistRequired

Pre-deployment verification gate with DevOps-specific additions:

  • Blast radius assessment reviewed and approved
  • Rollback procedure tested in staging
  • On-call engineer notified and available
  • Change window confirmed (off-peak unless incident)
  • Monitoring dashboards open and baselining
22
Production apply

Execute plan in production. Apply one resource group at a time if blast radius is HIGH. Monitor dashboards during apply and for 15 minutes after completion.

Ship + Release

23
/gsd:shipGSDRequired

Creates the pull request. For DevOps work, the PR body includes phase summaries, blast radius ratings, requirement coverage, and post-apply drift detection results.

→ Produces: pull request with blast radius ratings and infra coverage
24
/silver:releaseRequired

Runs the milestone-level release workflow for publishable infrastructure work: release quality gates, audits, documentation, fresh tests, gsd:ship, gsd:complete-milestone, then /silver:create-release as the final tag/release step.

→ Produces: completed milestone, git tag, GitHub Release, structured release notes

Review Loop Enforcement Rule

Every review loop in the workflow (spec review, plan review, code review, verification) must iterate until the reviewer returns Approved TWICE IN A ROW. A single clean pass is not sufficient.

  • Never stop because issues look minor or "close enough"
  • Never count a loop as done unless the reviewer outputs Approved on two consecutive passes
  • The loop is self-limiting — it ends naturally when two consecutive passes are clean
  • Surface to the user only if the reviewer raises an issue it cannot resolve
← Previous Dev Workflow Next → Command Reference