Template
✨ Adds documentation instructions for ADR, analyzers, and observability
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>
This commit is contained in:
@@ -0,0 +1,12 @@
|
||||
---
|
||||
description: "Use when editing files under docs/adr/. Enforces ADR immutability and supersession rules."
|
||||
applyTo: "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`, or `Decision Outcome` after acceptance — write a new ADR that supersedes instead.
|
||||
- **Permitted edits to accepted ADRs**: typo/grammar fixes, adding links to related ADRs, and updating the `status` field as part of supersession or deprecation.
|
||||
- **Superseding**: set the predecessor's frontmatter to `status: superseded by ADR-NNNN`, update its `date`, 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.
|
||||
Reference in New Issue
Block a user