change-brieflisted

# Skill: change-brief ## Purpose Close the gap between **code that runs** and **code that's owned**. AI-generated code compiles, passes the happy-path test, and ships — and the developer who merged it cannot explain why it's shaped that way, what breaks it, or who it affects. The defect surfaces in production weeks later, and nobody on the team can navigate the code that caused it. The existing rule ("Don't accept code you don't understand", `engineering-principles.md § AI-assisted development`) is advisory — nothing enforces it. This skill is the mechanical surface: a change cannot advance past `/pre-commit` / `/review-changes` until a brief exists that proves the change was understood, not just accepted. **The brief is the explain-it-or-it-isn't-yours test in artifact form.** Writing it takes 2 minutes when you understand the change — and is impossible when you don't. That asymmetry is the gate. ## When to use - Dispatched by `/pre-commit` (generate + validate before the commit lands) and `/review-changes` (validate that the PR body carries a passing brief). - On demand: "write the change brief for this diff" / "does this PR have a valid brief?". - **Self-applied by agents**: when an agent authors a non-trivial change, it generates the brief as part of the same turn — an agent that cannot fill all 5 fields from what it actually did has not finished the work. ### Trigger tiers (what counts as non-trivial) A brief is REQUIRED when the change matches any of: - diff > 2