mx-flow

mx-flow

Trigger

/mx-flow <topic>          ← full pipeline: idea to PR
/mx-flow status [name]    ← where every feature stands, next command
/mx-flow finish <name>    ← post-merge cleanup (read references/finish.md and follow it)

Not this skill when the change is one obvious edit with no design choice — a rename, a constant, a one-file fix. Say so and do it directly (/mx-commit for the commit, /mx-pr if it needs a PR). mx-flow's cost is the spec and the review loop; a change that needs neither should not pay for them.

Non-negotiables

Violating any of these is a workflow failure. They bind every phase and every sub-agent this skill dispatches.

1. Worktree before any code edit — before making any code change, verify the working directory is a git worktree (git rev-parse --git-dir contains worktrees/). If not, STOP and run Phase 4 first.
2. Iron Law — no production code without a failing test first. Code written before its test exists must be deleted and reimplemented after the test is in place. No exceptions.
3. Never weaken a gate to get green — no --no-verify, no lint suppressions to silence a finding, no deleting/skipping a failing test, no rewriting a RED test to match broken behavior, no relaxed assertions, no widened timeouts. A gate fighting you is a design signal: apply the wrong-direction rubric (doctrine below) — change approach or ask.
4. Review before verify — do not enter Phase 6 unless mx-team-review and mx-review-triage have run on the current branch diff at least once in this session. If unsure, check for a review report in .mx/<name>/tmp/.
5. Retry budget — the same task failing verification twice (regardless of approach) → stop retrying. In a harness with sub-agents, escalate to the strongest tier with the full failure trail (what was tried, exact diffs, exact errors); otherwise present that trail to the user with concrete options. Never a third identical attempt. (Small-tier workers get only ONE attempt before escalating — counting rule: mx-doctrine model-dispatch §6.)