adr-author

name	adr-author
description	Authoring skill for Architecture Decision Records (ADRs) supporting capture, from-planner-handoff, and adopt-template entry modes with selectable Y-Statement or MADR v4.0.0 output templates, supersession lineage, and ASR trigger evaluation - Brought to you by microsoft/hve-core.

adr-author

Overview

This skill encodes the per-phase authoring conventions for Architecture Decision Records consumed by the ADR Creator agent. It supports three entry modes and two output templates and converges all of them at the Govern phase, where the final ADR file is written and lineage is updated atomically.

Entry modes (state.entryMode):

• capture — Interactive authoring driven by user answers to Frame and Decide questions.
• from-planner-handoff — Entry from an upstream planner (Security, RAI, SSSC) with pre-populated Frame fields. Frame still requires user confirmation before exit.
• adopt-template — One-time setup mode that ingests a project's pre-existing ADR template and emits both the first ADR and a committed .adr-config.yml.

Output templates (state.outputTemplate):

• y-statement — Compact Y-Statement-shaped ADR for low-stakes or reversible decisions. Compressed Frame; ASR triggers optional.
• madr-v4 — Long-form MADR v4.0.0 ADR for architecturally significant decisions. ASR trigger evaluation required during Frame.

Entry mode and output template are independent: a from-planner-handoff session can target either y-statement or madr-v4, and a capture session can do the same. The adopt-template mode produces output shaped by the user's normalized template.

Lifecycle at a glance:

Mode	Phase sequence	Output
capture	Frame → Decide → Govern	Shaped by outputTemplate (y-statement or madr-v4)
from-planner-handoff	Frame (confirm pre-populated) → Decide → Govern	Shaped by outputTemplate (y-statement or madr-v4)
adopt-template	Ingest → Normalize → Derive Questions → Fill → Govern	First ADR + .adr-config.yml per the BYO contract

The state machine, hard exit gates, autonomy tiers (manual, partial, full), and the canonical state.json schema are defined in adr-identity.instructions.md. This skill provides the authoring activities and artifact contracts; it does not redefine the state machine.

Frame

Activities:

• Scope — capture the decision in one or two sentences; bound it to a single project.
• Decision-makers — record deciders, consulted, informed (RACI-aligned).
• Drivers — list decision drivers (functional needs, business goals).
• Constraints — list non-negotiables (regulatory, platform, contractual, time).
• ASR trigger evaluation — required when state.outputTemplate == 'madr-v4'. Evaluate triggers against the rubric in adr-standards.instructions.md and record results in state.asrTriggers[]. Defer the rubric and full taxonomy to that file and to references/asr-trigger-taxonomy.md.
• Diagram-format prompt — when state.userPreferences.diagramFormat is unset, ask the user ascii or mermaid and persist the answer to state.userPreferences.diagramFormat. Required before Frame can exit.

Hard exit gate (restated from adr-identity.instructions.md):

The Frame phase cannot advance without all of the following recorded: scope statement, deciders list, decision drivers, ASR triggers determination (when outputTemplate == 'madr-v4'), and userPreferences.diagramFormat. The user must confirm the Frame summary before advancing.

Output artifacts:

• Frame section of the in-progress ADR draft (working draft only; not yet written to disk).
• Updated state.json fields: scope, deciders, consulted, informed, drivers, constraints, asrTriggers (when outputTemplate == 'madr-v4'), userPreferences.diagramFormat.

Decide

Activities:

• Option enumeration — at least two considered options. A single-option ADR is rejected at this gate.
• Evaluation criteria — score each option against the drivers and constraints captured in Frame.
• Decision outcome selection — name the chosen option and articulate the rationale.
• Consequences — document positive, negative, and neutral consequences. Negative consequences are not optional; an ADR with no documented downside is rejected at this gate.

Y-Statement assembly (when state.outputTemplate == 'y-statement'):

• Compose the chosen option using the verbatim six-slot formula in templates/y-statement.md:

  In the context of (USE CASE), facing (CONCERN), we decided for (OPTION) and against (ALTERNATIVES), to achieve (QUALITY), accepting (DOWNSIDE).

• The Y-Statement is the entire Decide output for the y-statement template. The full MADR options table is omitted.

Hard exit gate:

The Decide phase cannot advance without at least two considered options, the chosen option, and the decision rationale recorded. The user must confirm the Decide summary before advancing.

Govern

This phase converges all three entry modes and is the only phase that writes ADR files to disk.

Activities:

1. MADR v4 frontmatter assembly — render the ADR frontmatter from templates/madr-v4.md. The template is reproduced verbatim from MADR v4.0.0 (CC0); see references/standards-excerpts.md for attribution. Merge templates/madr-v4-frontmatter-overlay.md on top to inject hve-core extension fields (id, deciders, tags, supersedes, superseded-by, related, asr_triggers) without modifying the verbatim upstream template (GP-17).
2. Diagram render — based on state.userPreferences.diagramFormat, embed the diagram body from either templates/diagram-ascii.md or templates/diagram-mermaid.md. Skill callers do not branch on platform; the template selection is purely data-driven.
3. Lineage validation — apply the six supersession rules summarized below; full text is in references/lineage-rules.md.
4. Frontmatter validation — invoke scripts/validate_frontmatter.py against the staged ADR file. The script returns a non-zero exit code on schema or enum violations and is the single authority for frontmatter shape.
5. Lineage allocator — invoke scripts/update_lineage.py to mutate .adr-config.yml. The allocator is the only writer of last_decision_id. Manual edits to last_decision_id are forbidden.
6. Final write — write the ADR to docs/planning/adrs/{NNNN}-{slug}.md. The path is derived from the allocator-issued NNNN and the slugified ADR title.
7. Handoff trigger — emit the dual-format (ADO + GitHub) work items per adr-handoff.instructions.md. This skill stops at handoff emission; routing is the agent's responsibility.

Govern uses the autonomy and disclaimer banners required by adr-identity.instructions.md and shared/disclaimer-language.instructions.md. Do not duplicate those texts here; load them at runtime.

Supersession Lineage Rules (Summary)

Brief enumeration. Full normative text and edge cases live in references/lineage-rules.md.

1. supersedes and superseded-by are each a scalar string or null.
2. Single-parent supersession — a given ADR has at most one superseded-by.
3. Status transition — the superseding ADR's status becomes accepted; the superseded ADR's status becomes superseded.
4. Lineage updates are atomic — both ADR files MUST be updated in the same Govern phase.
5. The lineage allocator (scripts/update_lineage.py) is the single writer of last_decision_id in .adr-config.yml; manual edits are forbidden.

Status Taxonomy

ADR status is one of six closed values. Full definitions and lifecycle transitions live in adr-standards.instructions.md.

• proposed — under active drafting; not yet decided.
• accepted — decision adopted; current authority for the scope.
• rejected — considered and declined; retained for historical context.
• deprecated — no longer recommended but not yet replaced.
• superseded — replaced by a newer ADR via the lineage rules below.
• withdrawn — proposal withdrawn before decision.

ASR Trigger Catalog (Summary)

ASR (Architecturally Significant Requirement) triggers are evaluated only when state.outputTemplate == 'madr-v4'. The closed enum has eight values:

• cost
• performance
• security
• compliance
• availability
• scalability
• maintainability
• evolvability

The trigger rubric, evaluation prompts, and example mappings are defined in adr-standards.instructions.md and elaborated in references/asr-trigger-taxonomy.md. Do not introduce trigger values outside the closed enum.

Adopt-Template Lifecycle

Five-step pointer. Full lifecycle, including GP-13 (the .adr-config.yml schema and the 2-layer config resolution), lives in adr-byo-template.instructions.md.

1. Ingest — accept the user's existing ADR template file or template directory.
2. Normalize — invoke scripts/normalize_template.py to convert the template into the canonical ADR frontmatter and section structure.
3. Derive Questions — generate the Frame and Decide question set from the normalized template's required fields.
4. Fill — execute the derived questions to populate the first ADR.
5. Govern — run the standard Govern phase. When lineage_fields are absent from the adopted template, the agent MUST warn the user and require an explicit confirmation before writing; this is the warn-and-confirm Govern behavior referenced in adr-byo-template.instructions.md.

Templates

• templates/madr-v4.md — MADR v4.0.0 ADR template (verbatim, CC0). Used by Govern frontmatter assembly when state.outputTemplate == 'madr-v4'.
• templates/y-statement.md — Six-slot Y-Statement formula for Decide assembly when state.outputTemplate == 'y-statement'.
• templates/diagram-ascii.md — ASCII diagram block, selected when state.userPreferences.diagramFormat == "ascii".
• templates/diagram-mermaid.md — Mermaid diagram block, selected when state.userPreferences.diagramFormat == "mermaid".

References

• references/standards-excerpts.md — MADR v4.0.0 verbatim text and CC0 attribution; Y-Statement attribution; status taxonomy.
• references/lineage-rules.md — Full text of the six supersession rules with edge cases and worked examples.
• references/asr-trigger-taxonomy.md — Full ASR trigger taxonomy, rubric prompts, and examples for each of the eight enum values.

Scripts

• scripts/render_template.py — Renders a template from templates/ against a Frame+Decide payload to produce an in-memory ADR draft. Path-traversal guarded: refuses any output path outside docs/planning/adrs/.
• scripts/validate_frontmatter.py — Validates ADR frontmatter against the MADR v4 schema and the closed enums. Returns non-zero on violation. Path-traversal guarded against the same root.
• scripts/update_lineage.py — Single writer of last_decision_id in .adr-config.yml. Mutates predecessor ADRs' superseded-by atomically with the new ADR's supersedes. Path-traversal guarded.
• scripts/normalize_template.py — Converts a user-supplied ADR template into the canonical structure used by templates/madr-v4.md. Used only by the adopt-template lifecycle. Path-traversal guarded.

All scripts treat their working directory as untrusted input and reject paths that resolve outside the project ADR root.

Source Attribution

• templates/madr-v4.md — reproduced byte-identical from MADR v4.0.0 (tag 4.0.0, file template/adr-template.md), released under CC0-1.0. CC0 does not require attribution; it is recorded here for transparency. Upstream typographical anomalies (for example, the unbalanced quotation in the status: placeholder) are preserved intentionally to keep the file diff-clean against the upstream release.

Mandatory Load Directives

The ADR Creator agent enforces a phase→section load contract per adr-identity.instructions.md. Each phase MUST load its section of this skill before executing phase work, and MUST append the section anchor to state.phaseSkillsLoaded:

Phase	Section anchor	Required phaseSkillsLoaded entry
Frame	#frame	adr-author#frame
Decide	#decide	adr-author#decide
Govern	#govern	adr-author#govern

The agent loads sections via read_file against this skill file and records the entry in state.phaseSkillsLoaded before any phase work executes. Re-entering a previously loaded phase does not require reloading; the agent checks phaseSkillsLoaded first.

---

Brought to you by microsoft/hve-core

🤖 Crafted with precision by ✨Copilot following brilliant human instruction, then carefully refined by our team of discerning human reviewers.