Help us improve
Share bugs, ideas, or general feedback.
From hb
Records concise Architecture Decision Records (ADRs) capturing what was decided and why, for decisions that are hard to reverse, surprising without context, or involve real trade-offs.
npx claudepluginhub helderberto/agent-skills --plugin hbHow this skill is triggered — by the user, by Claude, or both
Slash command
/hb:create-adrThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Capture architectural decisions as durable, minimal records future-you (and future-Claude) can read instead of guessing from code.
Creates Architecture Decision Records (ADRs) documenting technical decisions, context, alternatives considered, and consequences. Use for architectural choices, library/framework selections, or system component designs.
Writes Architecture Decision Records (ADRs) documenting decisions, rationale, alternatives, and trade-offs from codebases or conversations. Triggers on 'write an ADR' or 'document decision'.
Generates Architectural Decision Records (ADRs) by detecting project template conventions, assigning sequential numbers, supporting MADR/Nygard/Alexandrian formats, and saving markdown files. Use for documenting technical decisions.
Share bugs, ideas, or general feedback.
Capture architectural decisions as durable, minimal records future-you (and future-Claude) can read instead of guessing from code.
If any criterion is missing, say so and skip the ADR. Easy-to-reverse decisions get reversed; obvious decisions don't need recording; non-decisions ("we did the only thing that worked") aren't ADRs.
Cheap rejections prevent ADR sprawl. When in doubt, refuse and ask the user to confirm the decision really meets all three.
Restate the decision in one sentence. Check it against all three criteria explicitly. If it fails, tell the user which criterion failed and stop.
docs/adr/docs/adr/ exists, scan for the highest NNNN-*.md filename and increment.0001, 0002, …).Write docs/adr/NNNN-<kebab-slug>.md using the template below. Slug should be short and search-friendly (postgres-for-write-model, not decision-about-database-choice).
# {Short title of the decision}
{1–3 sentences: context, what was decided, and why.}
That's it. An ADR can be a single paragraph. The value is recording that a decision was made and why — not filling out sections.
Most ADRs won't need any of these.
proposed | accepted | deprecated | superseded by ADR-NNNN) — useful when decisions get revisited.Print the file path and the rendered content. Don't auto-commit — let the user stage it (matches their git rules).
docs/adr/ until you have a real ADR to put in it (lazy creation).git add here — the user stages explicitly./hb:prd.learn/learner.✅ Good — passes gate:
0003 — Manual SQL instead of an ORM
The query patterns are write-heavy and join-shaped in ways ORMs handle poorly; we hit perf cliffs in the spike. We accept the boilerplate cost in exchange for predictable plans and explicit transactions. Considered Prisma and Drizzle.
❌ Reject — fails "hard to reverse":
"We decided to use Prettier for formatting."
Reversible in one PR. Not an ADR — that's a .prettierrc and maybe a line in CLAUDE.md.
❌ Reject — fails "surprising without context":
"We decided to write tests."
Nobody will wonder why.