Architecture decision records
Skill shinzoxD/knackbox/skills/documents/architecture-decision-records
Curated, auditable, benchmark-ready Agent Skills library for Claude Code, Codex, OpenCode, Cursor, and more.
npx -y skills add shinzoxD/knackbox --skill architecture-decision-recordsAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 27 days oldThe repository was created 27 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Write concise Architecture Decision Records that capture context, decision, and consequences. Use whenever the user asks for an ADR, architecture decision log entry, decision record, or why we chose technology X over Y in a durable doc — even for small stack choices.
The file declares its own license as Apache-2.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
1.8 KB, as published. Nobody here has run it
Architecture Decision Records
ADRs are short, immutable-enough records of decisions. Prefer clarity over essay length. Link out to full RFCs when needed.
When to use ADR vs RFC
- ADR: single decision, few pages, durable log entry.
- RFC: broader design with multiple open questions and detailed design.
Format (default)
# ADR-<NNNN>: <Title>
Date: YYYY-MM-DD
Status: proposed | accepted | deprecated | superseded by ADR-XXXX
## Context
Forces, constraints, requirements.
## Decision
What we will do, in plain language.
## Alternatives considered
- Option A — why not
- Option B — why not
## Consequences
Positive, negative, and follow-up work.
## Notes
Links, owners, review date.
Rules
- One decision per ADR.
- Status must be explicit; superseding must reference the new ADR id.
- Alternatives must be real, not strawmen.
- Consequences include ops, cost, security, and team skills — not only happy path.
- Keep under ~2 pages unless the user asks for more.
- Do not rewrite history; supersede instead of silently editing accepted ADRs.
Edge cases
- Revisiting an old ADR: add a new ADR that supersedes; summarize delta.
- Reversible trial: status can be accepted with a review date.
- User wants template only: provide empty format with guidance comments.