drift-adr-workflowlisted

# Drift ADR Workflow Skill Use this skill when a Drift change needs a documented architectural or product decision before implementation. ## When To Use - A signal is added or materially changed - Scoring logic or weights are changed - Output formats or output contracts are changed - An architecture boundary, trust boundary, input path, or output path changes - An existing ADR draft must be completed or validated ## Core Rules 1. **Run the Drift Policy Gate first.** If the task is not admissible, stop. 2. **ADR first, implementation second.** For signal, scoring, output-format, or architecture-boundary changes, prepare the ADR before coding. 3. **Agents may draft, not accept.** Agents may create or update ADRs with status `proposed`; only the maintainer changes status to `accepted` or `rejected`. 4. **Validation must be testable.** Every ADR needs a concrete validation section with measurable checks or outcomes. 5. **Do not blur bugfixes and architectural decisions.** Pure bugfixes and pure refactorings do not automatically require a new ADR. ## Step 0: Run The Drift Policy Gate Before drafting an ADR, use the mandatory gate format from `.github/instructions/drift-policy.instructions.md`. If the task fails the gate, do not create an ADR to legitimize inadmissible work. ## Step 1: Decide Whether An ADR Is Required Create or update an ADR when the change affects one of these categories: - signal design or signal behavior - scoring or prioritization logic - output sch