/synthex:next-priority/synthex:next-priority

#What it does, end-to-end

/synthex:next-priority/synthex:next-priority is the command you re-run during the build phase. Each invocation:

1. Reads the implementation plan at docs/plans/main.md (configurable via documents.implementation_plan).
2. Picks the next batch of unblocked, non-overlapping tasks. Up to your next_priority.concurrent_tasks budget. The selection rules:
   • Status is not done, blocked, or awaiting [H].
   • All listed dependencies are satisfied.
   • The task is in the current milestone — phase boundaries are never crossed in a single run.
3. Marks the selected tasks in progress in the plan immediately, so concurrent runs (or future ones) don't re-pick them.
4. Spins up a git worktree per task at .claude/worktrees/feature/<task-id>-<slug> on a fresh branch off main.
5. Delegates each task to a Tech Lead instance scoped to its worktree.
6. Monitors completions, validates acceptance criteria, fast-forward merges into main, and removes the worktree.
7. Updates the plan with completion notes — including the test file + test name for each [T] criterion, and the user's approval record for each [H] criterion.

#Parameters

#When to run it

You re-run /synthex:next-priority/synthex:next-priority after every batch you finish. Some teams run it once per work session; others pass --loop to iterate it autonomously until the plan is complete or a configured completion-promise fires — see Native looping.

If your plan has lots of [H] criteria, you'll bottleneck on review attention rather than agent throughput. Drop concurrent_tasks so the review queue stays manageable.

#Common scenarios

#"All remaining tasks are blocked"

The command exits without picking up work and tells you which tasks remain and why. This is the correct behavior — it does NOT emit the --loop completion promise in this case, because the plan isn't complete; it's waiting on you.

#"A task fails or the Tech Lead gets stuck"

The blocker is captured in the task's plan record, the worktree is preserved for inspection (it is NOT deleted on failure — your in-progress work is safe), and the orchestrator moves on to other actionable tasks. Resolve the blocker on your own time; the next invocation picks up the unblocked work.

#"Pre-commit hook fails"

The Tech Lead diagnoses and fixes the underlying issue. Pre-commit hooks are never skipped — --no-verify is forbidden. If the hook reflects an outdated rule, fix the rule (and write the ADR to record the change), don't bypass it.

#"Merge conflict during fast-forward"

If main has advanced beyond the worktree's branch point, fast-forward fails. The orchestrator tries a merge commit; if that requires judgment, it pauses and reports — your git history is never modified silently.

#What it does not do

• Cross phase boundaries in a single session. If the current milestone is done, the command stops and asks you to confirm advancing to the next phase.
• Pick more tasks than the concurrency budget. If you set concurrent_tasks: 1, the command runs strictly sequentially.
• Skip the reviewer pipeline. Every diff merges only after code + security review (and any project specialists you've attached) clear at the configured severity threshold.

See Parallel execution for the worktree isolation model and Quality gates for the merge contract.

#Native looping

Pass --loop to iterate this command until the implementation plan is complete (or --max-iterations is reached). State lives in .synthex/loops/<loop-id>.json so the loop survives session restarts and crashes. See the Native looping framework explainer for the iteration contract.

Emission rule. The loop terminates when the agent emits <promise>{completion-promise}</promise> — and it does so only when either:

• Every task across all milestones and phases has status done, or
• exit_on_milestone_complete is true and every task in the current milestone is done.

The promise is not emitted just because no actionable work was picked up this iteration. Pending [H] reviews, blocked tasks, or unsatisfied dependencies all keep the loop alive — the next iteration picks up newly-unblocked work as you finish reviews in a parallel thread.

Example. Drive a plan to completion overnight, checkpoint at each milestone:

/synthex:next-priority --loop \
  --completion-promise "PLAN_DONE" \
  --max-iterations 30 \
  --name release-1 \
  exit_on_milestone_complete=true

Resume in a new session if you close Claude Code mid-loop:

/synthex:loop --resume release-1