skills/adr/SKILL.md
Generate Architecture Decision Records that capture the reasoning behind technical decisions. Use when the user asks to "create an ADR", "document a decision", "record why we chose X", or discusses architectural trade-offs worth preserving.
npx skillsauth add tslateman/duet adrInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Generate an Architecture Decision Record (ADR) based on the conversation context and any architectural decisions discussed.
Create a markdown file with this structure:
# ADR-[NUMBER]: [TITLE]
**Date:** [YYYY-MM-DD]
**Status:** [Proposed | Accepted | Deprecated | Superseded]
**Deciders:** [Who was involved]
## Context
What is the issue that we're seeing that is motivating this decision or change?
## Decision
What is the change that we're proposing and/or doing?
## Consequences
What becomes easier or more difficult to do because of this change?
### Positive
- [Benefit 1]
- [Benefit 2]
### Negative
- [Trade-off 1]
- [Trade-off 2]
### Risks
- [Risk and mitigation]
## Alternatives Considered
### [Alternative 1]
- **Description:** What was this option?
- **Rejected because:** Why didn't we choose it?
### [Alternative 2]
- **Description:** What was this option?
- **Rejected because:** Why didn't we choose it?
## References
- [Related PR, issue, or document]
- [Relevant discussion or prior art]
Extract from context — Use the conversation to identify:
Find the ADR location — Look for existing ADRs:
docs/adr/ or docs/decisions/adr/ at project rootdocs/adr/Number appropriately — Check existing ADRs and use the next number
Write concisely — ADRs should be scannable:
Capture the why — The decision itself ages; the reasoning stays valuable
/research — Research informs the decision; ADR captures it/review — Reviews that surface architectural decisions belong in ADRsskills/FRAMEWORKS.md — Full framework indexdevelopment
Judgment linter for vibe-coded output — reads the energy of the code, not just correctness. Use when the user says "vibe check", "check this vibe code", "does this hold up", "sanity check this AI code", or after a fast generation session before committing.
tools
Survey the project and choose what to play next
development
Design test strategy using Beck's Test Desiderata — which properties matter, which tradeoffs to make. Use when the user asks "how should I test this", "what tests do I need", "review my test strategy", "is this well-tested", or when planning tests for a new feature or refactor.
testing
Post-op check for artifacts, damage, and stale references after agent work