Ultrawork

<Purpose>
Ultrawork is a parallel execution engine 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 tmux 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
• 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 -- use ultragoal instead
• Task needs coordinated tmux workers, shared task state, mailbox/dispatch coordination, or long-running parallel execution -- use team instead
• Task requires a full autonomous pipeline -- use autopilot instead (default loop: deep-interview -> ralplan -> ultragoal, with team only when needed)
• Task intentionally requires the legacy persistent single-owner completion/verification loop -- use ralph 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 to a single executor
• 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.
• Always pass the model parameter explicitly when delegating.
• Read references/agent-tiers.md before first delegation for agent selection guidance.
• Auto-delegate researcher 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 pattern: 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 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?
4. **Classify the work by dependency shape**:
   - Independent tasks -> parallel lanes.
   - 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 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. </Tool_Usage>