Gather context. Read the issue body, labels, blockers, and any repo docs that define branching or orchestration rules.
Parse the orchestration label. Extract:
- stage number N
- lane letter for parallel stages
- chat id C
Choose the issue. If the user explicitly provided an issue number, inspect that issue first instead of auto-picking. If no issue number was provided, start only unblocked work and auto-pick the next valid issue. For auto-pick mode, prefer the lowest dependency stage number. Within the same stage, prefer the lowest issue number unless the user specifies a different lane or issue. Do not start a higher required stage while a lower one is still open or unmerged. If the explicitly requested issue is blocked, missing the required orchestration label, or otherwise not ready, do not silently switch to another issue. Explain why it cannot start and stop for user confirmation.
Handle convergence before selecting new foundation work. If the next issue is a foundation stage whose previous dependency stage was parallel, first confirm whether the completed parallel branches should now merge into dev. Do not start the new foundation issue yet. Ask the user for explicit approval to merge. If the user approves, merge the required parallel branches into dev one at a time in ascending issue number unless the user specifies a different order. If any merge conflicts, stop and ask before resolving it. Create the merge commit(s), close the merged parallel issues, and only then continue to the new foundation issue.
Confirm the chat before implementing. After selecting the issue, tell the user:
- selected issue
- parsed orchestration label
- why it is unblocked
- chosen base branch or worktree
- expected commit message format
If the issue was user-specified, mention that it was selected explicitly rather than by auto-pick. Ask Proceed in this chat? before coding so the user can verify this is the correct chat for that issue.
Choose the workspace strategy.
- f<N>-<C>: work on the local dev branch
- p<N><L>-<C>: create or use a separate worktree and create branch issue/<issue-number>
If issue/<issue-number> already exists locally or remotely, reuse it only if it clearly belongs to that issue. Otherwise stop and ask before creating or reusing a branch or worktree.
Choose the base commit correctly.
- foundation stages build on the latest dev commit that already contains the previous required stage
- parallel stages branch from the latest dev commit that already contains the immediately previous dependency stage
- convergence foundation stages after a parallel fanout start only after every required parallel lane for the prior stage is merged back into dev
Implement the issue. Keep the issue scope narrow. Respect the blocker graph from the issue body and orchestration label.
Verify, commit, push, and close the issue correctly. Run the relevant verification for the change. Commit with the required format: Use:
- #120 Refactor preview class
- #121 Cover all cases
Format rule: #<issue-number> <imperative or descriptive summary> Push the branch to the remote. If this is foundation work being delivered on dev, close the GitHub issue with a comment that includes the branch name and commit SHA or merge SHA. If this is parallel work on issue/<issue-number>, do not close the issue just because the branch was pushed. Close it when that branch is merged into dev, and include a closing comment with the branch name and merge SHA, or follow the repo's explicit policy if it differs.

Decision rules

Do not treat the chat suffix as a dependency signal. The stage number defines ordering.
Parallel siblings in the same stage may start from the same parent commit and proceed independently.
A later foundation stage must not start until all required parallel siblings from the prior stage are merged into dev.
When a completed parallel stage unlocks a new foundation stage, ask before merging those parallel branches into dev.
Closing rules depend on integration state, not just push state. A pushed parallel branch is not automatically complete.
If the correct base is unclear, inspect merged history and blocker issues before coding.
An explicit issue number overrides auto-selection, but it does not override blocker, dependency, merge, or branch-base rules.
Never reinterpret do-work 67 as "pick something near 67" or "pick the next available issue". It means GitHub issue #67.

Example

Explicit target:

do-work 67
inspect GitHub issue #67
if #67 is unblocked and labeled correctly, prepare the workspace for #67
if #67 is blocked or not orchestrated correctly, report that and stop instead of switching issues

For labels:

f1-1
f2-1
p3a-2
p3b-3
f4-1

Execution order:

f1-1 on dev
f2-1 on dev
p3a-2 in a worktree on branch issue/<issue-number> based on the dev commit after f2-1
p3b-3 in a separate worktree on branch issue/<issue-number> based on the same f2-1 result
when p3a, p3b, and any other required p3* lanes are done, ask whether to merge them into dev
after approval, merge those branches into dev and close the merged p3* issues
then pick up f4-1 on dev

Output

Before implementation, state:

selected issue
parsed orchestration label
why it is unblocked
chosen base branch or worktree
expected commit message format

If the issue is a convergence foundation stage after parallel work, ask first whether to merge the completed parallel branches into dev.

Then ask for confirmation that this is the correct chat for the issue.

do-work

Do Work

Process