From architect
Write an Architecture Decision Record using the MADR template. Captures context, options considered, decision made, consequences, and confirmation criteria.
npx claudepluginhub hpsgd/turtlestack --plugin architectThis skill is limited to using the following tools:
Write an ADR for $ARGUMENTS using the MADR (Markdown Any Decision Records) format.
Guides Next.js Cache Components and Partial Prerendering (PPR) with cacheComponents enabled. Implements 'use cache', cacheLife(), cacheTag(), revalidateTag(), static/dynamic optimization, and cache debugging.
Migrates code, prompts, and API calls from Claude Sonnet 4.0/4.5 or Opus 4.1 to Opus 4.5, updating model strings on Anthropic, AWS, GCP, Azure platforms.
Analyzes BMad project state from catalog CSV, configs, artifacts, and query to recommend next skills or answer questions. Useful for help requests, 'what next', or starting BMad.
Write an ADR for $ARGUMENTS using the MADR (Markdown Any Decision Records) format.
Write an ADR for decisions that:
Don't write an ADR for: trivial choices (variable names, which linter rule), decisions already covered by project conventions, or temporary decisions that will be revisited within a sprint.
find . -path '*/adr*' -name '*.md' -o -path '*/architecture-decisions*' -name '*.md' | sort
ls docs/adr/ 2>/dev/null | sort -n | tail -1
Use the MADR template. The template is at ${CLAUDE_PLUGIN_ROOT}/templates/adr-template.md — read it for the full structure.
Key sections (none optional):
---
status: "proposed"
date: YYYY-MM-DD
decision-makers: [who is making this decision]
consulted: [who was asked for input]
informed: [who needs to know the outcome]
---
# ADR-NNNN: {Short title — describes the problem AND solution}
Good: "ADR-0005: Use PostgreSQL BYTEA for binary content storage" Bad: "ADR-0005: Database decision" (too vague) Bad: "ADR-0005: We should use PostgreSQL" (no problem stated)
2-3 sentences. What situation requires a decision? What forces are at play? Frame as a question if helpful.
Rules:
Bulleted list of forces that influence the decision. These become the evaluation criteria for options.
At least 2 options. Always include "do nothing / status quo" if applicable.
Three categories:
How will you know this decision is working? Specific criteria:
For EACH option (including the chosen one):
Good, because... / Bad, because... / Neutral, because...Before declaring the ADR complete:
| Anti-Pattern | Problem | Fix |
|---|---|---|
| Retroactive ADR | Written after the decision to justify it | Write during the decision process, not after |
| No alternatives | Only the chosen option described | Always include at least one real alternative |
| Strawman options | Alternatives are obviously bad | Include options that were genuinely considered |
| Missing consequences | Only positive outcomes listed | Every decision has trade-offs. State them |
| Too long | 5+ pages | One page ideal, two maximum. Link to supporting docs |
| Too vague | "We chose X because it's better" | Better at WHAT? Against which decision drivers? |
| Orphaned ADR | No confirmation criteria | How will you know if this was the right call? |
Write to the project's ADR directory (check for existing location: docs/adr/, docs/architecture-decisions/, or docs/decisions/). If none exists, create docs/adr/.
File naming: NNNN-kebab-case-title.md (e.g., 0005-use-postgresql-bytea-for-content.md)
After writing, update any index file if one exists.
/architect:evaluate-technology — use when the ADR requires a technology comparison. Evaluate first, then record the decision as an ADR./architect:system-design — system designs often produce ADR-worthy decisions. Reference ADRs from the system design's key decisions table.