Template
Introduces new markdown files detailing editing rules for ADRs, guidelines for analyzer and style configuration, and best practices for observability and feature flags. These documents aim to ensure consistency and clarity in project documentation and code quality. Co-authored-by: Copilot <copilot@github.com>
852 B
852 B
description, applyTo
| description | applyTo |
|---|---|
| Use when editing files under docs/adr/. Enforces ADR immutability and supersession rules. | docs/adr/** |
ADR Editing Rules
ADRs are append-only history. To create a new ADR, use the new-adr skill.
- Accepted ADRs are immutable. Do not change
Context,Decision Drivers,Considered Options, orDecision Outcomeafter acceptance — write a new ADR that supersedes instead. - Permitted edits to accepted ADRs: typo/grammar fixes, adding links to related ADRs, and updating the
statusfield as part of supersession or deprecation. - Superseding: set the predecessor's frontmatter to
status: superseded by ADR-NNNN, update itsdate, and add a back-link in its body. Never delete the predecessor. - Filenames are permanent. Do not renumber or rename existing ADRs even if numbers have gaps.