drift-signal-development-full-lifecyclelisted

# Drift Signal Development Full Lifecycle Skill Use this skill for non-trivial signal work from decision through validation. ## When To Use - A new signal is being added - An existing signal changes materially - A signal heuristic is recalibrated in a way that affects trust, precision, or recall - A signal is being prepared for scoring readiness or report-only hardening ## Core Rules 1. **Run the Drift Policy Gate first.** Signal work that fails admissibility should stop before design begins. 2. **ADR before implementation.** Non-trivial signal work needs an ADR draft before code changes. 3. **Every signal must be explicit about scope.** Declare `incremental_scope` on the class. 4. **Evidence is mandatory.** Signal logic without fixtures, targeted tests, and audit updates is incomplete. 5. **Optimize for credibility before comfort.** Precision, reproducibility, and actionability outrank convenience or breadth. ## Step 0: Run The Drift Policy Gate Use the gate format from `.github/instructions/drift-policy.instructions.md` before doing design or implementation work. ## Step 1: Start With Decision And Design Before coding: - decide whether the task is a new signal, a material heuristic change, or a calibration pass - draft or update the ADR using the `drift-adr-workflow` skill - use `docs/decisions/templates/signal-design-template.md` for signal-centric decisions If a calibration materially changes signal behavior, scoring implications, or reviewer trust expectations