/architecture - Architectural Decision Record

SkillDocs & knowledge

Facilitate 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.

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

  1. Resolve story from argument (same resolution as /continue)
  2. Read the story spec, current progress, relevant test specs, and existing ADRs
  3. Read the code involved — domain entities, usecases, adapters, schemas
  4. Summarize the decision point: what question needs answering, what triggered it, what constraints exist

Phase 2: Interactive Discussion

  1. Present the problem — describe the tension or fork point clearly
  2. Propose 2-4 options with trade-offs (how it works, pros/cons, impact, edge cases)
  3. Request a user decision using structured input when available, otherwise ask directly; pause so the developer can choose or propose alternatives
  4. Iterate until the approach is clear
  5. 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