메뉴
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.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
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: