Menu
Create Architecture Decision Records (ADRs) documenting WHY decisions were made. Uses standard ADR format (Status/Context/Decision/Consequences).
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
| name | document-decision |
| description | Create Architecture Decision Records (ADRs) documenting WHY decisions were made. Uses standard ADR format (Status/Context/Decision/Consequences). |
Use this skill when recording system design decisions for LikeC4-modeled architectures.
Create Architecture Decision Records (ADRs) that explain WHY architectural choices were made in the system diagrams, not HOW the diagrams are built or maintained.
ADR/NNNN-decision-title.md (manually increment NNNN)ADR/0000-template.md as reference# ADR-0001: API Gateway Selection - Kong vs HAProxy
## Status
Accepted
## Context
Legacy system used HAProxy as a simple load balancer. Microservices architecture requires:
- API-aware routing based on paths, headers, JWT claims
- Built-in authentication (JWT validation, OAuth2)
- Rate limiting and circuit breakers
- Plugin ecosystem for extensibility
## Decision
Upgrade from HAProxy to Kong API Gateway
## Consequences
### Positive
- Routes to multiple backend services with path-based rules
- JWT validation out-of-the-box, reducing custom auth code
- Production-grade rate limiting without custom implementation
- Extensible via Lua plugins
### Negative
- More complex configuration than HAProxy
- Requires learning Kong admin API and declarative config
- Higher resource footprint (but acceptable for use case)
mySystem.apiGateway (Container_ReverseProxy)"deployment_api_tier"Design views with proper includes/excludes and basic layout. Use for include patterns, tag filtering, and simple rank hints. For advanced styling/navigation, use customize-view.
Model deployment infrastructure (environments, zones, VMs, apps) with proper hierarchy and instanceOf links. Organize zones into tiers (DMZ, App, Data, Processing) with rich descriptions including VLAN/network specifications.
Use metadata for system models (business/technical context) and markdown tables for deployment models (infrastructure specs). Makes models queryable and self-documenting.
C4 modeling methodology - design system hierarchy top-to-bottom from Context to Components. Ensures consistent, stakeholder-focused architecture documentation.
Manage likec4.config.json includes and image aliases. Ensures relative paths and preserves existing configuration. Support multi-file organization (system-model + system-views + deployment + operations).
Create elements with proper naming (PascalCase kinds, camelCase vars), required metadata (technology, description), and correct hierarchy.