DOCS · REFERENCE · COMMANDS · BUILD

next-priority/synthex:next-priority

Build

Pick top tasks, spin up worktrees, delegate to Tech Lead instances in parallel.

Invocation

Run from inside Claude Code in any project where Synthex is installed:

/synthex:next-priority

Some commands accept parameters; see the source-of-truth file linked below for the full parameter list and workflow.

Lifecycle phase

Build. Parallel-executed, peer-reviewed task delivery.

  • Tech Lead · Full-stack orchestrator. Breaks tasks down, delegates to specialists, rolls up the result.
  • Lead Frontend Engineer · Coordinates frontend delivery, enforces UX quality, accessibility, and design-system fidelity.
  • Architect · System design, ADRs, plan-review feasibility, technology trade-offs.
  • Code Reviewer · Craftsmanship review — correctness, maintainability, reuse, conventions.
  • Security Reviewer · Mandatory gate. Secrets, injection, auth, supply chain, OWASP.
  • Quality Engineer · Test strategy, gap analysis, behavior-driven test authoring.
  • Design System · Token ownership, component governance, compliance audit.
  • Technical Writer · API docs, guides, migrations, changelogs verifiable against code.

Source

The command's parameters, workflow, and sub-agent invocations are defined in markdown at bluminal/lumenai/blob/main/plugins/synthex/commands/next-priority.md.

Last modified:

What it does, end-to-end

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

ParameterDescriptionDefaultRequired
implementation_plan_pathPath to the plan markdown filedocs/plans/main.mdNo
concurrent_tasksMaximum tasks to execute in parallelValue from next_priority.concurrent_tasks config (or 3)No
exit_on_milestone_completeInside a Ralph Loop, output the completion signal after a milestone even if later milestones remainfalseNo

When to run it

You re-run next-priority/synthex:next-priority after every batch you finish. Some teams run it once per work session; others wrap it in a Ralph Loop (a Claude Code plugin pattern that re-invokes a command iteratively until the plan is complete or a configured completion-promise fires).

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 output the Ralph Loop completion signal 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.