/architecture - Architectural Decision Record
SkillDocs & knowledgeFacilitate architectural decisions during implementation. Use when the developer encounters a design choice with multiple viable approaches (data model, race condition handling, processing strategy, schema design) and needs structured discussion, trade-off analysis, and documentation. Triggers on /architecture or when a conversation reveals competing design options that need evaluation before coding continues.
Available today. Use it from your connected AI after setup.
No other account needed.
Connect ahel once, and every AI you use reads what you have installed.
Then ask your AI: use the /architecture - Architectural Decision Record skill
What this skill tells your AI
The instructions your AI receives, as published by rakovi4/continue-framework in .claude/skills/architecture/SKILL.md and read by ahel’s review.
Usage
/architecture 2 "task ordering within columns" # Story 2, named decision
/architecture 10 # Story 10, discover topic interactively
/architecture # Detect from recent git log
Purpose
When implementation reveals a design fork — multiple viable approaches with different trade-offs — this skill pauses coding to think through the options, document the decision, and plan the implementation with proper TDD steps.
Workflow
Phase 1: Context Gathering
- Resolve story from argument (same resolution as
/continue) - Read the story spec, current progress, relevant test specs, and existing ADRs
- Read the code involved — domain entities, usecases, adapters, schemas
- Summarize the decision point: what question needs answering, what triggered it, what constraints exist
Phase 2: Interactive Discussion
- Present the problem — describe the tension or fork point clearly
- Propose 2-4 options with trade-offs (how it works, pros/cons, impact, edge cases)
- Request a user decision using structured input when available, otherwise ask directly; pause so the developer can choose or propose alternatives
- Iterate until the approach is clear
- Draw diagrams when helpful — write HTML files to visualize complex flows
Phase 3: Write ADR
Use the format from .claude/templates/spec/adr-format.md.
Phase 4: Update Test Specs
Add edge case scenarios discovered during discussion to the appropriate test spec file.
Phase 5: Update Progress
Update progress.md with TDD steps that implement the decision.
Phase 6: Commit
Commit message: Story N: ADR for {decision topic} (Scenario X)
Rules
- Never generate code during this skill — it's a planning tool
- Always read existing ADRs in the story's
decisions/subfolder to avoid contradicting prior decisions - The developer makes the final call — present options, don't prescribe
- Keep ADRs concise — include current schema/code state when relevant
Templates
.claude/templates/spec/adr-format.md— ADR document format
Signals
- GitHub stars
- 51
- Forks
- 14
- Last commit
- Sep 2026
Advanced
- Catalog kind
- skill
- Gateway key
architecture-rakovi4- Source
- github.com/rakovi4/continue-framework