Use when working in infrastructure repos (Terraform, Helm, CI/CD). Replaces test-driven-development with infrastructure-appropriate verification. Use instead of TDD for any .tf, .yaml.tpl, or infrastructure-as-code work.
Infrastructure code doesn't have unit tests. Verification means: does terraform validate pass, does terraform plan show only expected changes, and does the security posture hold?
This skill replaces test-driven-development for infrastructure repos.
All other Superpowers skills (brainstorming, writing-plans, subagent-driven-development, verification-before-completion, code review) still apply unchanged.
Always when:
Never when:
digraph sre_pipeline {
rankdir=TB;
scope [label="1. Scope & Plan\n(scope-refine)", shape=box];
adr [label="2. Check ADRs\nadr/ directory", shape=box];
execute [label="3. Execute\n(superpowers:subagent-driven-development)", shape=box];
security [label="5. Security Review", shape=box, style=filled, fillcolor="#ffcccc"];
review [label="6. Code Review\n(superpowers:requesting-code-review)", shape=box];
update [label="7. Update Codebase Map\nif interfaces changed", shape=box];
finish [label="8. Finish Branch", shape=box];
brainstorm -> adr -> plan -> execute -> security -> review -> update -> finish;
}
Before planning, read adr/ in the repo root.
adr/0000-template.md)Use the scope-refine skill for combined scoping and planning. Check adr/ before planning — do existing ADRs constrain this work? If a new architectural decision is needed, write the ADR as part of the plan.
Before writing any code:
~/.claude/hooks/bd-create-from-plan.sh <scope-doc-path> (or bd create manually)bd readyChoose execution mode:
Parallel (default for independent tasks): Use the execute-plan skill. It dispatches one agent per ready issue in isolated worktrees. Each agent runs the infrastructure verification cycle (validate → plan → format) instead of TDD.
Sequential (for tightly coupled tasks): Claim the first ready task (bd update <id> --claim), then run the infrastructure verification cycle below. One task at a time.
Manual verification tasks: Some infra tasks need apply + manual validation (check AWS console, verify connectivity, test DNS). Agents implement and commit, but the human verifies after apply.
After each task — CHECKPOINT (mandatory):
git diff --stat, plan output summary, brief summary of what was donebd close <id> and check bd ready for what's unblocked nextThis replaces the TDD Red-Green-Refactor cycle. For each task:
terraform validate
Confirm: no syntax errors, no missing variables, no provider issues.
Fails? Fix the error. Re-validate. Don't proceed until clean.
terraform plan
Confirm:
Unexpected changes? Investigate before proceeding. Never ignore plan output.
terraform fmt -check
Should pass automatically (PostToolUse hook runs terraform fmt on save). If not, run terraform fmt and re-check.
After validate + plan + format are clean, commit following the conventions in ~/.claude/CLAUDE.md (Commit Conventions section). Use $STACK_TOOL commands from ~/.config/claude/workflow.env if stacking.
Before requesting code review, check:
| Check | What to Look For |
|---|---|
| IAM least privilege | No * in resource ARNs, no Action: "*", policies scoped to specific resources |
| No secrets in code | No hardcoded passwords, keys, or tokens. All secrets via Secrets Manager / SSM |
| Encryption | Storage encrypted at rest (RDS, S3, EBS). TLS in transit where applicable |
| Security groups | No 0.0.0.0/0 ingress on sensitive ports. Egress restricted where possible |
| Network exposure | No unintended public endpoints. VPC Link for internal services |
| IRSA over node IAM | Pod-level permissions via IRSA, not broad node group policies |
Found an issue? Fix it before code review. Don't defer security fixes.
When using superpowers:writing-plans, use this task structure instead of the TDD red-green-refactor steps:
### Task N: [Component Name]
**Files:**
- Create: `terraform/modules/foo/main.tf`
- Modify: `terraform/environments/dev/foo.tf`
**Step 1: Write the Terraform code**
```hcl
resource "aws_example" "this" {
name = var.name
# ...
}
```
**Step 2: Validate**
Run: `terraform validate`
Expected: Success with no errors
**Step 3: Plan**
Run: `terraform plan`
Expected: 1 to add, 0 to change, 0 to destroy (adjust per task)
**Step 4: Commit**
Follow commit conventions from `~/.claude/CLAUDE.md`.
If this work changed a module's interface (added/removed/renamed variables, changed outputs):
~/.claude/projects/<project-path>/CLAUDE.mdSkip if: Only internal changes (no interface change).
| Excuse | Reality |
|---|---|
| "Plan is clean, no need to run it" | Plan output IS the verification. Always run it. |
| "It's just a variable change" | Variable changes can cascade. Plan shows the blast radius. |
| "Security review is overkill for this" | Every IAM change, every security group change gets reviewed. No exceptions. |
| "I'll update the codebase map later" | You won't. Do it now while context is fresh. |
| "terraform validate passed, that's enough" | Validate checks syntax. Plan checks behavior. Both required. |
| "The ADR is obvious, no need to write it" | If you're making an architectural choice, write it down. |
Before marking work complete:
terraform validate passesterraform plan shows only expected changesterraform fmt -check passes* ARNs)~/.claude/CLAUDE.md| Skill | Status |
|---|---|
| brainstorming | Use as-is — design before code |
| writing-plans | Use with modified task structure — see above |
| subagent-driven-development | Use as-is — subagent per task, but verification = validate + plan (not tests) |
| verification-before-completion | Use as-is — evidence before claims |
| test-driven-development | REPLACED by this skill — do not use for infrastructure code |
| requesting-code-review | Use as-is — after security review |
| finishing-a-development-branch | Use as-is — but use $STACK_SUBMIT_CMD from workflow.env if available |