Agent Skills: MANDATORY RULES: VIOLATION IS FORBIDDEN

Ultrawork - high-quality 5-phase development workflow with 11 review steps out of 17

UncategorizedID: first-fluke/fullstack-starter/ultrawork

Install this agent skill to your local

pnpm dlx add-skill https://github.com/first-fluke/fullstack-starter/tree/HEAD/.qwen/skills/ultrawork

Skill Files

Browse the full folder contents for ultrawork.

Download Skill

Loading file tree…

.qwen/skills/ultrawork/SKILL.md

Skill Metadata

Name
ultrawork
Description
Ultrawork - high-quality 5-phase development workflow with 12 review steps out of 17

MANDATORY RULES: VIOLATION IS FORBIDDEN

  • Response language follows language setting in .agents/oma-config.yaml if configured.
  • NEVER skip steps. Execute from Step 0 in order. Explicitly report completion of each step to the user before proceeding to the next.
  • You MUST use MCP tools throughout the entire workflow. This is NOT optional.
    • Use code analysis tools (get_symbols_overview, find_symbol, find_referencing_symbols, search_for_pattern) for code exploration.
    • Use memory tools (read/write/edit) for progress tracking.
    • Memory path: configurable via memoryConfig.basePath (default: .agents/state/memories)
    • Tool names: configurable via memoryConfig.tools in .agents/mcp.json
    • Do NOT use raw file reads or grep as substitutes. MCP tools are the primary interface for code and memory operations.
  • Read the oma-coordination skill BEFORE starting. Read .agents/skills/oma-coordination/SKILL.md and follow its Core Rules.
  • Follow the context-loading guide. Read .agents/skills/_shared/core/context-loading.md and load only task-relevant resources.

Vendor Detection

Before starting, determine your runtime environment by following .agents/skills/_shared/core/vendor-detection.md. The detected runtime vendor and each agent's target vendor determine how agents are spawned in Phase 2 (IMPL), Phase 3 (VERIFY), Phase 4 (REFINE), and Phase 5 (SHIP).


Cross-Context Review (CCR) Dispatch

Every review step in this workflow (the 12 reviews in multi-review-protocol.md) runs as a fresh, context-isolated reviewer subagent — never inline in the main session, and never batched with implementation or with another review. This is mandatory; see the Cross-Context Review (CCR) Mandate in multi-review-protocol.md for the rationale and the two papers behind it.

One review = one fresh reviewer subagent. The main session is the coordinator: it dispatches each review, waits for its verdict, and aggregates verdicts into the phase's result-*.md and session-ultrawork.md. For each review:

  1. Resolve the reviewer's target vendor per the Per-Agent Dispatch rules (.agents/oma-config.yaml). Use the native subagent path when target_vendor === current_runtime_vendor; otherwise use oma agent:spawn for that reviewer.
  2. Build the reviewer prompt from the isolation contract only (multi-review-protocol.md → CCR Mandate): the durable artifacts under review referenced by path (git diff, changed files, .agents/results/plan-{sessionId}.json, prior result-*.md, test/lint output) plus that single review's guide section. Do NOT paste this session's conversation history, the implementation agent's reasoning, or any prior review's verdict into the prompt.
  3. Dispatch one reviewer per review.
    • Claude-native: Agent(subagent_type="qa-reviewer", prompt="CCR <review name> ONLY. Inputs (read fresh, assume no prior context): <artifact paths>. Guide: <that review's section>. Write a structured verdict to memory.", run_in_background=true) — multiple such calls in one message run in parallel, each in its own isolated context.
    • CLI fallback: oma agent:spawn qa-agent "CCR <review name> ONLY. Inputs (read fresh, assume no prior context): <artifact paths>. Guide: <that review's section>. Write a structured verdict to memory." session-id
  4. Collect each reviewer's structured verdict from memory and fold it into the phase's result-*.md and session-ultrawork.md.

Reviewers are read-only evaluators. Implementation and refactor actions (Phase 2 IMPL, and the structural refactor steps in Phase 4) remain with their action agents and are dispatched as before — only the review passes are isolated.


Phase 0: Initialization (DO NOT SKIP)

  1. Read .agents/skills/oma-coordination/SKILL.md and confirm Core Rules.
  2. Read .agents/skills/_shared/core/context-loading.md for resource loading strategy.
  3. Read .agents/skills/_shared/runtime/memory-protocol.md for memory protocol.
  4. Read .agents/skills/_shared/runtime/event-spec.md for L1 event protocol.
  5. Emit required L1 decisions by calling oma state:emit directly, as documented in .agents/skills/_shared/runtime/event-spec.md.
  6. Read .agents/workflows/ultrawork/resources/multi-review-protocol.md (12 review guides)
  7. Read .agents/skills/_shared/core/quality-principles.md (4 principles)
  8. Read .agents/workflows/ultrawork/resources/phase-gates.md (gate definitions)
  9. Resolve the session ID:
    • If a caller workflow (e.g. /ralph) delegated to ultrawork with an existing sessionId, reuse it verbatim — all plan-{sessionId}.json / result-*-{sessionId}.md artifacts must carry the caller's id so artifact verification (oma ralph:verify --session) matches.
    • Otherwise generate one now (format: YYYYMMDD-HHmmss).
  10. Record session start using memory write tool:
  • Create session-ultrawork.md in the memory base path
  • Include: session start time, session ID, user request summary, workflow version (ultrawork)
  1. (Recommended) Attach a mechanical stop gate when the project has a cheap deterministic check:
  • oma goal:set --gate typecheck (allowlist: typecheck | test | lint; maps to the package.json script)
  • While set, the Stop hook allows the session to end only when the gate passes; failures return the output tail. Add --budget-minutes <n> to bound unattended runs with an honest partial stop.

Phase 1: PLAN (Steps 1-4)

Step 1: Create Plan

// turbo Activate PM Agent to author the plan only (reviews are dispatched separately in Steps 2-4):

  1. Analyze requirements.
  2. Define API contracts.
  3. Create a prioritized task breakdown.
  4. Save plan to .agents/results/plan-{sessionId}.json.
  5. Create task-board.md in memory path for dashboard compatibility.
  6. Use memory write tool to record plan completion.

The PM Agent MUST NOT review its own plan inline — that is a same-context self-review, exactly the anchoring/sycophancy failure the CCR Mandate forbids. Steps 2-4 run in fresh isolated reviewers.

Steps 2-4: Plan Reviews (Cross-Context)

Dispatch each of Steps 2, 3, 4 as a separate fresh isolated reviewer subagent per the Cross-Context Review (CCR) Dispatch section. Each reviewer receives ONLY the plan artifact (.agents/results/plan-{sessionId}.json) and the original requirements, plus its own review guide section — never the PM Agent's reasoning or this session's history. Collect the three verdicts into session-ultrawork.md before evaluating PLAN_GATE.

Step 2: Plan Review (Completeness)

  • Executed by a fresh isolated reviewer subagent (CCR): Ensure requirements are fully mapped.

Step 3: Review Verification (Meta Review)

  • Executed by a fresh isolated reviewer subagent (CCR): Verify the completeness review was sufficient. Chaining exception: this reviewer MAY receive the Step 2 verdict as input, since a meta-review's job is to audit the prior review.

Step 4: Over-Engineering Review (Simplicity)

  • Executed by a fresh isolated reviewer subagent (CCR): Check for unnecessary complexity (MVP focus).

PLAN_GATE

  • [ ] Plan documented
  • [ ] Assumptions listed
  • [ ] Alternatives considered
  • [ ] Over-engineering review done
  • [ ] User confirmation

On gate pass:

  1. Use memory edit tool to record phase completion in session-ultrawork.md.
  2. Emit the required L1 decision:
    oma state:emit "decision.made" '{"subject":"ultrawork.plan-approved","decision":"Proceed with the approved PLAN output.","rationale":"PLAN_GATE passed and the user confirmed scope."}'
    
  3. Verify the required decision before Phase 2:
    oma state:verify --workflow ultrawork --checkpoint plan-approved
    
  4. Emit and verify the implementation scope lock before spawning implementation agents:
    oma state:emit "decision.made" '{"subject":"ultrawork.impl-plan-locked","decision":"Use the approved task decomposition for IMPL.","rationale":"PLAN output is locked before implementation agents are spawned."}'
    oma state:verify --workflow ultrawork --checkpoint impl-plan-locked
    

Gate failure → Return to Step 1


Phase 2: IMPL (Step 5)

Step 5: Implementation

// turbo Spawn Implementation Agents (Backend/Frontend/Mobile) in parallel.

Per-Agent Dispatch

Resolve the target vendor for each agent from .agents/oma-config.yaml. Use native subagents only when target_vendor === current_runtime_vendor and that runtime supports the vendor's role-subagent path. Otherwise use oma agent:spawn for that agent.

If Claude Code and target vendor is Claude

Use the Agent tool to spawn subagents:

  • Agent(subagent_type="backend-engineer", prompt="Implement backend tasks per plan. IMPORTANT: Follow .agents/skills/_shared/core/context-loading.md rules.", run_in_background=true)
  • Agent(subagent_type="frontend-engineer", prompt="Implement frontend tasks per plan. IMPORTANT: Follow .agents/skills/_shared/core/context-loading.md rules.", run_in_background=true)
  • Multiple Agent tool calls in the same message = true parallel execution

If Codex CLI and target vendor is Codex

Spawn native Codex custom agents using .codex/agents/{agent}.toml when available. Pass each agent its task description, API contracts, and relevant context. If native dispatch is not verified in the current runtime, fall back to oma agent:spawn.

If Gemini CLI and target vendor is Gemini

Use native Gemini subagents when available, otherwise fall back to oma agent:spawn.

If target vendor differs from current runtime, or native dispatch is unavailable

oma agent:spawn backend "Implement backend tasks per plan. IMPORTANT: Follow .agents/skills/_shared/core/context-loading.md rules." session-id -w ./backend &
oma agent:spawn frontend "Implement frontend tasks per plan. IMPORTANT: Follow .agents/skills/_shared/core/context-loading.md rules." session-id -w ./frontend &
wait

Step 5.1: Monitor & Wait for Completion

Wait for all implementation agents to complete before proceeding.

  1. Use memory read tool to poll progress-{agent}[-{sessionId}].md files
  2. Use MCP code analysis tools to verify implementation alignment
  3. Check for result-{agent}[-{sessionId}].md files to confirm completion
  4. Use memory edit tool to record monitoring results in session-ultrawork.md

Continue polling until all agents report completion or failure.

Step 5.2: Measure Baseline Quality Score (Conditional)

If automated measurement is available (tests, lint exist):

  1. Load quality-score.md (conditional, per context-loading.md)
  2. Run tests, lint, type-check via Bash to measure baseline
  3. Create Experiment Ledger via memory tools: [WRITE]("experiment-ledger.md", initial ledger with baseline row)
  4. Record composite score as the IMPL baseline

If no measurement tools: skip; gates fall back to binary checklist.

IMPL_GATE

  • [ ] Build succeeds
  • [ ] Tests pass
  • [ ] Only planned files modified
  • [ ] (If measured) Baseline Quality Score recorded in Experiment Ledger

On gate pass: Use memory edit tool to record phase completion in session-ultrawork.md

Gate failure → Return to Step 5, re-spawn failed agents, and repeat monitoring until GATE passes.


Phase 3: VERIFY (Steps 6-8)

Step 6-8: QA Verification (Cross-Context Review)

// turbo Dispatch each of Steps 6, 7, 8 as a separate fresh isolated reviewer subagent per the Cross-Context Review (CCR) Dispatch section. Do NOT run all three in one agent, and do NOT pass this session's history or the implementation agents' reasoning into any reviewer prompt. Each reviewer reads only the durable artifacts (git diff, changed files, .agents/results/plan-{sessionId}.json, result-{agent} files, test/lint output) plus its own review guide section from multi-review-protocol.md.

If Claude Code

Use three separate Agent tool calls (one message = parallel, isolated contexts):

  • Agent(subagent_type="qa-reviewer", prompt="CCR Step 6 Alignment Review ONLY. Inputs (read fresh, assume no prior context): <diff + changed files + plan-{sessionId}.json>. Guide: Alignment Review section. Write a structured verdict to memory.", run_in_background=true)
  • Agent(subagent_type="qa-reviewer", prompt="CCR Step 7 Security/Bug Review ONLY (npm audit, OWASP). Inputs (read fresh, assume no prior context): <diff + changed files + audit output>. Guide: Safety Review section. Write a structured verdict to memory.", run_in_background=true)
  • Agent(subagent_type="qa-reviewer", prompt="CCR Step 8 Improvement/Regression Review ONLY. Inputs (read fresh, assume no prior context): <diff + test output>. Guide: Regression Review section. Write a structured verdict to memory.", run_in_background=true)

If Codex CLI

Spawn one native Codex custom agent (.codex/agents/{agent}.toml) per review when available, each with only its artifacts + guide section. If native dispatch is not verified in the current runtime, fall back to oma agent:spawn.

If Gemini CLI or Antigravity or CLI Fallback

oma agent:spawn qa-agent "CCR Step 6 Alignment Review ONLY. Inputs (read fresh): <diff + plan-{sessionId}.json>. Guide: Alignment Review section. Write a structured verdict to memory." session-id
oma agent:spawn qa-agent "CCR Step 7 Security/Bug Review ONLY (npm audit, OWASP). Inputs (read fresh): <diff + audit output>. Guide: Safety Review section. Write a structured verdict to memory." session-id
oma agent:spawn qa-agent "CCR Step 8 Regression Review ONLY. Inputs (read fresh): <diff + test output>. Guide: Regression Review section. Write a structured verdict to memory." session-id

Monitor Reviewers & Aggregate

Wait for all three VERIFY reviewers to complete before proceeding.

  1. Use memory read tool to poll each reviewer's progress-* / verdict entry.
  2. Confirm each reviewer wrote its structured verdict to memory.
    • Claude-native path: each qa-reviewer Agent call returns synchronously with its verdict.
  3. Aggregate the three verdicts into result-qa-{sessionId}.md under .agents/results/ (this satisfies the VERIFY artifact contract) and record the combined VERIFY result in session-ultrawork.md.

Continue polling until all three reviewers report completion.

Step 6: Alignment Review

  • Executed by a fresh isolated reviewer subagent (CCR): Compare implementation vs plan.

Step 7: Security/Bug Review (Safety)

  • Executed by a fresh isolated reviewer subagent (CCR): Check for vulnerabilities (Safety).

Step 8: Improvement Review (Regression Prevention)

  • Executed by a fresh isolated reviewer subagent (CCR): Run regression tests.

Step 8.1: Measure Post-VERIFY Quality Score (Conditional)

If baseline was measured at Step 5.2:

  1. Measure Quality Score incorporating QA findings
  2. Calculate delta from IMPL baseline
  3. Record as experiment in Experiment Ledger via memory tools

VERIFY_GATE

  • [ ] Implementation = Requirements
  • [ ] CRITICAL count: 0
  • [ ] HIGH count: 0
  • [ ] No regressions
  • [ ] (If measured) Quality Score >= 75 (Grade B)

On gate pass: Use memory edit tool to record phase completion in session-ultrawork.md

Gate failure (1st time) → Before re-spawning for the next VERIFY cycle, check the session cost cap:

Review Loop termination conditions (OR, whichever fires first wins):

  1. Gate failure count has reached the configured maximum iterations (default: 5 total VERIFY + REFINE cycles). Do not start another cycle.
  2. Session cost cap exceeded: if loadQuotaCap() from cli/io/session-cost.ts returns non-null, call checkCap(sessionId, cap) (no cap configured → skip this condition). If exceeded === true, print formatPromptMessage(result) to the user and stop the loop immediately. Save all current step results before stopping, then report to the user that the loop was terminated early due to quota.

If neither condition is met, return to Step 5 and continue.

Root-cause-first fix mandate: when re-spawning implementation agents to address QA findings, the fix prompt MUST require root-cause remediation. Forbid tactical patches (try/catch swallowing the error, validation bypass, hardcoded values, feature flags hiding the bug, silencing the failing test) unless the agent explicitly justifies why a structural fix is out of scope (upstream library bug, deprecated path, hotfix window).

Gate failure (2nd time on same issue, and termination conditions not yet met) → Activate Exploration Loop:

  1. Load exploration-loop.md (conditional, per context-loading.md)
  2. Generate 2-3 alternative hypotheses that differ in mechanism, each scoped to at most 3 files
  3. Experiment each approach sequentially (git stash per attempt)
  4. Measure Quality Score for each
  5. Select the highest-scoring approach
  6. Record all experiments in Experiment Ledger
  7. Resume VERIFY with winning approach

Phase 4: REFINE (Steps 9-13)

Step 9-13: Deep Refinement

// turbo REFINE mixes two kinds of work: reviews (Steps 10, 12), which are read-only evaluations, and refactor actions (Steps 9, 11, 13), which change code.

First, dispatch the two reviews as fresh isolated reviewer subagents per the Cross-Context Review (CCR) Dispatch section — one reviewer for Step 10 (Reusability), one for Step 12 (Consistency). Each reads only the durable artifacts (git diff, changed files) plus its guide section; do not pass this session's history or the implementation agents' reasoning. Collect their verdicts from memory.

Then, spawn the Refactor Agent to perform the refactor actions (Steps 9, 11, 13) and apply the isolated reviewers' findings, and to write result-refactor-{sessionId}.md (this satisfies the REFINE artifact contract).

If Claude Code

Reviews (two separate calls, isolated contexts):

  • Agent(subagent_type="qa-reviewer", prompt="CCR Step 10 Reusability Review ONLY. Inputs (read fresh, assume no prior context): <diff + changed files>. Guide: Reusability Review section. Write a structured verdict to memory.", run_in_background=true)
  • Agent(subagent_type="qa-reviewer", prompt="CCR Step 12 Consistency Review ONLY. Inputs (read fresh, assume no prior context): <diff + changed files>. Guide: Consistency Review section. Write a structured verdict to memory.", run_in_background=true)

Refactor actions (after the review verdicts are collected):

  • Agent(subagent_type="refactor-engineer", prompt="Execute Phase 4 refactor actions. Step 9: Split large files. Step 11: Side Effect analysis (find_referencing_symbols). Step 13: Cleanup dead code. Apply the collected Reusability/Consistency verdicts. Write result-refactor-{sessionId}.md. IMPORTANT: Follow .agents/skills/_shared/core/context-loading.md rules.", run_in_background=true)

If Codex CLI

Spawn one native Codex reviewer per review (.codex/agents/{agent}.toml) with only its artifacts + guide section, then the native refactor agent (.codex/agents/refactor-engineer.toml) for Steps 9/11/13. If native dispatch is not verified in the current runtime, fall back to oma agent:spawn.

If Gemini CLI or Antigravity or CLI Fallback

oma agent:spawn qa-agent "CCR Step 10 Reusability Review ONLY. Inputs (read fresh): <diff>. Guide: Reusability Review section. Write a structured verdict to memory." session-id
oma agent:spawn qa-agent "CCR Step 12 Consistency Review ONLY. Inputs (read fresh): <diff>. Guide: Consistency Review section. Write a structured verdict to memory." session-id
oma agent:spawn refactor-engineer "Execute Phase 4 refactor actions. Step 9: Split large files. Step 11: Side Effect analysis. Step 13: Cleanup dead code. Apply the collected Reusability/Consistency verdicts. Write result-refactor-{sessionId}.md. IMPORTANT: Follow .agents/skills/_shared/core/context-loading.md rules." session-id

Monitor Reviewers & Refactor Agent Progress

Wait for the two reviewers and the Refactor Agent to complete refinement before proceeding.

  1. Confirm both isolated reviewers wrote their structured verdicts to memory.
  2. Use memory read tool to poll progress-refactor*[-{sessionId}].md
  3. Check for result-refactor-{sessionId}.md (the filename instructed in the dispatch prompt) to confirm completion. Accept result-refactor-engineer-{sessionId}.md as an equivalent — the CLI-fallback default naming (result-{agent-id}-{sessionId}.md per memory-protocol) produces it when the agent ignores the prompt-specified name.
    • Claude-native path: the Agent tool returns synchronously and the refactor-engineer subagent writes result-refactor-{sessionId}.md under .agents/results/ — check that file instead of polling.
  4. Use memory edit tool to record refinement results (reviews + actions) in session-ultrawork.md

Continue polling until the reviewers and Refactor Agent report completion.

Step 9: Split Large Files/Functions

  • Executed by Refactor Agent (action): Files > 500 lines, Functions > 50 lines.

Step 10: Integration/Reuse Review (Reusability)

  • Executed by a fresh isolated reviewer subagent (CCR): Check for duplicate logic.

Step 11: Side Effect Review (Cascade Impact)

  • Executed by Refactor Agent (action): Analyze impact scope.

Step 12: Full Change Review (Consistency)

  • Executed by a fresh isolated reviewer subagent (CCR): Review naming and style.

Step 13: Clean Up Unused Code

  • Executed by Refactor Agent (action): Remove newly created dead code.

Step 13.1: Measure Post-REFINE Quality Score (Conditional)

If baseline was measured at Step 5.2:

  1. Measure Quality Score after refinement
  2. Calculate delta from Post-VERIFY score
  3. If delta < -5: Apply Discard rule. Revert refinement changes, record in Experiment Ledger.
  4. Record kept experiments in Experiment Ledger

REFINE_GATE

  • [ ] No large files/functions
  • [ ] Integration opportunities captured
  • [ ] Side effects verified
  • [ ] Code cleaned
  • [ ] (If measured) Quality Score >= Post-VERIFY score (no regression from refinement)

On gate pass:

  1. Use memory edit tool to record phase completion in session-ultrawork.md.
  2. Emit and verify the REFINE outcome decision:
    oma state:emit "decision.made" '{"subject":"ultrawork.refine-outcome","decision":"Keep the REFINE changes or explicitly skip refinement.","rationale":"REFINE_GATE passed or the documented skip condition applies."}'
    oma state:verify --workflow ultrawork --checkpoint refine-outcome
    

Gate failure → Before re-spawning the Refactor Agent, apply the same termination check:

Review Loop termination conditions (OR, whichever fires first wins):

  1. Total REFINE failure count has reached the configured maximum iterations (default: 5 cycles across all phases). Do not start another cycle.
  2. Session cost cap exceeded: if loadQuotaCap() from cli/io/session-cost.ts returns non-null, call checkCap(sessionId, cap) (no cap configured → skip this condition). If exceeded === true, print formatPromptMessage(result) to the user and stop. Save current step results before stopping, then report early termination due to quota.

If neither condition is met, re-spawn the Refactor Agent with specific issues and repeat until GATE passes.

Skip conditions: Simple tasks < 50 lines


Phase 5: SHIP (Steps 14-17)

Step 14-17: Final QA & Deployment Readiness (Cross-Context Review)

// turbo Dispatch each of Steps 14, 15, 16, 17 as a separate fresh isolated reviewer subagent per the Cross-Context Review (CCR) Dispatch section. Do NOT run them in one agent, and do NOT pass this session's history or the implementation/refine agents' reasoning into any reviewer prompt. Each reviewer reads only the durable artifacts (git diff, changed files, lint/coverage output, prior result-*.md) plus its own review guide section.

If Claude Code

Use separate Agent tool calls (one message = parallel, isolated contexts):

  • Agent(subagent_type="qa-reviewer", prompt="CCR Step 14 Code Quality Review ONLY (lint/coverage). Inputs (read fresh, assume no prior context): <diff + lint/coverage output>. Guide: Quality Review section. Write a structured verdict to memory.", run_in_background=true)
  • Agent(subagent_type="qa-reviewer", prompt="CCR Step 15 UX Flow Verification ONLY. Inputs (read fresh, assume no prior context): <diff + user journey/routes>. Guide: UX Flow Review section. Write a structured verdict to memory.", run_in_background=true)
  • Agent(subagent_type="qa-reviewer", prompt="CCR Step 16 Related Issues / Cascade Impact Review ONLY. Inputs (read fresh, assume no prior context): <diff + find_referencing_symbols impact>. Guide: Cascade Impact Review section. Write a structured verdict to memory.", run_in_background=true)
  • Agent(subagent_type="qa-reviewer", prompt="CCR Step 17 Deployment Readiness Review ONLY. Inputs (read fresh, assume no prior context): <diff + secrets/migrations checklist>. Guide: Final Review section. Write a structured verdict to memory.", run_in_background=true)

If Codex CLI

Spawn one native Codex reviewer per review (.codex/agents/{agent}.toml) when available, each with only its artifacts + guide section. If native dispatch is not verified in the current runtime, fall back to oma agent:spawn.

If Gemini CLI or Antigravity or CLI Fallback

oma agent:spawn qa-agent "CCR Step 14 Code Quality Review ONLY (lint/coverage). Inputs (read fresh): <diff + lint output>. Guide: Quality Review section. Write a structured verdict to memory." session-id
oma agent:spawn qa-agent "CCR Step 15 UX Flow Verification ONLY. Inputs (read fresh): <diff + routes>. Guide: UX Flow Review section. Write a structured verdict to memory." session-id
oma agent:spawn qa-agent "CCR Step 16 Cascade Impact Review ONLY. Inputs (read fresh): <diff + impact>. Guide: Cascade Impact Review section. Write a structured verdict to memory." session-id
oma agent:spawn qa-agent "CCR Step 17 Deployment Readiness Review ONLY. Inputs (read fresh): <diff + checklist>. Guide: Final Review section. Write a structured verdict to memory." session-id

Monitor Reviewers & Aggregate

Wait for all SHIP reviewers to complete final review before proceeding.

  1. Confirm each reviewer wrote its structured verdict to memory.
    • Claude-native path: each qa-reviewer Agent call returns synchronously with its verdict.
  2. Aggregate the verdicts into result-qa-{sessionId}.md under .agents/results/ (this satisfies the SHIP artifact contract) and record the combined final result in session-ultrawork.md.

Continue polling until all SHIP reviewers report completion.

Step 14: Code Quality Review

  • Executed by a fresh isolated reviewer subagent (CCR): Lint, Types, Coverage.

Step 15: UX Flow Verification

  • Executed by a fresh isolated reviewer subagent (CCR): User journey check.

Step 16: Related Issues Review (Cascade Impact 2nd)

  • Executed by a fresh isolated reviewer subagent (CCR): Final impact check.

Step 17: Deployment Readiness Review (Final)

  • Executed by a fresh isolated reviewer subagent (CCR): Secrets, Migrations, checklist.

Step 17.1: Final Quality Score & Session Summary (Conditional)

If Quality Score was measured during this session:

  1. Measure final Quality Score
  2. Generate Experiment Ledger summary (total experiments, keep rate, net delta)
  3. Auto-generate lessons from discarded experiments (delta <= -5) into lessons-learned.md
  4. Append Quality Score Progression and Experiment Summary to session metrics

Always (regardless of Quality Score availability): 5. Record Evaluator Accuracy events for this session:

  • Review all QA findings: any disputed by impl agents? → false_positive
  • Review runtime verification results: any stubs caught that static review missed? → missed_stub
  • Review impl agent self-check results: any bugs caught by QA that self-check missed? → good_catch
  1. Append EA events to session-metrics.md
  2. If rolling 3-session EA >= 30: Flag in final report → "QA tuning suggested. Run oma retro to review."

SHIP_GATE

  • [ ] Quality checks pass
  • [ ] Test coverage >= 80% (per phase-gates.md SHIP_GATE)
  • [ ] UX verified
  • [ ] Related issues resolved
  • [ ] Deployment checklist complete
  • [ ] (If measured) Final Quality Score >= 75 (Grade B) with non-negative delta from baseline
  • [ ] (If measured) Experiment Ledger summary recorded
  • [ ] User final approval

On gate pass: Use memory write tool to record final results in session-ultrawork.md

Gate failure → Address issues, re-run affected steps, and repeat until GATE passes.


Step 18: Optional Doc Verify Hook (post-SHIP; outside the 17-step model)

If oma-config.yaml has docs.auto_verify: true:

  1. Run oma docs verify --json from the repo root.
  2. Capture the JSON output.
  3. If broken.length === 0: print docs verified clean (N docs) summary to stdout and continue with workflow completion.
  4. If broken.length > 0: print a 1-3 line summary identifying which docs have drift, and a hint Run /oma-docs verify for the full report. Continue with workflow completion (warn-only, never block).
  5. If oma-docs is not available (CLI command missing): skip silently.

This hook is opt-in; the default auto_verify: false skips this step entirely.


Review Steps Summary

| Phase | Steps | Agent | Execution | Perspective | | ------ | ----- | ---------------------------- | -------------------- | --------------------------------- | | PLAN | 1-4 | PM (author) + CCR reviewers | CCR isolated review | Completeness, Meta, Simplicity | | IMPL | 5 | Dev Agents | Spawn (action) | Implementation | | VERIFY | 6-8 | CCR reviewers | CCR isolated review | Alignment, Safety, Regression | | REFINE | 9-13 | Refactor Agent + CCR reviewers | Action + CCR review | Reusability, Cascade, Consistency | | SHIP | 14-17 | CCR reviewers | CCR isolated review | Quality, UX, Cascade 2nd, Deploy |

Total 12 review steps, each run in a fresh isolated reviewer (Cross-Context Review), + conditional Quality Score checkpoints → High quality guaranteed

Every review runs in its own fresh context (never inline, never batched) per the Cross-Context Review (CCR) Dispatch section and the CCR Mandate in multi-review-protocol.md.


Autoresearch-Inspired Enhancements

This workflow conditionally incorporates patterns from autoresearch:

| Pattern | When Active | Reference | |---------|-------------|-----------| | Continuous metrics | When measurement tools available | quality-score.md (loaded at VERIFY/SHIP) | | Keep/Discard | When quality score is measured | quality-score.md delta rules | | Experiment logging | When baseline is established | experiment-ledger.md (via memory protocol) | | Hypothesis exploration | On repeated gate failures | exploration-loop.md (loaded on trigger) | | Auto-learning | At session end, if experiments exist | lessons-learned.md auto-generation |

All protocols are loaded conditionally per context-loading.md, not at Phase 0.