Stats
Actions
Tags
'%20stop-opacity%3D'0.16'%2F%3E%3Cstop%20offset%3D'1'%20stop-color%3D'rgb(200%2C90%2C60)'%20stop-opacity%3D'0.03'%2F%3E%3C%2FlinearGradient%3E%3C%2Fdefs%3E%3Crect%20width%3D'320'%20height%3D'200'%20fill%3D'url(%23g)'%2F%3E%3Ccircle%20cx%3D'250'%20cy%3D'56'%20r%3D'92'%20fill%3D'rgb(200%2C90%2C60)'%20fill-opacity%3D'0.06'%2F%3E%3Ccircle%20cx%3D'64'%20cy%3D'172'%20r%3D'58'%20fill%3D'rgb(200%2C90%2C60)'%20fill-opacity%3D'0.05'%2F%3E%3C%2Fsvg%3E)
From totto2727
Skill for creating and referencing Architecture Decision Records (ADR). Use when recording design decisions, reviewing past architectural choices, or checking existing ADRs before implementation. Common triggers: "create ADR", "record design decision", "check ADR", "architecture decision", "design rationale". Do NOT use for: general documentation, meeting notes, code comments, or changelog entries.
How this skill is triggered — by the user, by Claude, or both
Slash command
/totto2727:adrThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Important architectural decisions are recorded as ADRs in `doc/adr/`.
Important architectural decisions are recorded as ADRs in doc/adr/.
If the doc/adr/ directory does not exist, create it before writing the first ADR.
!echo "$(date +%Y-%m-%d)-title.md"
All ADR files must have the following YAML frontmatter:
---
confirmed: false
---
| Field | Type | Description |
|---|---|---|
confirmed | boolean | true: Confirmed (generally immutable), false: Proposed (pending review) |
---
confirmed: false
---
# ADR: Title
## Context
Background on why this decision is needed.
## Decision
The specific design decision. May include table design, API design, route design, etc.
## Impact
The scope of impact from this decision. New tables, changes to existing code, new routes, etc.
confirmed: false and confirm after review.confirmed to true.confirmed: true must not be modified in principle.doc/adr/ directory exists (create if missing)YYYY-MM-DD-title.md file in doc/adr/confirmed: false in the frontmatterconfirmed: trueconfirmed: truenpx claudepluginhub totto2727-org/monorepo --plugin totto2727Guides collaborative design exploration before implementation: explores context, asks clarifying questions, proposes approaches, and writes a design doc for user approval.
Creates structured, bite-sized implementation plans from specs or requirements before writing code. Useful for breaking down multi-step tasks into testable steps with file structure and task boundaries.
Resolves in-progress git merge or rebase conflicts by analyzing history, understanding intent, and preserving both changes where possible. Runs automated checks after resolution.