ADR Suggestion Skill
When you detect an architectural decision being made, gently suggest documenting it.
What Qualifies as ADR-Worthy
Decisions that:
- •Affect multiple parts of the codebase
- •Are difficult or costly to reverse
- •Involve trade-offs between competing concerns
- •Establish patterns that future code should follow
- •Change how the system behaves architecturally
What Does NOT Need an ADR
- •Bug fixes
- •Minor refactoring
- •Adding features within existing patterns
- •Routine dependency updates
- •Code style changes
How to Suggest
After completing significant architectural work, suggest:
This change introduces [pattern/technology/approach]. Consider documenting this decision with an ADR to capture the context and reasoning. You can run
/adr:createto create one.
Suggestion Guidelines
- •Suggest once per decision, not repeatedly
- •Frame as optional, not required
- •Only suggest after the work is done, not before
- •Include what makes this ADR-worthy (e.g., "introduces a new caching layer")
- •Keep suggestions brief - one sentence plus the command reference