The pipeline
How a work item URL becomes a reviewed pull request.
When you give the lead agent a work item URL, execution follows this pipeline. If
the backlog platform is None, skip the work item stage. If the repository
platform is None, skip the pull request stage.
lead
↓
parse work item via userstory skill
↓
plan-propose
proposal + specs + tasks
↓
[confirm with user]
↓
wave of subagents (*-engineer, per-tier model)
each implements its assigned tasks → returns result → lead commits group
↓
verify (tests, build, lint as needed)
↓
lead (ship mode, if configured)
commit → push → pull request → feedback loop- Load the platform userstory skill (installed as
pc-userstory, from the variant matching your backlog platform) - Run
/plan-proposeto produceproposal.md, specs andtasks.md - Confirm with the user before implementation
- Run
/plan-applyto orchestrate implementation in waves - Each wave spawns engineers in parallel (custom
*-engineerspecialists, each carrying its own tier model), capped atagents.maxConcurrent - Each subagent receives its task IDs in its prompt, loads relevant abilities, implements, and returns; the lead commits each group
- Verify with tests, build and lint according to task scope
- Ship or update the pull request via the lead flow
Unattended runs
Keep a shell task as the final gate
For unattended loop runs, end with a concrete shell verification task as the exit-code gate.
Inside /plan-goal, /plan-apply step 10 runs lint, typecheck, test, and build commands and is
the checks gate; /repo-verify then writes verification-plan.md — a reproduction journey for a
later agent-browser executor. The shell task independently proves the critical commands passed
before any commit or pull request action.
Watching a run
Agents run as native OpenCode subagents in parallel waves: no external plugin, no
git worktrees. The lead's Todo pane is the live board, and the
pc-subagent-monitor plugin mirrors state to .opencode/harness-run.json. Navigate
into any running subagent with ctrl+x ↓ then
←/→.