enforces engineering-governance checks before code changes that may be unnecessary, risky, architectural, or scope-widening. use when the user asks whether to refactor, clean up, redesign, choose a next development step, review a proposed implementation, evaluate architectural consistency, review a pull request, or prevent development drift. do not use as the primary implementation skill for routine debugging, bug fixes, feature coding, or language-specific coding unless a no-op, minimal-diff, or architecture-conflict judgment is needed.
98
100%
Does it follow best practices?
Impact
96%
1.33xAverage score across 5 eval scenarios
Passed
No known issues
Use this when a choice affects architecture, ownership, runtime boundaries, write behavior, data model, or long-term direction.
# Decision: <short title>
Date: <yyyy-mm-dd>
Status: proposed | accepted | superseded
## Context
<why the decision is needed>
## Decision
<what was chosen>
## Alternatives Rejected
- <alternative>: <why rejected>
## Constraints Added or Changed
- <constraint>
## Consequences
- positive: <impact>
- negative/risk: <impact>
## Acceptance Test
<how future work proves this remains true>