galihcitta/dotclaudeskills/generating-adrs
- community
Checking that the SKILL.md file is still in the repository.
Use when PRD/TRD contains architectural decisions to document - extracts decisions from refined requirements (architecture choices, data model decisions, API patterns, technology selections, integration strategies, reuse patterns) and generates MADR-format ADRs. One ADR per decision point. Also use when asked to document decisions, create decision records, or retrospectively capture architectural choices.
Install
npx vskill@latest install galihcitta/dotclaudeskills/generating-adrsSKILL.md
Generating ADRs
Extract architectural decisions from PRDs/TRDs and generate MADR (Markdown Any Decision Record) format ADR documents.
When to Use
- PRD/TRD contains architectural choices to document
- User asks to "document decisions" or "create ADRs"
- Retrospectively capturing decisions from existing requirements
- Before implementation to formalize choices
- After implementation to document what was decided and why
When NOT to Use
- Simple bug fixes with no architectural impact
- Requirements without design decisions
- Already-documented decisions (check existing ADRs first)
Workflow
Phase 0: Locate PRD and Existing ADRs
Step 1: Find the source PRD/TRD
Read the PRD directory or file provided by user.
Step 2: Check for existing ADRs
If ADRs exist, determine next sequence number. If not, start at 0001.
Step 3: Determine output location
ADRs go in <project>/adrs/ directory (project level, NOT inside PRD folder).
Example: PRD at /Works/tada/bridge/agent-workflow/requirements/ → ADRs at /Works/tada/bridge/adrs/
Phase 1: Identify Decision Points
Scan PRD for decision patterns. See references/decision-patterns.md for full taxonomy.
Decision Types to Extract:
| Type | Signals | Often Missed? | |
|---|---|---|---|
| Architecture | ASCII diagrams, "→", "async vs sync" | No | |
| Data Model | "Key Design Decision", schema diagrams | No | |
| API Design | "Internal API", auth patterns | Yes | |
| Technology | "Uses Redis", TTL values | No | |
| Integration | "Each X in own transaction", retry patterns | Yes | |
| Business Logic | "Before/After", "Once per X not Y" | No | |
| Reuse Patterns | "Hybrid approach", "Reuse existing" | Yes |
Critical: Check for commonly missed decisions:
- [ ] Reuse vs build-new decisions ("hybrid approach", "thin wrapper")
- [ ] Error isolation patterns ("each config in own transaction")
- [ ] Internal vs external API decisions
- [ ] Calculation context decisions (what value is used as base)
Phase 2: Determine ADR Scope
For each decision, assess if it warrants own ADR:
Create separate ADR when:
- Affects multiple components
- Involves documented trade-offs
- May be questioned later
- Sets precedent for future work
Combine into single ADR when:
- Decisions tightly coupled
- Same rationale drives multiple choices
- From "Confirmed Decisions" table (can group)
Skip ADR when:
- Implementation detail only
- Standard practice with no alternatives
- Single-component impact
Phase 3: Generate ADRs
Use MADR format from references/madr-template.md.
Required sections (baseline test showed these are often missing):
Consequence format is critical - always use:
Good, because {specific positive}Bad, because {specific negative}Neutral, because {neither positive nor negative}
Phase 4: Create Index
Generate adrs/README.md:
Phase 5: Save Output
Directory structure:
Naming convention:
- 4-digit sequence:
ADR-0001notADR-001 - Kebab-case:
ADR-0001-use-async-queue.md - Title in file:
# ADR-0001: Use Async Queue
Quick Reference
| Aspect | Correct | Incorrect | |
|---|---|---|---|
| Location | <project>/adrs/ | <prd-folder>/adr/ | |
| Numbering | ADR-0001 (4 digits) | ADR-001 (3 digits) | |
| Consequences | Good, because... | Free-form text | |
| Frontmatter | Include status, date | None | |
| Options | At least 2 listed | Only chosen option |
Common Mistakes
| Mistake | Fix | |
|---|---|---|
| Missing "Considered Options" | Always list 2+ options, even if one was obvious | |
| Free-form consequences | Use "Good/Bad/Neutral, because" format | |
| Missing reuse decisions | Check for "hybrid", "reuse", "thin wrapper" | |
| ADRs in PRD folder | Put at project level <project>/adrs/ | |
| 3-digit numbering | Use 4 digits: ADR-0001 | |
| Missing context | Explain WHY decision was needed, not just what |
Anti-Patterns
- Missing alternatives - Always document what was NOT chosen
- Vague context - Be specific about forces and constraints
- No negative consequences - Every decision has trade-offs
- Wrong location - ADRs at project level, not inside PRD
- Skipping reuse decisions - "Hybrid approach" is architectural
See Also
references/madr-template.md- Full and minimal templatesreferences/decision-patterns.md- How to identify decisionsreferences/extraction-examples.md- PRD → ADR transformations
Security
- Security scanPassed, 95 of 100Pattern checks on the skill's files.
- Model reviewPassed
Quality evaluation
- Task evaluationWarning, 82 of 100Marginal. 1 run. Evaluated 7 months ago.
Source
- SKILL.md in the repositoryCheckingskills/generating-adrs/SKILL.md
Popularity
- Repository stars
- 6
- 7-day trend score
- 10
Stars and forks are for the whole GitHub repository, not this skill alone. Refreshed 23 Mar 2026, 7 months ago.
Works with
Any agent vskill installs to: 56 targets in all. These 39 have a page on this site.
- Claude Code
- Cursor
- GitHub Copilot
- Windsurf
- Codex
- Gemini CLI
- Cline
- Amp
- Roo Code
- Goose
- Continue
- Kilo Code
- Junie
- Trae
- OpenHands
- Qwen Code
- AI Agent
- Tabnine Chat
- Sourcegraph Cody
- Amazon Q
- Firebase Genkit
- Sweep
- Devin
- Phind
- Mentat
- Claude Desktop
- Aider
- GPT Pilot
- Plandex
- bolt.new
- v0
- Replit Agent
- Anse
- TypingMind
- BetterChatGPT
- LibreChat
- Warp AI
- Pieces
- Fig AI
Embed badge
[](https://verified-skill.com/skills/galihcitta/dotclaudeskills/generating-adrs)