/pm:next reads the current conductor state and tells you precisely what to work on. It follows a strict, deterministic decision rule so you never have to guess, names any blockers explicitly when it can’t advance, and surfaces genuine ties to you rather than making an arbitrary call. The output is always a single, concrete recommendation — the epic, and the specific story or phase within it to tackle.
Decision rule
PM applies the following order every time you call/pm:next:
1
Detour stack check (highest priority)
If the detour stack is non-empty, the next action is always to finish or resume the top frame. If the detour epic is already archived, PM triggers the reconcile gate via
/pm:resume. PM never starts new work while a detour is unresolved — the stack must be empty first.2
Priority queue (when stack is clear)
With an empty detour stack, PM selects the highest-priority
queued epic in P0 → P3 order. If the currently active epic still has open stories, that’s the default next action rather than switching epics. Any epic whose depends-on epic hasn’t been archived yet is skipped, and the blocker is named explicitly in the output.3
Tie-breaking and ambiguity
If two or more epics share the same priority with no clear differentiator, PM surfaces the tie to you and asks you to choose rather than picking arbitrarily. Ambiguity is always made visible, never silently resolved.
What it does after choosing
Once PM identifies the next epic, it makes that epic active by updatingstate.json atomically: the top-level .active pointer is set, the chosen epic’s status is set to active, and any previously-active epic is demoted back to queued. This keeps the briefing’s NOW line accurate without requiring you to manually update state.
PM then states the specific next story or phase to build — not just the epic name, but the concrete unit of work within it.