oh-my-opencode 5.0.0-beta.4 → 5.0.0-beta.42

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

@@ -1,24 +1,11 @@
 ---
 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'."
+description: "Thorough, file-cited technical debt audit across 9 dimensions using AST-grep (tree-sitter), grep, LSP, and language-native tooling. 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.
-
----
+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`). Produces a grounded, citable `TECH_DEBT_AUDIT.md` artifact.
 
 ## Output
 
@@ -42,19 +29,6 @@ Write results to `TECH_DEBT_AUDIT.md` in the repo root with:
 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`.
@@ -68,33 +42,12 @@ Use OMO tools for each dimension. Run parallel tool calls within each dimension.
 - `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`)
+- Dead exports: function/class defined but never imported elsewhere (confirm with `lsp_find_references`)
 - Commented-out code blocks (>3 consecutive consecutive lines)
 
 ### 2. Consistency Rot
@@ -148,14 +101,6 @@ Use `codegraph_explore` to survey actual module structure.
 - `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)
@@ -184,21 +129,6 @@ Run this on a few key internal modules (logger, config loader, HTTP client) to s
 - `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
@@ -237,18 +167,18 @@ Check the blast radius of custom error classes. If changing an error type would
 
 ## 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:
+For large codebases (>50k LOC), delegate heavy dimensions to parallel sub-agents. Each sub-agent runs the standard tool passes for its dimensions:
 
 ```
 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.
+Spawn 2-3 sub-agents for the heaviest dimensions, collect results in parallel, then synthesize.
 
 ## Phase 3: Synthesize & Deliver
 
-1. Collect all findings from direct tool calls, CodeGraph queries (if available), and sub-agent results
+1. Collect all findings from direct tool calls and sub-agent results
 2. Deduplicate — same issue mentioned by multiple dimensions
 3. Classify severity:
    - **Critical** — Causes incorrect behavior, data loss, or security vulnerability

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

@@ -196,12 +196,20 @@ while true:
 
 ### Gate A: CI Checks
 
-CI is the fastest feedback loop. Wait for it to complete, then parse results.
+CI is the fastest feedback loop. Subscribe to its completion via `monitor` — never block a model round-trip on `gh pr checks --watch`.
 
-```bash
-# Wait for checks to start (GitHub needs a moment after push)
-# Then watch for completion
-gh pr checks "$PR_NUMBER" --watch --fail-fast
+```
+# Subscribe to CI completion — the monitor event wakes the session when checks finish.
+# Do NOT use `gh pr checks --watch` as a blocking tool call; it burns a full model
+# round-trip (~29s) on every poll. Instead, register a monitor and end the turn:
+monitor({
+  description: "CI completion for PR $PR_NUMBER",
+  command: "gh pr checks $PR_NUMBER --watch --fail-fast",
+  filter: "completed|fail|cancel"
+})
+# → end turn; the monitor's matching line arrives as an injected event.
+# For a single midpoint status peek (at most once), use:
+#   gh pr checks "$PR_NUMBER"  # one-shot, no --watch
 ```
 
 **On failure**: Get the failed run logs to understand what broke:
@@ -243,20 +251,21 @@ fi
 
 **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:
+Cubic reviews are triggered automatically on PR updates. After pushing a fix, subscribe to the new review arriving — never spin a `for _ in $(seq 1 30)` polling loop that burns model round-trips.
 
-```bash
-# Wait for a NEW Cubic review after push. If none arrives within the bound,
-# Cubic is out of quota (or not running) → skip Gate B rather than spin forever.
+```
+# Subscribe to a NEW Cubic review after push. The monitor exits when a review
+# newer than PUSH_TIME appears, or times out (quota exhausted → Gate B SKIPPED).
 PUSH_TIME=$(date -u +%Y-%m-%dT%H:%M:%SZ)
-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')
-  [[ "$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 B as SKIPPED (quota exhausted)
-[[ "$LATEST_REVIEW_TIME" > "$PUSH_TIME" ]] || echo "Cubic: SKIPPED (no review within bound — quota exhausted)"
+monitor({
+  description: "Cubic review for PR $PR_NUMBER",
+  command: "LATEST=$(gh api repos/${REPO}/pulls/${PR_NUMBER}/reviews --jq '[.[] | select(.user.login == "cubic-dev-ai[bot]")] | last | .submitted_at // empty'); [ -n \"$LATEST\" ] && [ \"$LATEST\" > \"$PUSH_TIME\" ] && echo NEW_REVIEW || echo WAITING",
+  filter: "NEW_REVIEW",
+  timeout_ms: 600000   # 10 min bound — if no review arrives, Gate B is SKIPPED (quota exhausted)
+})
+# → end turn; if the monitor times out without NEW_REVIEW, treat Gate B as SKIPPED.
+# For a single midpoint peek (at most once), use:
+#   gh api "repos/${REPO}/pulls/${PR_NUMBER}/reviews" --jq '[.[] | select(.user.login == "cubic-dev-ai[bot]")] | last | .submitted_at'
 ```
 
 ### Iteration discipline
@@ -292,13 +301,18 @@ gh pr merge "$PR_NUMBER" --merge --auto --delete-branch
 # are green, fall back to a direct merge: gh pr merge "$PR_NUMBER" --merge --delete-branch
 ```
 
-Then WAIT until the merge has actually completed before you report done or clean up - never walk away while the PR is still merging:
+Then subscribe to the merge completing — never block a model round-trip on an `until [ ... MERGED ]` polling loop:
 
-```bash
-# Block until the PR is actually MERGED (auto-merge lands once all required checks pass)
-until [ "$(gh pr view "$PR_NUMBER" --json state -q .state)" = "MERGED" ]; do
-  gh pr checks "$PR_NUMBER" --watch --fail-fast >/dev/null 2>&1 || true   # spend the interval on the checks
-done
+```
+# Subscribe to merge completion. The monitor exits when gh pr view returns MERGED.
+monitor({
+  description: "Merge completion for PR $PR_NUMBER",
+  command: "[ \"$(gh pr view $PR_NUMBER --json state -q .state)\" = \"MERGED\" ] && echo MERGED || echo WAITING",
+  filter: "MERGED",
+  timeout_ms: 1800000   # 30 min bound for auto-merge to land after all gates pass
+})
+# → end turn; the MERGED event wakes the session for the cleanup step.
+# If the monitor times out, check merge state once: gh pr view "$PR_NUMBER" --json state -q .state
 ```
 
 If the user opted out of merging, skip the merge but STILL run the cleanup below: the worktree is removed either way.

package/.opencode/command/publish.md

@@ -1,6 +1,6 @@
 ---
 description: Publish oh-my-opencode to npm via GitHub Actions workflow
-argument-hint: <patch|minor|major>
+argument-hint: <patch|minor|major|explicit-semver>
 ---
 
 
@@ -54,15 +54,16 @@ This contract applies to the slash-command copies (`.agents/command/publish.md`,
 
 ## CRITICAL: ARGUMENT REQUIREMENT
 
-**You MUST receive a version bump type from the user.** Valid options:
+**You MUST receive one release selector from the user.** Valid options:
 - `patch`: Bug fixes, backward-compatible (1.1.7 → 1.1.8)
 - `minor`: New features, backward-compatible (1.1.7 → 1.2.0)
 - `major`: Breaking changes (1.1.7 → 2.0.0)
+- An explicit valid semantic version, including a prerelease such as `5.0.0-beta.9`
 
-**If the user did not provide a bump type argument, STOP IMMEDIATELY and ask:**
-> "To proceed with deployment, please specify a version bump type: `patch`, `minor`, or `major`"
+**If the user did not provide a release selector, STOP IMMEDIATELY and ask:**
+> "To proceed with deployment, specify `patch`, `minor`, `major`, or an explicit semantic version such as `5.0.0-beta.9`."
 
-**DO NOT PROCEED without explicit user confirmation of bump type.**
+Reject any other value. Do not infer or repair malformed versions.
 
 ---
 
@@ -72,7 +73,7 @@ This contract applies to the slash-command copies (`.agents/command/publish.md`,
 
 ```
 [
-  { "id": "confirm-bump", "content": "Confirm version bump type with user (patch/minor/major)", "status": "in_progress", "priority": "high" },
+  { "id": "confirm-release-input", "content": "Confirm release selector with user (patch/minor/major or explicit semver)", "status": "in_progress", "priority": "high" },
   { "id": "check-uncommitted", "content": "Check for uncommitted changes and commit if needed", "status": "pending", "priority": "high" },
   { "id": "sync-remote", "content": "Sync with remote (pull --rebase && push if unpushed commits)", "status": "pending", "priority": "high" },
   { "id": "run-workflow", "content": "Trigger GitHub Actions publish workflow", "status": "pending", "priority": "high" },
@@ -92,9 +93,23 @@ This contract applies to the slash-command copies (`.agents/command/publish.md`,
 
 ---
 
-## STEP 1: CONFIRM BUMP TYPE
+## STEP 1: CONFIRM AND CLASSIFY THE RELEASE SELECTOR
 
-If the user already named a bump type (argument or message), that IS the confirmation — state it and continue immediately. Only ask and wait when no bump type was given.
+If the user already supplied the selector in the command argument or message, that IS the confirmation. Parse it exactly once:
+
+```bash
+RELEASE_INPUT="${ARGUMENTS}"
+if [[ "$RELEASE_INPUT" =~ ^(patch|minor|major)$ ]]; then
+  RELEASE_KIND=bump
+elif [[ "$RELEASE_INPUT" =~ ^([0-9]+\.){2}[0-9]+(-[0-9A-Za-z]+(\.[0-9A-Za-z]+)*)?$ ]]; then
+  RELEASE_KIND=version
+else
+  echo "Invalid release selector: $RELEASE_INPUT" >&2
+  exit 1
+fi
+```
+
+Only ask and wait when no selector was provided.
 
 ---
 
@@ -125,16 +140,29 @@ This ensures the GitHub Actions workflow runs on the latest code including all l
 
 ## STEP 3: TRIGGER GITHUB ACTIONS WORKFLOW
 
-Run the publish workflow:
-```bash
-gh workflow run publish -f bump={bump_type}
-```
+Dispatch from `dev`, pass bump selectors through `bump`, and pass exact versions through `version`. The required `bump` input remains `patch` for explicit-version dispatches but is ignored by the workflow because `version` takes precedence.
 
-Wait 3 seconds, then get the run ID:
 ```bash
-gh run list --workflow=publish --limit=1 --json databaseId,status --jq '.[0]'
+if [ "$RELEASE_KIND" = bump ]; then
+  RUN_URL="$(gh workflow run publish.yml --ref dev -f "bump=${RELEASE_INPUT}")"
+else
+  RUN_URL="$(gh workflow run publish.yml --ref dev -f bump=patch -f "version=${RELEASE_INPUT}")"
+fi
+
+if ! [[ "$RUN_URL" =~ ^https://github.com/code-yeongyu/oh-my-openagent/actions/runs/[0-9]+$ ]]; then
+  echo "Publish dispatch did not return an exact workflow run URL: $RUN_URL" >&2
+  exit 1
+fi
+RUN_ID="${RUN_URL##*/}"
+if ! [[ "$RUN_ID" =~ ^[0-9]+$ ]]; then
+  echo "Publish dispatch returned an invalid run ID: $RUN_ID" >&2
+  exit 1
+fi
+gh run view "${RUN_ID}" --json databaseId,status,url --jq '{databaseId,status,url}'
 ```
 
+The returned run ID owns this release attempt. Never replace it with a latest-run lookup.
+
 ---
 
 ## STEP 4: WAIT FOR WORKFLOW COMPLETION
@@ -150,14 +178,14 @@ The publish run is a single workflow with sequential stages. Expected timeline (
 
 Poll job-level status every 30 seconds and report stage transitions to the user:
 ```bash
-gh run view {run_id} --json status,conclusion,jobs --jq '{status, conclusion, stage: ([.jobs[] | select(.status=="in_progress") | .name] | join(", "))}'
+gh run view "${RUN_ID}" --json status,conclusion,jobs --jq '{status, conclusion, stage: ([.jobs[] | select(.status=="in_progress") | .name] | join(", "))}'
 ```
 
 **IMPORTANT: Use polling loop, NOT sleep commands.** Use the waiting time to draft the enhanced release summary (Step 6) — do not sit idle, and do not start any review activity.
 
 If conclusion is `failure`, show error and stop:
 ```bash
-gh run view {run_id} --log-failed
+gh run view "${RUN_ID}" --log-failed
 ```
 
 ---

package/.opencode/skills/pre-publish-review/SKILL.md

@@ -1,16 +1,16 @@
 ---
 name: pre-publish-review
-description: "Nuclear-grade 16-agent pre-publish release gate. Runs /get-unpublished-changes to detect all changes since last npm release, spawns up to 10 ultrabrain agents for deep per-change analysis, invokes /review-work (5 agents) for holistic review, and 1 oracle for overall release synthesis. Runs ONLY when the user explicitly asks for a pre-publish review — a plain publish/release request MUST NOT trigger this; /publish ships directly. Triggers: 'pre-publish review', 'review before publish', 'release review', 'pre-release review', 'ready to publish?', 'can I publish?', 'pre-publish', 'safe to publish', 'publishing review', 'pre-publish check'."
+description: "Nuclear-grade 12-agent pre-publish release gate. Runs /get-unpublished-changes to detect all changes since last npm release, spawns up to 10 ultrabrain agents for deep per-change analysis, invokes /review-work (orchestrator manual QA plus one gate reviewer) for holistic review, and 1 oracle for overall release synthesis. Runs ONLY when the user explicitly asks for a pre-publish review — a plain publish/release request MUST NOT trigger this; /publish ships directly. Triggers: 'pre-publish review', 'review before publish', 'release review', 'pre-release review', 'ready to publish?', 'can I publish?', 'pre-publish', 'safe to publish', 'publishing review', 'pre-publish check'."
 ---
 
-# Pre-Publish Review — 16-Agent Release Gate
+# Pre-Publish Review — 12-Agent Release Gate
 
 Three-agent-layer review before publishing to npm. Every layer covers a different angle, and every result is mapped onto the release layers below.
 
 | Layer | Agents | Type | What They Check |
 |-------|--------|------|-----------------|
 | Per-Change Deep Dive | up to 10 | ultrabrain | Each logical change group individually — correctness, edge cases, pattern adherence |
-| Holistic Review | 5 | review-work | Goal compliance, QA execution, code quality, security, context mining across full changeset |
+| Holistic Review | 1 (+ orchestrator QA) | review-work | Manual QA by the review orchestrator, then one gate reviewer covering goal compliance, code quality, security, and missed context across the full changeset |
 | Release Synthesis | 1 | oracle | Overall release readiness, version bump, breaking changes, deployment risk |
 
 ## Release Layer Taxonomy
@@ -159,9 +159,9 @@ OUTPUT FORMAT:
 """)
 ```
 
-### Layer 2: Holistic Review via /review-work (5 agents)
+### Layer 2: Holistic Review via /review-work (one gate reviewer)
 
-Spawn a sub-agent that loads the `/review-work` skill. The review-work skill internally launches 5 parallel agents: Oracle (goal verification), unspecified-high (QA execution), Oracle (code quality), Oracle (security), unspecified-high (context mining). All 5 must pass for the review to pass.
+Spawn a sub-agent that loads the `/review-work` skill. The review-work skill runs manual QA on the real surface itself, then launches ONE gate reviewer (oracle) that audits goal compliance, code quality, security, missed context, and the QA evidence. The review passes only on a clean QA matrix plus APPROVE.
 
 ```
 task(
@@ -186,7 +186,7 @@ BACKGROUND: Pre-publish review of oh-my-opencode, an OpenCode plugin with 1268 T
 
 The diff base is: git diff v{PUBLISHED}..HEAD
 
-Follow the /review-work skill flow exactly — launch all 5 review agents and collect results. Do NOT skip any of the 5 agents.
+Follow the /review-work skill flow exactly — run the manual QA phase, launch the gate reviewer, and collect its verdict. Do NOT skip the QA phase or the reviewer.
 """)
 ```
 
@@ -228,7 +228,7 @@ task(
 {Read and include full content of KEY changed files — focus on public API surfaces, config schemas, agent definitions, hook registrations, tool registrations}
 </file_contents>
 
-You are the final gate before an npm publish. 10 ultrabrain agents are reviewing individual changes and 5 review-work agents are doing holistic review. Your job is the bird's-eye view that those focused reviews might miss.
+You are the final gate before an npm publish. 10 ultrabrain agents are reviewing individual changes and the review-work gate reviewer is doing the holistic review. Your job is the bird's-eye view that those focused reviews might miss.
 
 SYNTHESIS CHECKLIST:
 
@@ -378,11 +378,8 @@ Compile the final report:
 
 | # | Review Area | Verdict | Confidence |
 |---|------------|---------|------------|
-| 1 | Goal & Constraint Verification | PASS/FAIL | HIGH/MED/LOW |
-| 2 | QA Execution | PASS/FAIL | HIGH/MED/LOW |
-| 3 | Code Quality | PASS/FAIL | HIGH/MED/LOW |
-| 4 | Security | PASS/FAIL | Severity |
-| 5 | Context Mining | PASS/FAIL | HIGH/MED/LOW |
+| 1 | Manual QA (orchestrator, real surface) | PASS/FAIL | - |
+| 2 | Gate Review (goal, code quality, security, context, QA audit) | APPROVE/REJECT | HIGH/MED/LOW |
 
 ### Blocking Issues from Holistic Review
 {Aggregated from review-work}

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

@@ -196,12 +196,20 @@ while true:
 
 ### Gate A: CI Checks
 
-CI is the fastest feedback loop. Wait for it to complete, then parse results.
+CI is the fastest feedback loop. Subscribe to its completion via `monitor` — never block a model round-trip on `gh pr checks --watch`.
 
-```bash
-# Wait for checks to start (GitHub needs a moment after push)
-# Then watch for completion
-gh pr checks "$PR_NUMBER" --watch --fail-fast
+```
+# Subscribe to CI completion — the monitor event wakes the session when checks finish.
+# Do NOT use `gh pr checks --watch` as a blocking tool call; it burns a full model
+# round-trip (~29s) on every poll. Instead, register a monitor and end the turn:
+monitor({
+  description: "CI completion for PR $PR_NUMBER",
+  command: "gh pr checks $PR_NUMBER --watch --fail-fast",
+  filter: "completed|fail|cancel"
+})
+# → end turn; the monitor's matching line arrives as an injected event.
+# For a single midpoint status peek (at most once), use:
+#   gh pr checks "$PR_NUMBER"  # one-shot, no --watch
 ```
 
 **On failure**: Get the failed run logs to understand what broke:
@@ -243,20 +251,21 @@ fi
 
 **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:
+Cubic reviews are triggered automatically on PR updates. After pushing a fix, subscribe to the new review arriving — never spin a `for _ in $(seq 1 30)` polling loop that burns model round-trips.
 
-```bash
-# Wait for a NEW Cubic review after push. If none arrives within the bound,
-# Cubic is out of quota (or not running) → skip Gate B rather than spin forever.
+```
+# Subscribe to a NEW Cubic review after push. The monitor exits when a review
+# newer than PUSH_TIME appears, or times out (quota exhausted → Gate B SKIPPED).
 PUSH_TIME=$(date -u +%Y-%m-%dT%H:%M:%SZ)
-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')
-  [[ "$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 B as SKIPPED (quota exhausted)
-[[ "$LATEST_REVIEW_TIME" > "$PUSH_TIME" ]] || echo "Cubic: SKIPPED (no review within bound — quota exhausted)"
+monitor({
+  description: "Cubic review for PR $PR_NUMBER",
+  command: "LATEST=$(gh api repos/${REPO}/pulls/${PR_NUMBER}/reviews --jq '[.[] | select(.user.login == "cubic-dev-ai[bot]")] | last | .submitted_at // empty'); [ -n \"$LATEST\" ] && [ \"$LATEST\" > \"$PUSH_TIME\" ] && echo NEW_REVIEW || echo WAITING",
+  filter: "NEW_REVIEW",
+  timeout_ms: 600000   # 10 min bound — if no review arrives, Gate B is SKIPPED (quota exhausted)
+})
+# → end turn; if the monitor times out without NEW_REVIEW, treat Gate B as SKIPPED.
+# For a single midpoint peek (at most once), use:
+#   gh api "repos/${REPO}/pulls/${PR_NUMBER}/reviews" --jq '[.[] | select(.user.login == "cubic-dev-ai[bot]")] | last | .submitted_at'
 ```
 
 ### Iteration discipline
@@ -292,13 +301,18 @@ gh pr merge "$PR_NUMBER" --merge --auto --delete-branch
 # are green, fall back to a direct merge: gh pr merge "$PR_NUMBER" --merge --delete-branch
 ```
 
-Then WAIT until the merge has actually completed before you report done or clean up - never walk away while the PR is still merging:
+Then subscribe to the merge completing — never block a model round-trip on an `until [ ... MERGED ]` polling loop:
 
-```bash
-# Block until the PR is actually MERGED (auto-merge lands once all required checks pass)
-until [ "$(gh pr view "$PR_NUMBER" --json state -q .state)" = "MERGED" ]; do
-  gh pr checks "$PR_NUMBER" --watch --fail-fast >/dev/null 2>&1 || true   # spend the interval on the checks
-done
+```
+# Subscribe to merge completion. The monitor exits when gh pr view returns MERGED.
+monitor({
+  description: "Merge completion for PR $PR_NUMBER",
+  command: "[ \"$(gh pr view $PR_NUMBER --json state -q .state)\" = \"MERGED\" ] && echo MERGED || echo WAITING",
+  filter: "MERGED",
+  timeout_ms: 1800000   # 30 min bound for auto-merge to land after all gates pass
+})
+# → end turn; the MERGED event wakes the session for the cleanup step.
+# If the monitor times out, check merge state once: gh pr view "$PR_NUMBER" --json state -q .state
 ```
 
 If the user opted out of merging, skip the merge but STILL run the cleanup below: the worktree is removed either way.