// Review an ExStruct ADR draft for decision quality, overlap with existing ADRs and specs, evidence strength, rollout risk, and human-ownership escalations. Use only after adr-linter reports no unresolved high/medium findings on the current draft, and when you need design-review findings before merge or handoff.
Review an ExStruct ADR draft for required sections, status values, evidence quality, supersede links, and balanced consequences. Use when an ADR already exists in draft form and you need findings before review or merge.
Use ExStruct CLI to validate, inspect, create, and edit Excel workbooks safely. Trigger when an agent needs `exstruct patch`, `exstruct make`, `exstruct validate`, `exstruct ops list`, or `exstruct ops describe`, especially for create-vs-edit decisions, dry-run workflows, backend constraints, or safe workbook-edit guidance.
Maintain ExStruct ADR index artifacts by scanning ADR files and synchronizing README, index.yaml, and decision-map.md metadata. Use when ADRs are added, updated, superseded, or reclassified and the repository needs a refreshed ADR map for humans and AI agents.
Audit ExStruct ADRs against current specs, tests, and source code to detect policy drift, missing ADR updates, stale references, and evidence gaps. Use after merges, during periodic ADR audits, or when a review suspects that implementation and ADRs have diverged.
Draft a new ExStruct ADR or propose an update to an existing ADR from an issue, PR, diff, tests, and specs. Use when an ADR is required or recommended and you need a structured draft with context, decision, consequences, and evidence.
Determine whether a change in ExStruct needs an ADR, using repository-specific governance and criteria. Use when reading an issue, PR, review thread, or diff and you need a verdict of required, recommended, or not-needed, plus candidate ADR titles and related existing ADRs.
| name | adr-reviewer |
| description | Review an ExStruct ADR draft for decision quality, overlap with existing ADRs and specs, evidence strength, rollout risk, and human-ownership escalations. Use only after adr-linter reports no unresolved high/medium findings on the current draft, and when you need design-review findings before merge or handoff. |
Review the policy decision, not just the document shape.
dev-docs/agents/adr-governance.mddev-docs/agents/adr-criteria.mddev-docs/agents/adr-workflow.mddev-docs/specs/adr-review.mddocs/ when public API / CLI / MCP contracts are in scope, internal specs, tests, src paths, and issue / PR contextadr-linter findings for the current draftadr-linter high / medium findings. Only proceed with design review after that precondition is met.Tests, Code, and Related specs actually support the claims being made, and include relevant public docs/ pages in scope when the ADR touches public API / CLI / MCP contracts.readyreviseescalateReturn findings first, ordered by severity, and include:
verdictscope
draftrelated ADRspublic docsspecssrctestsissue / PR contextfindingsEach finding should include:
type
decision-gapscope-conflictevidence-riskrollout-gapownership-escalationseveritysummarywhy it matterssuggested revisionevidence
draftrelated sourcesAlso include top-level:
open questionsresidual risksDo not silently rewrite the ADR text. If the review hits a human-owned decision, return escalate instead of inventing a final policy.