Ported from oh-my-codex ultrawork. OMX runtime conventions ($macro invocation,
omx CLI, .omx/ state directory) are replaced with WorkBuddy idioms
(Skill tool, Agent tool, task list, .workbuddy/memory).
Direct-tool lane:
- update
skills/ultrawork/SKILL.md
Background evidence lane:
- spawn a test-engineer Agent for this scoped task
Why good: Context is grounded first, acceptance criteria are explicit, and the direct-tool lane
runs alongside a bounded evidence lane.
</Good>
<Good>
Correct use of self-vs-delegate judgment:
Shared-file edit across src/scripts/native-hook.ts and its test -> keep implementation local.
Independent regression mapping for keyword-detector coverage -> delegate to a test-engineer Agent.
Why good: Shared-file work stays local; independent evidence work fans out.
</Good>
<Bad>
Parallelizing before the task is grounded:
spawn an executor Agent for this scoped task
spawn a test-engineer Agent for this scoped task
Why bad: No context snapshot, no pass/fail target, and delegation starts before the work is
shaped.
</Bad>
<Bad>
Claiming success without evidence or manual QA:
Made the changes. Ultrawork should be updated now.
Why bad: No verification output, no acceptance evidence, and no manual QA note when the behavior
is user-visible.
</Bad>
</Examples>
<Escalation_And_Stop_Conditions>
- When ultrawork is invoked directly, apply lightweight verification only — build/typecheck
passes when relevant, affected tests pass, and manual QA notes are captured when needed.
- Ultrawork does not own persistence, durable ledgers, architect verification, deslop, full QA,
or the full verified-completion promise. Do not claim those guarantees from direct ultrawork
alone.
- Escalate to `ultragoal` when the work needs durable goal state, story checkpoints, or resume
across implementation steps.
- Escalate to the `team` pattern (Agent-tool teammates) when the work needs coordinated workers,
shared task state, or durable multi-worker lifecycle control.
- Escalate to explicitly requested `ralph` only for the supported legacy single-owner
persistence/verification fallback.
- If a task fails repeatedly across retries, report the issue rather than retrying indefinitely.
- Escalate to the user when tasks have unclear dependencies, conflicting requirements, or a
materially branching acceptance target.
</Escalation_And_Stop_Conditions>
<Final_Checklist>
- [ ] Task intent and constraints were grounded before editing
- [ ] Pass/fail acceptance criteria were stated before execution
- [ ] Parallel lanes were used only for independent work
- [ ] Build/typecheck passes when relevant
- [ ] Affected tests pass
- [ ] Manual QA notes recorded when behavior is user-visible
- [ ] No new errors introduced
- [ ] Completion claim stays inside ultrawork's lightweight-verification boundary
</Final_Checklist>
<Advanced>
## Relationship to Other Modes
ultrawork (this skill)
-- provides: in-session parallel execution discipline + lightweight evidence
ultragoal (durable goal execution)
-- owns: goal ledger, checkpoints, resume across stories, final gate discipline
-- may use: Agent-tool teammates for parallel lanes when a story benefits from them
team (coordinated parallel execution via the Agent tool)
-- owns: multiple teammates, shared task state, handoff coordination, lifecycle control
-- can return: checkpoint-ready evidence to an Ultragoal leader
autopilot (strict autonomous delivery loop)
-- default flow: deep-interview -> ralplan -> ultragoal -> code-review -> ultraqa
-- may use: Agent-tool teammates only when an Ultragoal story needs parallel execution
ralph (supported legacy explicit fallback)
-- owns: single-owner persistence loop + architect verification when intentionally selected
Ultrawork is the parallelism and execution-discipline layer. Ultragoal is the current default
durable goal/ledger follow-up. The `team` pattern (Agent-tool teammates) is the coordinated
parallel runtime, often nested under an Ultragoal story when durable work needs multiple lanes.
Autopilot orchestrates the full default lifecycle through deep-interview, ralplan, ultragoal,
code-review, and ultraqa. Ralph remains active as an explicit legacy fallback for persistent
single-owner verification, but it is not the recommended default durable path.
</Advanced>
1---2name: ultrawork3description: Parallel execution engine for high-throughput task completion — ground context, set acceptance criteria, fan out independent work via the Agent tool, and close with lightweight evidence. Triggers: "ultrawork", "ulw", "parallel execution", "run tasks in parallel".4---56> Ported from oh-my-codex `ultrawork`. OMX runtime conventions (`$macro` invocation,7> `omx` CLI, `.omx/` state directory) are replaced with WorkBuddy idioms8> (Skill tool, Agent tool, task list, `.workbuddy/memory`).910<Purpose>11Ultrawork is a parallel execution discipline for high-throughput task completion. It is a12component, not a standalone persistence or verification mode: it provides parallelism,13context discipline, and smart delegation guidance, but not durable goal tracking, Team's14coordinated multi-worker lifecycle, Ralph's legacy persistence loop, architect sign-off, or15long-running completion guarantees.16</Purpose>1718<Use_When>19- Multiple independent tasks can run simultaneously.20- User says "ulw", "ultrawork", or explicitly wants parallel execution.21- A task benefits from concurrent execution plus lightweight evidence before wrap-up.22- You need a direct-tool lane plus optional background evidence lanes without entering Team23 or a durable goal workflow.24</Use_When>2526<Do_Not_Use_When>27- Task needs durable goal tracking, ledger checkpoints, or resume across stories — invoke the28 `ultragoal` skill instead.29- Task needs coordinated workers, shared task state, or long-running parallel execution —30 spawn teammates via the Agent tool (the `team` pattern) instead.31- Task requires a full autonomous pipeline — invoke the `autopilot` skill (default loop:32 `deep-interview` -> `ralplan` -> `ultragoal`, with Agent-tool teammates only when needed).33- Task intentionally requires the legacy persistent single-owner completion/verification loop —34 invoke the `ralph` skill explicitly; do not present it as the default durable path.35- There is only one sequential task with no parallelism opportunity — execute directly, use36 `ultragoal` for durable tracking, or delegate a single bounded task to an Agent.37- The request is still in plan-consensus mode — keep planning artifacts in `ralplan` until38 execution is explicitly authorized.39</Do_Not_Use_When>4041<Why_This_Exists>42Sequential task execution wastes time when tasks are independent. Ultrawork keeps the43execution branch fast while tightening the protocol: gather enough context first, define44pass/fail acceptance criteria before editing, decide deliberately between local execution and45delegation, and finish with evidence rather than vibes.46</Why_This_Exists>4748<Execution_Policy>49- Gather enough context before implementation. Start with the task intent, desired outcome,50 constraints, likely touchpoints, and any uncertainty that would change the execution path.51- If uncertainty is still material after a quick repo read, do a focused evidence pass first52 instead of immediately editing.53- Define pass/fail acceptance criteria before launching execution lanes. Include the command,54 artifact, or manual check that will prove success.55- Prefer direct tool work when the task is small, coupled, or blocked on immediate local56 context. Delegate only when the work is independent enough to benefit from parallel execution.57- When useful, run a direct-tool lane and one or more background evidence lanes at the same58 time. Evidence lanes can cover docs, tests, regression mapping, or bounded repo analysis.59- Fire independent Agent calls simultaneously — never serialize independent work.60- Read `references/agent-tiers.md` before first delegation for agent/role selection guidance.61- Auto-delegate a `researcher` Agent when official docs, version-aware framework guidance, best62 practices, or external dependency behavior materially affect task correctness; treat it as an63 evidence lane, not a replacement primary workflow.64- Use `run_in_background: true` for operations over ~30 seconds (installs, builds, tests).65- Run quick commands (git status, file reads, simple checks) in the foreground.66- Apply the shared workflow guidance: outcome-first framing, concise visible updates for67 speculative/blocked lanes, local overrides for the active workflow branch, evidence-backed68 validation, explicit stop rules, and continuation of clear safe execution branches instead of69 restarting or re-asking.70- If the user says `continue`, continue the active workflow branch rather than restarting71 discovery or re-asking settled questions.72</Execution_Policy>7374<Steps>751. **Read agent reference**: Load `references/agent-tiers.md` for tier/role selection.762. **Context + certainty check**:77 - State the task intent in one sentence.78 - List the constraints and unknowns that could invalidate a quick fix.79 - If confidence is low, explore first and narrow the task before editing.803. **Define acceptance criteria before execution**:81 - What must be true at the end?82 - Which command or artifact proves it?83 - Which manual QA check is required, if any?84 - Record these in the task list (TaskCreate/TaskUpdate) or a short note in85 `.workbuddy/memory/YYYY-MM-DD.md`.864. **Classify the work by dependency shape**:87 - Independent tasks -> parallel lanes (spawn multiple Agents in one message).88 - Shared-file or prerequisite-heavy tasks -> local execution or staged lanes.895. **Choose self vs delegate deliberately**:90 - Work locally when the next step depends on immediate repo context, shared files, or tight91 iteration.92 - Delegate when the task slice is bounded, independent, and materially improves throughput.936. **Run execution lanes**:94 - Direct-tool lane for immediate implementation or verification work.95 - Background evidence lanes for tests, docs, repo analysis, or regression checks.967. **Run dependent tasks sequentially**: Wait for prerequisites before launching dependent work.978. **Close with lightweight evidence**:98 - Build/typecheck passes when relevant.99 - Affected tests pass.100 - Manual QA notes are recorded when the task needs a human-visible or behavior-level check.101 - No new errors introduced.102</Steps>103104<Tool_Usage>105- Use LOW-tier delegation (a fast Agent) for simple lookups and bounded evidence gathering.106- Use STANDARD-tier delegation for standard implementation and regression work.107- Use THOROUGH-tier delegation for complex analysis, architectural review, or risky multi-file108 changes.109- Prefer a direct-tool lane when the immediate next step is blocked on local context.110- Prefer background evidence lanes when you can learn something useful in parallel with111 implementation.112- Use `run_in_background: true` for package installs, builds, and test suites.113- Use foreground execution for quick status checks and file operations.114- Track lifecycle with TaskCreate/TaskUpdate (task list) and append progress notes to115 `.workbuddy/memory/YYYY-MM-DD.md`. Never shell out to `omx`.116117<Examples>118<Good>119Two-track execution with acceptance criteria up front:120```121Acceptance criteria:122- `npm run build` passes123- `node --test dist/scripts/__tests__/native-hook.test.js` passes124- Manual QA: verify `ultrawork` activation still points to the session state file125126Direct-tool lane:127- update `skills/ultrawork/SKILL.md`128129Background evidence lane:130- spawn a test-engineer Agent for this scoped task131```132Why good: Context is grounded first, acceptance criteria are explicit, and the direct-tool lane133runs alongside a bounded evidence lane.134</Good>135136<Good>137Correct use of self-vs-delegate judgment:138```139Shared-file edit across `src/scripts/native-hook.ts` and its test -> keep implementation local.140Independent regression mapping for keyword-detector coverage -> delegate to a test-engineer Agent.141```142Why good: Shared-file work stays local; independent evidence work fans out.143</Good>144145<Bad>146Parallelizing before the task is grounded:147```148spawn an executor Agent for this scoped task149spawn a test-engineer Agent for this scoped task150```151Why bad: No context snapshot, no pass/fail target, and delegation starts before the work is152shaped.153</Bad>154155<Bad>156Claiming success without evidence or manual QA:157```158Made the changes. Ultrawork should be updated now.159```160Why bad: No verification output, no acceptance evidence, and no manual QA note when the behavior161is user-visible.162</Bad>163</Examples>164165<Escalation_And_Stop_Conditions>166- When ultrawork is invoked directly, apply lightweight verification only — build/typecheck167 passes when relevant, affected tests pass, and manual QA notes are captured when needed.168- Ultrawork does not own persistence, durable ledgers, architect verification, deslop, full QA,169 or the full verified-completion promise. Do not claim those guarantees from direct ultrawork170 alone.171- Escalate to `ultragoal` when the work needs durable goal state, story checkpoints, or resume172 across implementation steps.173- Escalate to the `team` pattern (Agent-tool teammates) when the work needs coordinated workers,174 shared task state, or durable multi-worker lifecycle control.175- Escalate to explicitly requested `ralph` only for the supported legacy single-owner176 persistence/verification fallback.177- If a task fails repeatedly across retries, report the issue rather than retrying indefinitely.178- Escalate to the user when tasks have unclear dependencies, conflicting requirements, or a179 materially branching acceptance target.180</Escalation_And_Stop_Conditions>181182<Final_Checklist>183- [ ] Task intent and constraints were grounded before editing184- [ ] Pass/fail acceptance criteria were stated before execution185- [ ] Parallel lanes were used only for independent work186- [ ] Build/typecheck passes when relevant187- [ ] Affected tests pass188- [ ] Manual QA notes recorded when behavior is user-visible189- [ ] No new errors introduced190- [ ] Completion claim stays inside ultrawork's lightweight-verification boundary191</Final_Checklist>192193<Advanced>194## Relationship to Other Modes195196```197ultrawork (this skill)198 \-- provides: in-session parallel execution discipline + lightweight evidence199200ultragoal (durable goal execution)201 \-- owns: goal ledger, checkpoints, resume across stories, final gate discipline202 \-- may use: Agent-tool teammates for parallel lanes when a story benefits from them203204team (coordinated parallel execution via the Agent tool)205 \-- owns: multiple teammates, shared task state, handoff coordination, lifecycle control206 \-- can return: checkpoint-ready evidence to an Ultragoal leader207208autopilot (strict autonomous delivery loop)209 \-- default flow: deep-interview -> ralplan -> ultragoal -> code-review -> ultraqa210 \-- may use: Agent-tool teammates only when an Ultragoal story needs parallel execution211212ralph (supported legacy explicit fallback)213 \-- owns: single-owner persistence loop + architect verification when intentionally selected214```215216Ultrawork is the parallelism and execution-discipline layer. Ultragoal is the current default217durable goal/ledger follow-up. The `team` pattern (Agent-tool teammates) is the coordinated218parallel runtime, often nested under an Ultragoal story when durable work needs multiple lanes.219Autopilot orchestrates the full default lifecycle through deep-interview, ralplan, ultragoal,220code-review, and ultraqa. Ralph remains active as an explicit legacy fallback for persistent221single-owner verification, but it is not the recommended default durable path.222</Advanced>
mrzhangguoguo