oh-my-opencode 4.9.2 → 4.11.0

package/.agents/skills/tech-debt-audit/SKILL.md

@@ -0,0 +1,277 @@
+---
+name: tech-debt-audit
+description: "Thorough, file-cited technical debt audit across 9 dimensions using AST-grep (tree-sitter), grep, language-native tooling, and optionally CodeGraph knowledge graph. Produces TECH_DEBT_AUDIT.md with severity, effort estimates, and prioritized fixes. Use when asked for codebase health check, tech debt audit, architecture review, code quality assessment, or cleanup planning. Triggers: 'tech debt', 'technical debt', 'debt audit', 'code health', 'technical debt audit', 'codebase health check', 'find tech debt', 'debt analysis', 'audit code quality'."
+---
+
+# Tech Debt Audit Protocol
+
+Model-agnostic technical debt audit for oh-my-openagent (OMO). Uses OMO's built-in tools (`grep`, `glob`, `bash` with `sg`, `read`, `lsp_diagnostics`, `task`) plus **optional CodeGraph MCP** for enhanced code graph analysis when available. Produces a grounded, citable `TECH_DEBT_AUDIT.md` artifact.
+
+## CodeGraph Enhancement (Optional)
+
+If you have [CodeGraph](https://github.com/colbymchenry/codegraph) installed (check with `codegraph status`), its MCP tools (`codegraph_search`, `codegraph_callers`, `codegraph_callees`, `codegraph_impact`, `codegraph_explore`, etc.) can supersede or augment the standard tool searches in the dimensions marked below. CodeGraph gives you:
+- **Symbol search** — instant by-name lookup via FTS5
+- **Call graph analysis** — callers/callees for any function
+- **Impact analysis** — blast radius before changing any symbol
+- **Smart context building** — entry points, related symbols, and snippets in one call
+- **Framework-aware routes** — URL patterns linked to their handlers
+
+To use CodeGraph, ensure the `codegraph` MCP server is configured in your project's `.mcp.json` or global MCP config. The skill will auto-detect CodeGraph by checking if `codegraph` MCP tools are available. Sub-agents spawned via `task()` cannot use CodeGraph — they use the standard tool fallback.
+
+---
+
+## Output
+
+Write results to `TECH_DEBT_AUDIT.md` in the repo root with:
+
+1. **Executive Summary** — 3-5 sentences: overall health, worst dimension, quick wins count
+2. **Mental Model** — the repo's architecture in 1 paragraph (what it does, stack, module boundaries)
+3. **Findings Table** — columns: ID, Category, File:Line, Severity (Critical/High/Medium/Low), Effort (Hours), Description, Recommendation
+4. **Top 5 Priorities** — ranked by impact/effort ratio
+5. **Quick Wins Checklist** — items under 30 minutes each
+6. **"Looks Bad But Is Fine"** — patterns that look like debt but are intentional
+7. **Open Questions** — things the maintainer should clarify
+
+## Phase 0: Orient
+
+### Standard (always run)
+1. `glob("**/*.ts")` / `glob("**/*.py")` / etc — map the language stack
+2. `glob("**/package.json")` + `read()` — dependencies and build tooling
+3. `bash("git log --oneline -200")` — churn: find highest-change files
+4. `glob("**/*")` + basic math — find largest files (>300 LOC are candidates)
+5. Cross-reference high-churn + large = debt hot zones
+6. Write the mental model paragraph in your own working context
+
+### CodeGraph Enhancement (if available)
+Instead of guessing module boundaries, query the code graph:
+
+```
+codegraph_explore(query="architecture overview and main modules")
+```
+This returns symbol relationships and source grouped by file. Use the structure as your architectural mental model instead of hand-inferring it from directory names.
+
+```
+codegraph_explore(query="main entry points and execution flow")
+```
+This surfaces entry points and call chains. Use these to understand how the code actually flows vs how the directory layout suggests it flows.
+
+## Phase 1: Audit Across 9 Dimensions
+
+Use OMO tools for each dimension. Run parallel tool calls within each dimension. Every finding MUST cite `file:line:col`.
+
+### 1. Architectural Decay
+
+#### Standard (always run)
+- `bash("sg -p \"import { $$$ } from '$SRC'\" -l ts .")` — map module graph, look for circular patterns
+- `bash("sg -p \"class $NAME { $$$ }\" -l ts .")` — check for god classes
+- `grep("TODO|FIXME|HACK|XXX|WORKAROUND|TEMP")` — tagged debt markers
+- `grep("async|await")` on sync-looking files — misplaced async boundaries
+- `bash("wc -l <file>")` on each large file found in Phase 0
+
+#### CodeGraph Enhancement (if available)
+
+**Dead code detection:**
+```
+codegraph_callers(symbol="<suspected-dead-function>")
+codegraph_callers(symbol="<suspected-dead-class>")
+```
+Run `codegraph_callers` on suspected dead exports found via grep/glob. If the result shows zero callers (excluding test files), it's dead code.
+
+**Circular dependency detection:**
+```
+codegraph_impact(target="<module-or-file>", direction="upstream")
+```
+Use `codegraph_impact` on key modules to trace their dependents. If A depends on B and B depends on A, that's a cycle.
+
+**Architecture boundaries:**
+```
+codegraph_explore(query="module dependencies and architecture boundaries")
+```
+Use `codegraph_explore` to survey actual module structure.
+
+#### What to flag
+- Files > 500 LOC (god files)
+- Functions > 80 LOC or > 4 nesting levels
+- Classes with > 15 methods or > 400 LOC
+- Import cycles (A → B → A)
+- Dead exports: function/class defined but never imported elsewhere (CodeGraph: `codegraph_callers`)
+- Commented-out code blocks (>3 consecutive consecutive lines)
+
+### 2. Consistency Rot
+
+#### Standard (always run)
+- `bash("sg -p \"import $CLIENT from '$PKG'\" -l ts .")` — multiple HTTP clients
+- `grep("console.log|console.error|console.warn")` — direct console use vs logger
+- `bash("sg -p \"try { $$$ } catch ($$$) { $$$ }\" -l ts .")` — error handling patterns
+- `grep("as any|@ts-ignore|@ts-expect-error|as unknown")` — type escapes
+- `grep("eslint-disable|prettier-ignore")` — lint suppressions
+
+#### What to flag
+- 3+ ways of doing the same thing (HTTP, logging, validation, config)
+- Mixed naming conventions (camelCase + snake_case + PascalCase)
+- Multiple date/time handling libraries
+- Mixed error response shapes across modules
+
+### 3. Type & Contract Debt
+
+#### Standard (always run)
+- `bash("sg -p \"$VALUE as any\" -l ts .")` — runtime type escapes
+- `grep("@ts-expect-error")` — suppressed errors
+- `grep("@ts-ignore")` — suppressed errors (legacy)
+- `bash("sg -p \"$NAME: any\" -l ts .")` — typed as any
+- `lsp_diagnostics(filePath="<src-dir>")` — current type errors
+
+#### What to flag
+- `any` types on public APIs and exported interfaces
+- Untyped function parameters
+- Missing schema validation at API/IO boundaries
+- LSP type errors grouped by file
+
+### 4. Test Debt
+
+#### Standard (always run)
+- `glob("**/*.test.ts")` — find all test files
+- `bash("bun test 2>&1 | grep -E '(fail|skip|todo)'")` — current test health
+- Cross-reference Phase 0 high-churn files with test existence
+
+#### What to flag
+- Critical-path files with zero tests
+- Skipped tests (`test.skip`, `describe.skip`)
+- Tests asserting implementation details vs behavior
+- Slow tests (>1s each)
+
+### 5. Dependency & Config Debt
+
+#### Standard (always run)
+- `bash("npm audit --omit=dev 2>&1 | head -40")` — known CVEs (if node_modules present)
+- `read("package.json")` — check dependency count and stale deps
+- `grep(".env|process.env|Bun.env")` — env var usage
+- `grep("API_KEY|SECRET|PASSWORD|TOKEN")` in non-config files — hardcoded config
+
+#### CodeGraph Enhancement (if available)
+
+**Blast radius of core dependencies:**
+```
+codegraph_impact(target="<core-utility-function>", direction="upstream")
+```
+Run this on a few key internal modules (logger, config loader, HTTP client) to see how widely they're used. A widely-depended-on module with poor error handling or type safety is a high-priority refactor target because changes to it ripple everywhere.
+
+#### What to flag
+- Outdated major-version deps
+- Dependencies that do the same thing (duplicate libraries)
+- Referenced env vars not documented in README
+- Hardcoded environment-specific values
+
+### 6. Performance & Resource Hygiene
+
+#### Standard (always run)
+- `bash("sg -p \"for ($$$ of $$$) { $$$ await $$$ }\" -l ts .")` — async-in-loop
+- `grep("await.*map|await.*filter|await.*forEach")` — sequential async iteration
+- `grep("Promise\\.all|Promise\\.allSettled")` — existing parallel patterns (good signal)
+- `grep("addEventListener|on\\(|subscribe")` without `removeEventListener|off\\(|unsubscribe` nearby — listener hygiene
+
+#### What to flag
+- `await` inside `for/of` loops (sequential when parallel possible)
+- N+1 query patterns
+- Missing cleanup on event listeners, intervals, handles
+- Unnecessary serialization/deserialization
+
+### 7. Error Handling & Observability
+
+#### Standard (always run)
+- `bash("sg -p \"catch ($$$) { $$$ }\" -l ts .")` — catch blocks
+- `grep("catch.*{}|catch.*{\\s*}")` — empty catch blocks
+- `grep("console.error|logger\\.error|log\\.error")` — actual error logging
+- `bash("sg -p \"throw new $ERR($$$)\" -l ts .")` — error types used
+
+#### CodeGraph Enhancement (if available)
+
+**Trace error propagation through call chains:**
+```
+codegraph_callers(symbol="<key-error-handler-or-middleware>")
+codegraph_explore(query="how errors propagate through <key-error-handler>")
+```
+Use `codegraph_callers` to find who calls your error handlers. If errors are caught and swallowed at multiple levels, that's a finding.
+
+**Impact of changing error types:**
+```
+codegraph_impact(target="<error-class-or-interface>", direction="upstream")
+```
+Check the blast radius of custom error classes. If changing an error type would break 20+ consumers, the error contract is too tight.
+
+#### What to flag
+- Empty catch blocks (worst offense)
+- Generic `catch (e) { console.error(e) }` without recovery
+- Inconsistent error shapes across modules
+- Missing structured logging on critical paths
+- Errors swallowed in promise chains (`.catch(() => {})`)
+
+### 8. Security Hygiene
+
+#### Standard (always run)
+- `grep("api[Kk]ey|api_secret|password|secret|token|credential")` in source files (not config or env)
+- `grep("SELECT .* FROM|INSERT INTO|UPDATE.*SET|DELETE FROM")` — SQL construction
+- `grep("innerHTML|dangerouslySetInnerHTML")` — XSS vectors
+- `grep("eval\\(|Function\\(|setTimeout\\(.*string|setInterval\\(.*string")` — code injection
+
+#### What to flag
+- Hardcoded secrets in source
+- String-concatenated SQL
+- `innerHTML` / `dangerouslySetInnerHTML` usage
+- `eval()` or string-based `setTimeout`/`setInterval`
+- Permissive CORS or auth middleware
+
+### 9. Documentation Drift
+
+#### Standard (always run)
+- `read("README.md")` — check if claims match reality
+- `grep("@param|@returns|@throws")` — docstring coverage
+- `grep("FIXME|TODO|HACK|XXX|WORKAROUND")` — fixme density
+- Compare README API examples with actual signatures
+
+#### What to flag
+- README claiming features that don't exist
+- Public functions without any doc comment
+- Comments that contradict the code
+- Stale architecture decision records (ADRs) if present
+
+## Phase 2: Deeper Dives (Parallel Sub-Agents)
+
+For large codebases (>50k LOC), delegate heavy dimensions to parallel sub-agents. Sub-agents CANNOT use CodeGraph — they use standard tools only:
+
+```
+task(category="unspecified-low", run_in_background=true, load_skills=[], prompt="[CONTEXT] Tech debt audit. [GOAL] Audit dimensions 1 (Architecture) and 2 (Consistency). [REQUEST] Run ast_grep and grep searches for dimensions 1-2 from the tech-debt-audit skill. Report every finding with file:line:col. Tag severity: Critical/High/Medium/Low.")
+task(category="unspecified-low", run_in_background=true, load_skills=[], prompt="[CONTEXT] Tech debt audit. [GOAL] Audit dimensions 3 (Type debt) and 7 (Error handling). [REQUEST] Run searches for dimensions 3 and 7 from the tech-debt-audit skill. Report every finding with file:line:col. Tag severity.")
+```
+
+Spawn 2-3 sub-agents for the heaviest dimensions, collect results in parallel, then synthesize. The main agent handles CodeGraph queries itself while sub-agents run the standard tool passes.
+
+## Phase 3: Synthesize & Deliver
+
+1. Collect all findings from direct tool calls, CodeGraph queries (if available), and sub-agent results
+2. Deduplicate — same issue mentioned by multiple dimensions
+3. Classify severity:
+   - **Critical** — Causes incorrect behavior, data loss, or security vulnerability
+   - **High** — Will cause problems in production; blocks maintenance
+   - **Medium** — Reduces maintainability; violates conventions
+   - **Low** — Cosmetic; should fix when in the area
+4. Estimate effort in hours per finding (conservative)
+5. Write `TECH_DEBT_AUDIT.md` with all required sections
+6. Report summary to the user
+
+## Severity Rubric
+
+```
+Critical = actively causing bugs or security holes
+High     = will cause problems under normal operation; blocks changes
+Medium   = reduces maintainability; inconsistent; violates team conventions
+Low      = cosmetic; would be nice to fix when nearby
+```
+
+## Quick Checks Before Finishing
+
+- [ ] Every concrete finding has `file:line:col` citation
+- [ ] No generic claims without evidence
+- [ ] "Looks Bad But Is Fine" section explains at least 2-3 patterns
+- [ ] Top 5 priorities ranked by impact/effort
+- [ ] Quick wins are things that can be fixed in <30 minutes each

package/.agents/skills/work-with-pr/SKILL.md

@@ -1,23 +1,27 @@
 ---
 name: work-with-pr
-description: "Full PR lifecycle: git worktree → implement → atomic commits → PR creation → verification loop (CI + review-work + Cubic approval) → merge. Keeps iterating until ALL gates pass and PR is merged. Worktree auto-cleanup after merge. Use whenever implementation work needs to land as a PR. Triggers: 'create a PR', 'implement and PR', 'work on this and make a PR', 'implement issue', 'land this as a PR', 'work-with-pr', 'PR workflow', 'implement end to end', even when user just says 'implement X' if the context implies PR delivery."
+description: "Full PR lifecycle in an isolated git worktree: implement via the ulw-loop skill with mandatory evidence-bound manual QA → detailed English PR → verification loop (CI + review-work reviewers + Cubic, where Cubic is skipped only when its quota is exhausted) → merge by default → worktree cleanup. Decomposes one task into the smallest atomic, independently-mergeable PRs and builds the independent ones concurrently via a worktree per PR driven by parallel subagents or a team. Unbounded loop: any failing gate sends you back to fix-and-re-QA inside the worktree. Use whenever implementation work needs to land as a PR. Triggers: 'create a PR', 'implement and PR', 'work on this and make a PR', 'implement issue', 'land this as a PR', 'split into atomic PRs', 'parallel PRs', 'work-with-pr', 'PR workflow', 'implement end to end', even when user just says 'implement X' if the context implies PR delivery."
 ---
 
 # Work With PR — Full PR Lifecycle
 
-You are executing a complete PR lifecycle: from isolated worktree setup through implementation, PR creation, and an unbounded verification loop until the PR is merged. The loop has three gates — CI, review-work, and Cubic — and you keep fixing and pushing until all three pass simultaneously.
+You are executing a complete PR lifecycle: from isolated worktree setup, through `ulw-loop`-driven implementation with evidence-bound manual QA, PR creation, and an unbounded verification loop until the PR is merged. The loop has three gates — CI, review-work, and Cubic — and a failing gate sends you back into the worktree to fix and re-QA. You keep cycling until every active gate passes at once.
+
+**The unit of delivery is the smallest PR that compiles, passes, and stands on its own — not "one task, one PR."** A single task routinely splits into several atomic PRs; the lifecycle below describes ONE of them, so apply it to each, and build the independent ones concurrently (Phase 0).
 
 <architecture>
 
 ```
-Phase 0: Setup         → Branch + worktree in sibling directory
-Phase 1: Implement     → Do the work, atomic commits
-Phase 2: PR Creation   → Push, create PR targeting dev
-Phase 3: Verify Loop   → Unbounded iteration until ALL gates pass:
+Phase 0: Setup         → Split into atomic PRs, then branch + worktree per PR (parallel when independent)
+Phase 1: Implement     → Drive the work through the ulw-loop skill:
+                         evidence-bound manual QA per success criterion, atomic commits
+Phase 2: PR Creation   → Push, create a detailed English PR targeting dev
+Phase 3: Verify Loop   → Unbounded iteration; a failing gate routes back to Phase 1:
   ├─ Gate A: CI         → gh pr checks (bun test, typecheck, build)
-  ├─ Gate B: review-work → 5-agent parallel review
+  ├─ Gate B: review-work → 5-agent parallel review (the reviewer subagents)
   └─ Gate C: Cubic      → cubic-dev-ai[bot] "No issues found"
-Phase 4: Merge         → Merge commit, worktree cleanup
+                         (SKIPPED, not failed, when Cubic's quota is exhausted)
+Phase 4: Merge         → Merge by default, then worktree cleanup
 ```
 
 </architecture>
@@ -26,11 +30,21 @@ Phase 4: Merge         → Merge commit, worktree cleanup
 
 ## Phase 0: Setup
 
-Create an isolated worktree so the user's main working directory stays clean. This matters because the user may have uncommitted work, and checking out a branch would destroy it.
+Create an isolated worktree so the user's main working directory stays clean — the user may have uncommitted work, and a branch checkout would destroy it. Isolation also makes parallelism cheap: one worktree per PR, so several build at once without colliding.
 
 <setup>
 
-### 1. Resolve repository context
+### 1. Decide the PR split
+
+Before creating anything, decompose the task into the smallest atomic PRs that each compile, pass, and deliver one reviewable slice. Prefer more small PRs over one large one — a 200-line PR gets a real review; a 2000-line PR gets a rubber stamp. Sequence by dependency: independent slices branch off the base and run in parallel; dependent slices stack, each branched off the previous.
+
+Building more than one independent PR concurrently is the recommended default, not an exotic option:
+- **Subagents** — dispatch one background subagent per PR, each owning its own worktree, branch, and the full Phase 0→4 lifecycle.
+- **Team** — for larger fan-outs, form a team (`team_mode`) and assign one member per PR.
+
+When the work is large enough to need a plan (`ulw-plan`), this decomposition is not optional polish: the plan MUST encode the atomic PRs, their dependency order, and which run in parallel as first-class structure.
+
+### 2. Resolve repository context
 
 ```bash
 REPO=$(gh repo view --json nameWithOwner -q .nameWithOwner)
@@ -38,7 +52,7 @@ REPO_NAME=$(basename "$PWD")
 BASE_BRANCH="dev"  # CI blocks PRs to master
 ```
 
-### 2. Create branch
+### 3. Create branch
 
 If user provides a branch name, use it. Otherwise, derive from the task:
 
@@ -49,7 +63,7 @@ git fetch origin "$BASE_BRANCH"
 git branch "$BRANCH_NAME" "origin/$BASE_BRANCH"
 ```
 
-### 3. Create worktree
+### 4. Create worktree
 
 Place worktrees as siblings to the repo — not inside it. This avoids git nested repo issues and keeps the working tree clean.
 
@@ -59,7 +73,7 @@ mkdir -p "$(dirname "$WORKTREE_PATH")"
 git worktree add "$WORKTREE_PATH" "$BRANCH_NAME"
 ```
 
-### 4. Set working context
+### 5. Set working context
 
 All subsequent work happens inside the worktree. Install dependencies if needed:
 
@@ -75,15 +89,19 @@ cd "$WORKTREE_PATH"
 
 ## Phase 1: Implement
 
-Do the actual implementation work inside the worktree. The agent using this skill does the work directly — no subagent delegation for the implementation itself.
+Drive all implementation through the `ulw-loop` skill (your harness's native ultrawork loop) from inside the worktree. Do not free-hand the work: `ulw-loop` decomposes the brief into goals with binary success criteria, delegates code edits and QA to right-sized subagents, and — the reason it is mandatory here — forces every success criterion to be proven with evidence-bound **manual QA on a real surface**, not just a green test suite.
 
-**Scope discipline**: For bug fixes, stay minimal. Fix the bug, add a test for it, done. Do not refactor surrounding code, add config options, or "improve" things that aren't broken. The verification loop will catch regressions — trust the process.
+**Manual QA is the gate, not the tests.** This repo's rule is absolute: a change that reaches OpenCode or Codex is not done until you have driven the real harness (tmux / HTTP / browser / GUI — use the manual-QA channel table in the `ulw-loop` skill) AND written the evidence to disk. No evidence file means the QA did not happen, and you may NOT commit or push. "It typechecks" and "`bun test` is green" are NOT QA.
 
 <implementation>
 
+### Scope discipline
+
+Within each PR, stay minimal: deliver its one slice, add the test, prove it, stop. Do not refactor surrounding code, add config options, or "improve" things that aren't broken — that work belongs in its own PR, and scope creep makes failures harder to isolate.
+
 ### Commit strategy
 
-Use the git-master skill's atomic commit principles. The reason for atomic commits: if CI fails on one change, you can isolate and fix it without unwinding everything.
+`ulw-loop` commits through `git-master`. Keep commits atomic so that if CI fails on one change you can isolate and fix it without unwinding everything:
 
 ```
 3+ files changed  → 2+ commits minimum
@@ -91,15 +109,11 @@ Use the git-master skill's atomic commit principles. The reason for atomic commi
 10+ files changed → 5+ commits minimum
 ```
 
-Each commit should pair implementation with its tests. Load `git-master` skill when committing:
-
-```
-task(category="quick", load_skills=["git-master"], prompt="Commit the changes atomically following git-master conventions. Repository is at {WORKTREE_PATH}.")
-```
+Each commit pairs implementation with its tests, and you commit a criterion only after its QA evidence is on disk.
 
 ### Pre-push local validation
 
-Before pushing, run the same checks CI will run. Catching failures locally saves a full CI round-trip (~3-5 min):
+Before pushing, run the same checks CI will run — a cheap pre-filter that saves a ~3-5 min CI round-trip, NOT a substitute for the manual QA above:
 
 ```bash
 bun run typecheck
@@ -107,7 +121,7 @@ bun test
 bun run build
 ```
 
-Fix any failures before pushing. Each fix-commit cycle should be atomic.
+Fix any failure before pushing; each fix is its own atomic commit.
 
 </implementation>
 
@@ -123,7 +137,7 @@ Fix any failures before pushing. Each fix-commit cycle should be atomic.
 git push -u origin "$BRANCH_NAME"
 ```
 
-Create the PR using the project's template structure:
+Write the PR body in English, detailed enough that a reviewer understands the change without reading the diff. The Verification section is where the manual-QA evidence from Phase 1 earns its place — cite what you actually drove and where the artifact lives, not just that tests passed.
 
 ```bash
 gh pr create \
@@ -132,15 +146,14 @@ gh pr create \
   --title "$PR_TITLE" \
   --body "$(cat <<'EOF'
 ## Summary
-[1-3 sentences describing what this PR does and why]
+[2-4 sentences: what this PR does, why it's needed, and the approach taken]
 
 ## Changes
-[Bullet list of key changes]
+[Bullet list of key changes, grouped by area; enough that a reviewer can map each bullet to the diff]
 
-## Testing
-- `bun run typecheck` ✅
-- `bun test` ✅
-- `bun run build` ✅
+## Verification
+**Automated:** `bun run typecheck` ✅ · `bun test` ✅ · `bun run build` ✅
+**Manual QA:** [per success criterion — the channel driven (tmux/HTTP/browser/GUI), what you observed, and the evidence artifact path]
 
 ## Related Issues
 [Link to issue if applicable]
@@ -160,19 +173,20 @@ PR_NUMBER=$(gh pr view --json number -q .number)
 
 ## Phase 3: Verification Loop
 
-This is the core of the skill. Three gates must ALL pass for the PR to be ready. The loop has no iteration cap — keep going until done. Gate ordering is intentional: CI is cheapest/fastest, review-work is most thorough, Cubic is external and asynchronous.
+This is the core of the skill. Every active gate must pass for the PR to be ready. The loop has no iteration cap — keep going until done. Gate ordering is intentional: CI is cheapest/fastest, review-work is most thorough, Cubic is external and asynchronous. Gate C (Cubic) is the one gate that can be SKIPPED rather than satisfied — only when its quota is exhausted; it is never skipped just because it found issues. A failing gate is not a patch-and-push: route back to Phase 1, where fixes get the same scope discipline and, if behavior changed, fresh manual-QA evidence before you re-enter the loop.
 
 <verify_loop>
 
 ```
 while true:
   1. Wait for CI          → Gate A
-  2. If CI fails          → read logs, fix, commit, push, continue
-  3. Run review-work      → Gate B
-  4. If review fails      → fix blocking issues, commit, push, continue
+  2. If CI fails          → back to Phase 1: read logs, fix + re-QA, commit, push, continue
+  3. Run review-work      → Gate B (the reviewer subagents)
+  4. If review fails      → back to Phase 1: fix blocking issues + re-QA, commit, push, continue
   5. Check Cubic          → Gate C
-  6. If Cubic has issues   → fix issues, commit, push, continue
-  7. All three pass       → break
+  6. If Cubic has issues   → back to Phase 1: fix + re-QA, commit, push, continue
+  7. If Cubic quota out    → record Gate C SKIPPED, stop waiting on it
+  8. All active gates pass → break
 ```
 
 ### Gate A: CI Checks
@@ -195,7 +209,7 @@ RUN_ID=$(gh run list --branch "$BRANCH_NAME" --status failure --json databaseId
 gh run view "$RUN_ID" --log-failed
 ```
 
-Read the logs, fix the issue, commit atomically, push, and re-enter the loop.
+Read the logs, then fix per the iteration discipline below.
 
 ### Gate B: review-work
 
@@ -213,7 +227,7 @@ task(
 )
 ```
 
-**On failure**: review-work reports blocking issues with specific files and line numbers. Fix each blocking issue, commit, push, and re-enter the loop from Gate A (since code changed, CI must re-run).
+**On failure**: review-work reports blocking issues with specific files and line numbers. Fix each blocking issue per the iteration discipline below.
 
 ### Gate C: Cubic Approval
 
@@ -223,45 +237,49 @@ Cubic (`cubic-dev-ai[bot]`) is an automated review bot that comments on PRs. It
 
 **Issue signal**: The comment lists issues with file-level detail.
 
+**Quota-exhausted signal**: Cubic posts a usage/quota/limit message instead of a review, or no Cubic review appears within the bounded wait below. This is the ONLY case where you skip Gate C and proceed — record it as SKIPPED in the final report, never silently. Issues are never a reason to skip.
+
 ```bash
 # Get the latest Cubic review
 CUBIC_REVIEW=$(gh api "repos/${REPO}/pulls/${PR_NUMBER}/reviews" \
   --jq '[.[] | select(.user.login == "cubic-dev-ai[bot]")] | last | .body')
 
-# Check if approved
 if echo "$CUBIC_REVIEW" | grep -q "No issues found"; then
   echo "Cubic: APPROVED"
+elif echo "$CUBIC_REVIEW" | grep -qiE "quota|usage limit|rate limit|out of (credits|reviews)|upgrade your plan"; then
+  echo "Cubic: SKIPPED (quota exhausted)"   # Gate C satisfied-by-skip; do not loop on it
 else
   echo "Cubic: ISSUES FOUND"
   echo "$CUBIC_REVIEW"
 fi
 ```
 
-**On issues**: Cubic's review body contains structured issue descriptions. Parse them, determine which are valid (some may be false positives), fix the valid ones, commit, push, re-enter from Gate A.
+**On issues**: Cubic's review body contains structured issue descriptions. Parse them, determine which are valid (some may be false positives), and fix the valid ones per the iteration discipline below.
 
 Cubic reviews are triggered automatically on PR updates. After pushing a fix, wait for the new review to appear before checking again. Use `gh api` polling with a conditional loop:
 
 ```bash
-# Wait for new Cubic review after push
+# Wait for a NEW Cubic review after push. If none arrives within the bound,
+# Cubic is out of quota (or not running) → skip Gate C rather than spin forever.
 PUSH_TIME=$(date -u +%Y-%m-%dT%H:%M:%SZ)
-while true; do
+for _ in $(seq 1 30); do
   LATEST_REVIEW_TIME=$(gh api "repos/${REPO}/pulls/${PR_NUMBER}/reviews" \
     --jq '[.[] | select(.user.login == "cubic-dev-ai[bot]")] | last | .submitted_at')
-  if [[ "$LATEST_REVIEW_TIME" > "$PUSH_TIME" ]]; then
-    break
-  fi
-  # Use gh api call itself as the delay mechanism — each call takes ~1-2s
-  # For longer waits, use: timeout 30 gh pr checks "$PR_NUMBER" --watch 2>/dev/null || true
+  [[ "$LATEST_REVIEW_TIME" > "$PUSH_TIME" ]] && break
+  timeout 20 gh pr checks "$PR_NUMBER" --watch >/dev/null 2>&1 || true  # spend the interval usefully
 done
+# Loop exhausted without a newer review → treat Gate C as SKIPPED (quota exhausted)
+[[ "$LATEST_REVIEW_TIME" > "$PUSH_TIME" ]] || echo "Cubic: SKIPPED (no review within bound — quota exhausted)"
 ```
 
 ### Iteration discipline
 
 Each iteration through the loop:
 1. Fix ONLY the issues identified by the failing gate
-2. Commit atomically (one logical fix per commit)
-3. Push
-4. Re-enter from Gate A (code changed → full re-verification)
+2. If the fix changes runtime behavior, capture fresh manual-QA evidence (Phase 1)
+3. Commit atomically (one logical fix per commit)
+4. Push
+5. Re-enter from Gate A (code changed → full re-verification)
 
 Avoid the temptation to "improve" unrelated code during fix iterations. Scope creep in the fix loop makes debugging harder and can introduce new failures.
 
@@ -271,12 +289,14 @@ Avoid the temptation to "improve" unrelated code during fix iterations. Scope cr
 
 ## Phase 4: Merge & Cleanup
 
-Once all three gates pass:
+Once all active gates pass (Cubic may be SKIPPED on quota):
 
 <merge_cleanup>
 
 ### Merge the PR
 
+Merging is the default — do it unless the user explicitly told you not to. If they opted out, skip this step and report the green, ready-to-merge PR, but STILL run the cleanup below: the worktree is removed either way.
+
 ```bash
 # This repository requires merge commits. Never use --squash or --rebase here.
 gh pr merge "$PR_NUMBER" --merge --delete-branch
@@ -310,12 +330,13 @@ git worktree prune
 Summarize what happened:
 
 ```
-## PR Merged ✅
+## PR Complete
 
 - **PR**: #{PR_NUMBER} — {PR_TITLE}
 - **Branch**: {BRANCH_NAME} → {BASE_BRANCH}
 - **Iterations**: {N} verification loops
-- **Gates passed**: CI ✅ | review-work ✅ | Cubic ✅
+- **Gates**: CI pass | review-work pass | Cubic {pass | SKIPPED (quota exhausted)}
+- **Merged**: {yes | no — left for you to merge, as requested}
 - **Worktree**: cleaned up
 ```
 
@@ -351,10 +372,13 @@ git rebase "origin/$BASE_BRANCH"
 | Violation | Why it fails | Severity |
 |-----------|-------------|----------|
 | Working in main worktree instead of isolated worktree | Pollutes user's working directory, may destroy uncommitted work | CRITICAL |
+| Committing or pushing without manual-QA evidence on disk | "Tests pass" never proves the feature works; the repo forbids it for OpenCode/Codex-touching changes | CRITICAL |
 | Pushing directly to dev/master | Bypasses review entirely | CRITICAL |
 | Skipping CI gate after code changes | review-work and Cubic may pass on stale code | CRITICAL |
+| Skipping Cubic because it found issues | Only an exhausted quota justifies a skip; real issues must be fixed and re-pushed | HIGH |
 | Fixing unrelated code during verification loop | Scope creep causes new failures | HIGH |
 | Deleting worktree on failure | User loses ability to inspect/resume | HIGH |
 | Ignoring Cubic false positives without justification | Cubic issues should be evaluated, not blindly dismissed | MEDIUM |
+| Bundling independent slices into one big PR | Atomic review dies — a 2000-line PR gets rubber-stamped, regressions hide, and one bad slice blocks all the others | HIGH |
 | Giant single commits | Harder to isolate failures, violates git-master principles | MEDIUM |
 | Not running local checks before push | Wastes CI time on obvious failures | MEDIUM |

package/.agents/skills/work-with-pr-workspace/iteration-1/eval-5/with_skill/outputs/execution-plan.md

@@ -107,6 +107,6 @@ gh pr create --base dev \
 ```bash
 gh pr merge --squash --auto
 # Cleanup worktree
-cd /Users/yeongyu/local-workspaces/omo
+cd <repo-root>
 git worktree remove ../omo-wt/fix/comment-checker-note-false-positive
 ```