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).

<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>