rust-development-pipeline

Merged Stage 1+2 — define success criteria, explore against real fixtures, validate, implement, and produce a forensic record. One continuous session with a checkpoint in the middle. Use when the user says "/drive-outcomes <plan-path>", "drive the outcomes for this phase", after /define-outcomes completes, or when a phase plan is already ready for ODD-driven implementation.

Interactive skill that helps users define desired outcomes for the next phase through Socratic grilling. Produces a PHASE_PLAN.md with concrete goals, scope boundaries, and success criteria. Uses grill-me + first-principle thinking to question priorities and foundations before committing to a plan. This is the recommended step before `/drive-outcomes`, especially when goals are still vague. Use when the user says "/define-outcomes", "define the outcomes", "clarify what we want", "what should the next phase achieve", "plan the next phase", or wants to decide what the next phase should accomplish before implementing.

Review implemented changes against TASKS.md, produce review.md and fix-tasks.md for any defects found. Accepts a TASKS.md path and progressively loads group sections for validation. Use when the user says "/make-judgement <tasks-path>", "review the implementation", "judge the changes", or after /drive-outcomes completes for complex multi-group changes.

Debug an existing fixture-anchored system that passes its acceptance test but produces wrong physics or wrong output. Classifies prior investigation notes, establishes external anchor criteria, applies upstream-audit rule, implements fix with discriminator-value tests, and captures resolution. Use when the user says "/debug-outcomes", "debug this failure", "the test passes but the output is wrong", or describes a symptom in a system that already has fixture files and a passing (but loose) acceptance test.

Stage 0 — grill the user to settle the repo constitution: architecture, coding patterns, domain language, dependency choices. Produces CONTEXT.md (domain glossary) and ADRs (architectural decisions). MUST be run before `/drive-outcomes` on any project. Use when the user says "/init-project", "set up the project constitution", "initialize the repo for the pipeline", or on a fresh project checkout before any planning begins.

Scans a Rust project's existing test suite for placebo test patterns (vacuous assertions, circular round-trip, unbounded thresholds, synthetic-only data). Produces a migration report to help projects adopt the Outcome-Driven Development (ODD) pipeline. Use when migrating from the old TDD pipeline, auditing test quality, or when the user says "/diagnose-tests", "audit my tests", "find placebo tests", or "how healthy are my tests?".

File a bug report or feature request for the rust-development-pipeline itself, with auto-gathered context from the current project and session. Use when the user says "/file-issue", "file a bug", "report an issue", "this is a pipeline problem", or encounters a pipeline defect during daily use.