Recording Architecture Decisions
Purpose
Record durable architecture decisions without losing the current-state baseline
closure. An ADR records why a decision was made; a baseline records what the
architecture is after that decision.
This skill is a lazy, task-specific workflow. It does not replace
verification-before-completion, does not grant completion authority, and does
not make authoritative GateDecision or PolicySnapshot outputs.
Required Read Set
Before deciding or writing, read the smallest relevant excerpts from:
docs/adr/ADR-CREATION-GATE.mddocs/current/AEGIS_ADR_AUTO_BACKFILL.md- the target project's current ADR, baseline, or authority docs that own the
affected architecture surface
For Aegis repository changes, use this repository's docs/adr/ and
docs/current/ authority order. For target projects with their own ADR system,
respect that project owner instead of duplicating the same decision into
docs/aegis/adr/.
When To Use
Use this skill when the user asks to:
- create, write, update, amend, supersede, or evaluate an ADR
- decide whether an architecture decision record is needed
- record a durable architecture decision or decision log entry
- close baseline sync after an ADR-relevant architecture change
- verify that an ADR action did not leave the architecture baseline stale
Do not use it for simple wording edits, ordinary README cleanup, tests-only
coverage improvements, low-risk single-file changes, or bug fixes that only
restore the existing baseline.
Decision Flow
- Identify the decision candidate and evidence source.
- Run the ADR creation gate:
- hard to reverse
- surprising without context
- real trade-off
- Apply the Retro / Memory Filter:
- executed durable decisions may become ADR or baseline memory
- unexecuted ideas stay out of accepted architecture memory
- process notes may use a lighter record when they do not change current
architecture state
- Choose exactly one ADR action: create, amend, supersede, or skip.
- Choose the owner surface: project
docs/adr/, docs/aegis/adr/, existing
ADR, or lighter record.
- Run Baseline Sync Closure.
- If writing files, preserve local ADR conventions and verify structure.
Helper-Backed Write Path
When the chosen owner surface is a target project's docs/aegis/adr/, use the
shared workspace helper instead of ad-hoc file creation:
create -> <aegis-workspace-helper> new-adr --root <target-project-root> ...amend -> <aegis-workspace-helper> amend-adr --root <target-project-root> --path docs/aegis/adr/ADR-####-<slug>.md ...supersede -> <aegis-workspace-helper> supersede-adr --root <target-project-root> --path docs/aegis/adr/ADR-####-<slug>.md ...
After helper-backed writeback, run:
<aegis-workspace-helper> check --root <target-project-root>
The helper owns file shape, ADR numbering, supersession markers, and
INDEX.md coverage only. It does not decide architecture truth, whether the
ADR gate passed, or whether baseline sync is semantically sufficient.
If the ADR gate or owner-surface decision says skip, do not create or amend
ADR files just because the helper exists. An ADR signal in a design/plan is a
note for later completion, not an ADR file. Create/amend/supersede an ADR only
for an executed durable decision; if an existing ADR already covers the
decision surface, amend it instead of creating a sibling.
Baseline Sync Closure
If the ADR action is create, amend, or supersede, baseline sync must be checked.
Baseline sync is required when the decision changes or confirms any of:
- canonical owner or ownership map
- public API, schema, artifact shape, or behavior contract
- dependency direction or allowed cross-module relationship
- source-of-truth owner
- host compatibility strategy or install/discovery contract
- method-pack/runtime-core boundary
- runtime-ready artifact boundary or evidence model
- retained fallback, adapter, compatibility path, duplicate owner, or retirement
schedule
- accepted architecture-scoped Implementation Drift
- release or distribution strategy that future contributors would otherwise
misread
If no baseline writeback is made, state why the existing baseline remains valid.
Never leave baseline sync implicit after create, amend, or supersede.
Compact Output Contract
Aegis Visibility:
- Why executed-decision filtering, ADR gate, owner surface, or baseline sync matters now:
Decision Candidate:
- Summary:
- Evidence source:
ADR Gate:
- Hard to reverse: yes | no | unknown
- Surprising without context: yes | no | unknown
- Real trade-off: yes | no | unknown
Retro / Memory Filter:
- Classification: executed durable decision | unexecuted idea | process note
- Memory action: record | skip | lighter record
- Reason:
ADR Action:
- create | amend | supersede | skip
- Reason:
Owner Surface:
- Target:
- Existing ADR / baseline checked:
Baseline Sync:
- Required: yes | no | unknown
- Target:
- Action: create snapshot | update baseline | cite unchanged | blocked
- Reason:
Boundary:
- Advisory method-pack signal only; not completion authority.
Common Mistakes
- Writing an ADR because the topic feels important, even though the gate fails.
- Recording why in an ADR while leaving the baseline's current-state facts stale.
- Updating a baseline to match drift without first deciding whether the drift is
intentional and ADR-worthy.
- Duplicating the same decision into both project
docs/adr/ and
docs/aegis/adr/ without an explicit mirror relationship.
- Treating an ADR or baseline sync as proof that the work is complete.
anthropics/skills180k
