ultrawork

> 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`). <Purpose> Ultrawork is a parallel execution discipline for high-throughput task completion. It is a component, not a standalone persistence or verification mode: it provides parallelism, context discipline, and smart delegation guidance, but not durable goal tracking, Team's coordinated multi-worker lifecycle, Ralph's legacy persistence loop, architect sign-off, or long-running completion guarantees. </Purpose> <Use_When> - Multiple independent tasks can run simultaneously. - User says "ulw", "ultrawork", or explicitly wants parallel execution. - A task benefits from concurrent execution plus lightweight evidence before wrap-up. - You need a direct-tool lane plus optional background evidence lanes without entering Team or a durable goal workflow. </Use_When> <Do_Not_Use_When> - Task needs durable goal tracking, ledger checkpoints, or resume across stories — invoke the `ultragoal` skill instead. - Task needs coordinated workers, shared task state, or long-running parallel execution — spawn teammates via the Agent tool (the `team` pattern) instead. - Task requires a full autonomous pipeline — invoke the `autopilot` skill (default loop: `deep-interview` -> `ralplan` -> `ultragoal`, with Agent-tool teammates only when needed). - Task intentionally requires the legacy persistent single-owner completion/verification loop — invoke the `ralph` skill explicitly; do not present it as the default durable path. - There is only one sequential task with no parallelism opportunity — execute directly, use `ultragoal` for durable tracking, or delegate a single bounded task to an Agent. - The request is still in plan-consensus mode — keep planning artifacts in `ralplan` until execution is explicitly authorized. </Do_Not_Use_When> <Why_This_Exists> Sequential task execution wastes time when tasks are independent. Ultrawork keeps the execution branch fast while tightening the protocol: gather enough context first, define pass/fail acceptance criteria before editing, decide deliberately between local execution and delegation, and finish with evidence rather than vibes. </Why_This_Exists> <Execution_Policy> - Gather enough context before implementation. Start with the task intent, desired outcome, constraints, likely touchpoints, and any uncertainty that would change the execution path. - If uncertainty is still material after a quick repo read, do a focused evidence pass first instead of immediately editing. - Define pass/fail acceptance criteria before launching execution lanes. Include the command, artifact, or manual check that will prove success. - Prefer direct tool work when the task is small, coupled, or blocked on immediate local context. Delegate only when the work is independent enough to benefit from parallel execution. - When useful, run a direct-tool lane and one or more background evidence lanes at the same time. Evidence lanes can cover docs, tests, regression mapping, or bounded repo analysis. - Fire independent Agent calls simultaneously — never serialize independent work. - Read `references/agent-tiers.md` before first delegation for agent/role selection guidance. - Auto-delegate a `researcher` Agent when official docs, version-aware framework guidance, best practices, or external dependency behavior materially affect task correctness; treat it as an evidence lane, not a replacement primary workflow. - Use `run_in_background: true` for operations over ~30 seconds (installs, builds, tests). - Run quick commands (git status, file reads, simple checks) in the foreground. - Apply the shared workflow guidance: outcome-first framing, concise visible updates for speculative/blocked lanes, local overrides for the active workflow branch, evidence-backed validation, explicit stop rules, and continuation of clear safe execution branches instead of restarting or re-asking. - If the user says `continue`, continue the active workflow branch rather than restarting discovery or re-asking settled questions. </Execution_Policy> <Steps> 1. **Read agent reference**: Load `references/agent-tiers.md` for tier/role selection. 2. **Context + certainty check**: - State the task intent in one sentence. - List the constraints and unknowns that could invalidate a quick fix. - If confidence is low, explore first and narrow the task before editing. 3. **Define acceptance criteria before execution**: - What must be true at the end? - Which command or artifact proves it? - Which manual QA check is required, if any? - Record these in the task list (TaskCreate/TaskUpdate) or a short note in `.workbuddy/memory/YYYY-MM-DD.md`. 4. **Classify the work by dependency shape**: - Independent tasks -> parallel lanes (spawn multiple Agents in one message). - Shared-file or prerequisite-heavy tasks -> local execution or staged lanes. 5. **Choose self vs delegate deliberately**: - Work locally when the next step depends on immediate repo context, shared files, or tight iteration. - Delegate when the task slice is bounded, independent, and materially improves throughput. 6. **Run execution lanes**: - Direct-tool lane for immediate implementation or verification work. - Background evidence lanes for tests, docs, repo analysis, or regression checks. 7. **Run dependent tasks sequentially**: Wait for prerequisites before launching dependent work. 8. **Close with lightweight evidence**: - Build/typecheck passes when relevant. - Affected tests pass. - Manual QA notes are recorded when the task needs a human-visible or behavior-level check. - No new errors introduced. </Steps> <Tool_Usage> - Use LOW-tier delegation (a fast Agent) for simple lookups and bounded evidence gathering. - Use STANDARD-tier delegation for standard implementation and regression work. - Use THOROUGH-tier delegation for complex analysis, architectural review, or risky multi-file changes. - Prefer a direct-tool lane when the immediate next step is blocked on local context. - Prefer background evidence lanes when you can learn something useful in parallel with implementation. - Use `run_in_background: true` for package installs, builds, and test suites. - Use foreground execution for quick status checks and file operations. - Track lifecycle with TaskCreate/TaskUpdate (task list) and append progress notes to `.workbuddy/memory/YYYY-MM-DD.md`. Never shell out to `omx`. <Examples> <Good> Two-track execution with acceptance criteria up front: ``` Acceptance criteria: - `npm run build` passes - `node --test dist/scripts/__tests__/native-hook.test.js` passes - Manual QA: verify `ultrawork` activation still points to the session state file 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>