Adr gen
A portable library of standardized AI agent skills and orchestration scripts, built on the SKILL.md open standard to streamline consistent engineering workflows across diverse LLM clients.
npx -y skills add victoriacheng15/dev-toolchain --skill adr-genAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 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
Guides the creation and management of Architectural Decision Records (ADRs) with immutable indexing.
SKILL.md
2.5 KB, as published. Nobody here has run it
Architectural Decision Records (ADR)
Overview
Architectural Decision Records (ADRs) capture critical design decisions, the context in which they were made, and the long-term consequences and trade-offs. This skill standardizes the lifecycle of ADRs, ensuring architectural continuity and visibility as the codebase evolves.
Automated Execution
To create a new, auto-incremented ADR skeleton, execute the companion template generator from the root of the workspace:
./adr-gen/new-adr.sh "Title of the Decision"
This script scans the docs/adr/ directory, detects the next sequential ID, and generates a pre-formatted template with standard metadata headers.
ADR Lifecycle States
Every ADR must transition through defined, explicit lifecycle states:
- Proposed: The decision is currently under active discussion or review.
- Accepted: The decision has been approved by the core engineering team and is active.
- Superseded: The decision has been replaced by a newer ADR. When superseding, you must update the older ADR's metadata block to point directly to the replacing ADR (e.g.,
Superseded by ADR-005).
Mandatory ADR Template Structure
All ADR markdown files (e.g., docs/adr/001-use-vitest-for-testing.md) must strictly adhere to the following schema:
# ADR XXX: [Descriptive Title]
- **Status:** [Proposed | Accepted | Superseded by ADR-YYY]
- **Date:** [YYYY-MM-DD]
- **Author:** [Author Name]
## Context and Problem Statement
[What specific issue triggered this change?]
## Decision Outcome
[What was the chosen architectural path?]
## Consequences
### Positive
- **[Benefit 1]:** [Description]
### Negative
- **[Drawback 1]:** [Description]
## Verification
- [ ] **Manual Check:** (e.g., Verified logs/UI locally).
- [ ] **Automated Tests:** (e.g., `make test` passed).
Verification Checklist
Prior to committing a new ADR, verify that:
- State Specified: The metadata section contains an allowed lifecycle state.
- Chronology Checked: The next sequential integer index has been reserved using the orchestration script.
- Consequences Documented: Both positive benefits and negative drawbacks are explicitly listed.
- Traceability Maintained: If this ADR supersedes an existing one, the old ADR has been edited to change its status to "Superseded by ADR-XXX".