Menu
Designs implementation-grounded architecture, sequence, and flow diagrams from existing code and documentation. Ensures notation is chosen intentionally, avoids invented components or flows, and explicitly flags mismatches across ADRs, RFCs, and code.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Structures, writes, and reviews Terraform infrastructure code. Covers module layout, remote state, workspace strategy, variable and secrets handling, CI plan/apply pipeline, naming conventions, and multi-region deployment patterns (provider aliases, per-region state, failover strategies), while delegating shared risk classification, version guards, and rollback contract to `terraform-risk-playbook`. Invoked when the user asks to write Terraform, set up infrastructure as code, or review IaC.
Creates or updates AWS-oriented Terraform module structure and implementation scaffolding. Focuses on file layout, variable/output contracts, provider and version constraints, tagging standards, safe composition patterns, and address-stability guardrails.
Designs and implements Terraform module tests for AWS-targeted modules. Covers terraform-native tests, validation gates, fixture composition, and risk-focused assertions for regressions, address migration, and unsafe changes.
Designs AWS-targeted Terraform infrastructure plans before implementation. Focuses on service selection, module boundaries, state/backends, environment separation, security/compliance guardrails, acceptance criteria, and explicit risk/validation assumptions.
Diagnoses Terraform/OpenTofu risk before generating changes. Defines the response contract, failure-mode routing, version/runtime guards, validation commands, and rollback expectations for modules, tests, CI, and state work.
Uses lightweight AWS stack emulation for faster local Terraform iteration. Defines what can be safely validated locally, compatibility caveats, and the handoff boundary to real-AWS verification and reviewed plan/apply flows.
| name | diagram-design |
| description | Designs implementation-grounded architecture, sequence, and flow diagrams from existing code and documentation. Ensures notation is chosen intentionally, avoids invented components or flows, and explicitly flags mismatches across ADRs, RFCs, and code. |
| version | 1.0.0 |
| tags | ["ui","architecture","diagram","design"] |
| resources | [] |
| vendor_support | {"claude":"native","opencode":"native","copilot":"prompt-inject","codex":"prompt-inject","gemini":"prompt-inject"} |
Inspect implementation artifacts before drawing:
README, ADRs, RFCs, architecture docs, API contracts).Capture what is explicitly evidenced. If evidence is missing, mark it as unknown.
State the single primary question the diagram must answer, such as:
Limit scope to one context per diagram to keep it reviewable.
Select notation based on the objective:
Document why this notation was chosen and why alternatives were not.
Build the diagram strictly from verified artifacts:
Unknown or TBD (needs evidence) instead of inventing paths.Do not add speculative systems, side effects, queues, or external actors without evidence.
Validate consistency across design intent and implementation:
List mismatches explicitly with:
Provide: