adr-authoring

# MADR Authoring Skill Canonical rules for project-level Architecture Decision Records. All ADR file mutations flow through the **ADR Author** subagent (`.github/agents/_adr-author.md`). Orchestrating workflows (system-design, plan-feature, amend-project) decide *when* an ADR is needed; this skill defines *what* the ADR must look like and *how* it is managed. ## Scope - Project-level architectural decisions only. - Standalone Markdown files under `specs/adrs/`. - Feature-local tradeoffs stay in `plan.md` as `AD-###` rows and never invoke this skill. ## MADR Profile ### Required Frontmatter ```yaml --- adr_id: ADR-NNNN status: proposed | accepted | deprecated | superseded date: YYYY-MM-DD tags: [] supersedes: [] superseded_by: "" related_artifacts: [] --- ``` ### Optional Frontmatter ```yaml deciders: [] consulted: [] informed: [] review_date: YYYY-MM-DD ``` ### Required Body Sections ```markdown # ADR-NNNN: Decision Title ## Status [Mirrors frontmatter status in human-readable form. Include supersession links when applicable.] ## Context [Problem, forces, constraints, and why a decision is needed now.] ## Decision Drivers - [Criteria that drove the choice, ordered by weight] ## Considered Options ### Option A: [Label] - Pros: … - Cons: … ### Option B: [Label] - Pros: … - Cons: … ## Decision Outcome Chosen option: **[Label]** — [rationale for selecting it]. ## Consequences ### Positive - … ### Negative - … ### Neutral - … *(optional)* ## Links - [Related AD...