opencode-swarm 7.112.2 → 7.113.1

package/.opencode/skills/brainstorm/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: brainstorm
+audience: swarm-plugin
 description: >
   Full execution protocol for MODE: BRAINSTORM -- structured discovery dialogue, approach selection, spec drafting, QA gate selection, and transition handling.
 ---

package/.opencode/skills/ci-failure-batching/SKILL.md

@@ -1,5 +1,6 @@
----
+---
 name: ci-failure-batching
+audience: swarm-plugin
 description: Batch collection and fix protocol for CI failures. Triggered when any CI check fails on a PR. Prevents serial diagnose-fix-push cycles by collecting all failures before fixing.
 ---
 

package/.opencode/skills/ci-fix-monitor/SKILL.md

@@ -0,0 +1,203 @@
+---
+name: ci-fix-monitor
+audience: swarm-plugin
+description: >
+  Monitor CI on a PR, diagnose failures, fix them, and re-push until green.
+  Covers reading CI logs, classifying failure types (check-title, package-check,
+  test failures, lint), determining the correct fix, and re-pushing.
+triggers:
+  - ci check failure
+  - fix ci
+  - monitor ci
+generated_from_knowledge: []
+source_knowledge_ids: []
+generated_at: 2026-07-02T02:35:49.945Z
+confidence: 0.60
+status: active
+version: 6
+skill_origin: generated
+---
+
+<!-- generated by opencode-swarm skill-generator. Do not edit by hand; edits will be preserved on regeneration only with controlled update mode. -->
+
+# CI Fix & Monitor Protocol
+
+Activates when the user asks to monitor CI, fix CI failures, or resolve red
+checks on a PR.
+
+## Environment note — tool availability
+
+This skill was originally written for desktop Claude Code (Windows) with `gh`
+CLI. In the **remote execution / GitHub MCP** environment, use the equivalent
+MCP tools instead:
+
+| Desktop / `gh` CLI | Remote MCP equivalent |
+|---|---|
+| `gh pr checks <number>` | `mcp__github__pull_request_read` method `get_check_runs` |
+| `gh pr view <number> --json checks` | `mcp__github__pull_request_read` method `get_check_runs` |
+| `gh run view <run-id> --job <job-id> --log` | `mcp__github__get_job_logs` with `job_id` and `return_content: true` |
+| `gh pr edit --title` | `mcp__github__update_pull_request` with `title` |
+| `gh pr view --json mergeable` | `mcp__github__pull_request_read` method `get` |
+
+> MCP tool names are injected by the runtime harness and not guaranteed to be
+> stable across environments. Use `ToolSearch` to verify availability before
+> calling any `mcp__github__*` tool for the first time in a session.
+
+## Step 1 — Fetch current status
+
+Fetch all check runs for the PR head commit. If all green: report success
+and stop.
+
+## Step 2 — Classify each failure
+
+| Failure type | Root cause pattern | Fix action |
+|---|---|---|
+| **check-title** | PR title lacks `<type>(<scope>):` prefix | Update title via PR edit |
+| **package-check** | npm tarball validation failed (source/build/package-manifest problem) | Fix source/build/manifest — see section below. Not generated-file drift. |
+| **branch behind main** | Branch is behind main; main had a release commit; CI uses merge-commit checkout | Rebase onto main, force-push — see section below |
+| **lint/quality: format** | Code style violations (long lines, spacing) | `bunx biome format --write <files>` then commit |
+| **lint/quality: lint** | Lint rule violations (noExplicitAny, etc.) | `bunx biome check --write <files>` or fix manually |
+| **unit test** | Test failures | Read log, fix code, commit |
+| **integration** | Integration failures | Read log, check if pre-existing on main |
+| **macOS unit test** | Cross-platform file I/O race (atomic write-then-read returns null on macOS) | See "macOS file I/O fixes" below |
+| **security** | SAST/secret findings | Read log, fix or suppress with justification |
+| **smoke** | Smoke test failures | Read log, check if environment-specific |
+
+## macOS file I/O fixes (cross-platform atomic write)
+
+macOS/APFS has different filesystem timing than Linux ext4. `fs.renameSync` can
+complete before the data is visible to subsequent reads. The most common
+manifestation is `unit (macos-latest)` failing on tests that write-then-read
+atomic files (e.g., `curator atomic write > writeCuratorSummary > after write,
+readCuratorSummary reads file back successfully`), while the same tests pass
+on `ubuntu-latest` and `windows-latest`.
+
+**Canonical patterns:** See
+`file:.swarm/bundled-skills/writing-tests/SKILL.md`
+§ Cross-Platform Requirements → "macOS rename-visibility race" for the
+full three-layer fix pattern (bunWrite + ENOENT retry + Node FileHandle.sync()
+not fsync()). This skill is a triage pointer; the canonical technical
+reference lives in `writing-tests` so it survives any regeneration of this
+`generated/` file.
+
+**Related security test pattern:** if the CI failure involves a long task ID
+or path, the security test `ADVERSARIAL: Command Services Attack Vectors >
+Attack Vector 1: Malformed Arguments > EVIDENCE: extremely long task ID
+(buffer overflow) - ACCEPTED by regex but no crash` requires a path length
+guard BEFORE `validateSwarmPath` in `src/evidence/manager.ts:loadEvidence`.
+See `file:.swarm/bundled-skills/engineering-conventions/SKILL.md`
+for the evidence file flow that this gate check triggers on macOS CI.
+
+## Step 3 — Diagnose with logs
+
+For every failed check, fetch the full log content. Fetch only the tail
+(last 80–100 lines) unless the error is near the start.
+
+Read the log carefully before concluding root cause. Distinguish between:
+- a failure introduced by this PR,
+- a pre-existing failure on `main` (verify by checking main's last CI run for
+  the same check), and
+- a failure caused by the CI environment or branch drift.
+
+## Step 4 — Fix
+
+### check-title
+No commit needed. Update the PR title.
+
+### package-check failure
+
+`package-check` validates the npm tarball (`npm pack` + tarball contents). A
+failure is a source/build/package-manifest problem, **not** generated-file
+drift. `dist/` is generated and NOT committed — do not stage it. Run
+`bun run build` locally only when you need the bundle to verify the failure:
+
+```bash
+bun run build
+node --input-type=module -e "await import('./dist/index.js'); console.log('dist import OK')"
+```
+
+Fix the underlying source/build/`package.json` `files` manifest issue, then
+commit the source fix (not `dist/`) and push.
+
+### branch behind main (version drift)
+
+**Identifying this case:** A version string differs (`version: "X.Y.Z"` changed
+to a higher version) because main had a release commit after the branch was cut,
+and GitHub Actions checks out the merge-commit for CI. Rebase onto main to pick
+up the release commit.
+
+**Fix:**
+
+```bash
+git fetch origin main
+git rebase origin/main       # fast-forward the branch onto the release commit
+# If the rebase halts with conflicts, run `git rebase --abort` and escalate
+# to the user — do not attempt to resolve a conflicted rebase automatically.
+git push --force-with-lease origin <branch>   # force-push is required after rebase
+```
+
+> `--force-with-lease` is safe here: it refuses to overwrite commits that
+> appeared on the remote after your last fetch. After the rebase, the local
+> branch has diverged from remote history — a regular push will be rejected.
+
+- Do NOT stage or commit `dist/` — it is generated and NOT committed; there is no committed-dist drift check
+- After a rebase, a force-push is required and expected — do not try a regular push
+
+### lint/quality: format violations
+
+Biome format violations (line too long, spacing, bracket style) — these can
+appear when a code change introduces a line that exceeds Biome's print-width.
+Auto-fix only the changed files to minimize noise:
+
+```bash
+bunx biome format --write src/path/to/changed-file.ts
+bun test src/path/to/changed-file.test.ts   # verify tests still pass after format
+git add <files>
+git commit -m "style: apply Biome formatting"
+git push origin <branch>
+```
+
+> Do NOT run `bunx biome format --write .` on the entire repo unless instructed
+> — this can introduce formatting changes in unrelated files and bloat the diff.
+
+### lint/quality: lint rule violations
+
+```bash
+bunx biome check --write <specific-file>
+# or fix manually if --write does not handle the rule
+```
+
+### integration failures
+
+Check whether the same check failed on `main`'s last CI run before treating
+it as PR-introduced. If pre-existing: document the finding and skip. If
+introduced by this PR: collect the full failure log, the test name, and the
+first error line, then delegate to a coder with that evidence.
+
+### security (SAST/secret findings)
+
+Fetch the full log. If it is a secret/credential finding: confirm the file
+and line, remove or rotate the credential, and commit the fix. If it is a
+SAST code-quality finding: collect the rule ID, file, and line, then
+delegate to a coder. Do NOT suppress findings without an explicit
+justification comment approved by the user.
+
+### unit test / smoke failures
+Delegate to coder with specific failure details (test name, assertion, first
+error line). See execute skill.
+
+## Step 5 — Push and monitor
+
+After pushing, subscribe to PR activity (if in webhook/MCP context) and wait
+for the next CI event rather than polling. Do not push a second time until the
+CI result from the first push is confirmed.
+
+If no CI event arrives after a reasonable wait (e.g., checks are still queued
+and stalled), re-fetch check status manually via `get_check_runs` and report
+the stall state to the user rather than waiting indefinitely.
+
+## Step 6 — Verify all green
+
+Do NOT declare victory until ALL required checks pass. A check in `skipped`
+state is acceptable only if the same check was skipped on the base branch
+(i.e. the workflow gates on a path filter). Confirm this explicitly.

package/.opencode/skills/clarify/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: clarify
+audience: swarm-plugin
 description: >
   Full execution protocol for MODE: CLARIFY -- structured clarification funnel with critic review before surfacing user decisions.
 ---

package/.opencode/skills/clarify-spec/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: clarify-spec
+audience: swarm-plugin
 description: >
   Full execution protocol for MODE: CLARIFY-SPEC -- resolving spec clarification markers and maintaining spec/planning alignment.
 ---

package/.opencode/skills/codebase-review-swarm/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: codebase-review-swarm
+audience: swarm-plugin
 description: Run a rigorous, quote-grounded codebase review or security/QA/accessibility/performance/AI-slop/enhancement audit. Use for full-repo or large-subsystem review reports; not for normal implementation. Performs Phase 0 inventory, selected exhaustive tracks with non-diluting depth, coverage closure, reviewer/critic validation, and writes .swarm/review-v8 artifacts without modifying source files.
 license: MIT
 metadata:

package/.opencode/skills/commit-pr/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: commit-pr
+audience: swarm-plugin
 description: >
   Apply when committing, pushing, opening or updating a PR, writing a pull request,
   creating release notes, or closing out remote CI. Enforces the opencode-swarm
@@ -240,6 +241,20 @@ git fetch origin $prBranch
 git push origin "<your-local-branch>:$prBranch" --force-with-lease
 ```
 
+### Fork PR workflow approval
+
+If the PR is from a fork (head repository differs from base repository), GitHub requires explicit workflow approval after every push. CI jobs will remain in "waiting" status until approved:
+
+```bash
+# List pending runs
+gh run list --repo <upstream-owner>/<upstream-repo> --branch <branch-name> --limit 5
+
+# Approve the pending run
+gh api -X POST repos/<upstream-owner>/<upstream-repo>/actions/runs/<run-id>/approve
+```
+
+This requires `actions: write` permission on the base repository. See the `fork-pr-operations` skill for the full protocol including race conditions, permission requirements, and stale CI verification.
+
 ### Pre-push: Push Protection and Canonical Remote
 
 Before `git push`, run both checks:

package/.opencode/skills/consult/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: consult
+audience: swarm-plugin
 description: >
   Full execution protocol for MODE: CONSULT -- answering advisory questions with bounded evidence and clear uncertainty.
 ---

package/.opencode/skills/council/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: council
+audience: swarm-plugin
 description: >
   Full execution protocol for MODE: COUNCIL -- General Council research,
   parallel member dispatch, disagreement handling, and synthesis.

package/.opencode/skills/critic-gate/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: critic-gate
+audience: swarm-plugin
 description: >
   Full execution protocol for MODE: CRITIC-GATE -- plan critic review, revision loops, and hard stop before execution.
 ---

package/.opencode/skills/deep-dive/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: deep-dive
+audience: swarm-plugin
 description: >
   Full execution protocol for MODE: DEEP_DIVE — read-only codebase audit with
   parallel explorer waves, 2 independent reviewers, and sequential critic

package/.opencode/skills/deep-research/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: deep-research
+audience: swarm-plugin
 description: >
   Full execution protocol for MODE: DEEP_RESEARCH — orchestrator-worker deep
   research over external sources: decompose, iterative web_search/web_fetch

package/.opencode/skills/design-docs/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: design-docs
+audience: swarm-plugin
 description: >
   Full execution protocol for MODE: DESIGN_DOCS — generate or sync structured,
   language-agnostic design docs (domain.md, technical-spec.md, behavior-spec.md,
@@ -39,7 +40,7 @@ Have the `docs_design` agent (or `doc_scan`) index `<out>/` to discover any exis
 Dispatch the **`docs_design`** agent (the active swarm's `docs_design` — never the standard `docs` agent) with:
 - `TASK`, `MODE` (generate|sync), `OUT_DIR`, `LANGUAGE`
 - For sync: `FILES CHANGED` and `CHANGES SUMMARY` from the current phase/diff
-- `SKILLS: file:.opencode/skills/design-docs/SKILL.md` (this skill)
+- `SKILLS: file:.swarm/bundled-skills/design-docs/SKILL.md` (this skill)
 
 The agent owns exactly these files under `<out>` and creates NOTHING else:
 

package/.opencode/skills/discover/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: discover
+audience: swarm-plugin
 description: >
   Full execution protocol for MODE: DISCOVER -- read-only repository discovery and governance/context mapping.
 ---

package/.opencode/skills/engineering-conventions/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: engineering-conventions
+audience: swarm-plugin
 description: >
   Guidelines and non-negotiable engineering invariants for modifying opencode-swarm.
   Load before architecture, plugin initialization, subprocess, tool registration, plan
@@ -40,7 +41,7 @@ The full list of 12 invariants is in `AGENTS.md`. The four that have caused the
 
 ## Cross-link: writing tests
 
-For test changes, also load [`.opencode/skills/writing-tests/SKILL.md`](../writing-tests/SKILL.md). It covers `bun:test` API, mock isolation rules, CI per-file isolation, and cross-platform anti-patterns.
+For test changes, also load [`.swarm/bundled-skills/writing-tests/SKILL.md`](../writing-tests/SKILL.md). It covers `bun:test` API, mock isolation rules, CI per-file isolation, and cross-platform anti-patterns.
 
 ## Hard warning: do NOT use broad `test_runner` for repo validation
 

package/.opencode/skills/execute/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: execute
+audience: swarm-plugin
 description: >
   Full execution protocol for MODE: EXECUTE -- task execution, coder retry handling, QA gates, completion evidence, and per-task closure.
 ---

package/.opencode/skills/fork-pr-operations/SKILL.md

@@ -0,0 +1,136 @@
+---
+name: fork-pr-operations
+audience: swarm-plugin
+description: Operational patterns for fork PRs (head repo differs from base repo). Covers GitHub workflow approval after push, force-push protocol, remote naming conventions, stale CI verification, and bot review multi-round awareness. Load when working with fork PRs, cross-repo contributions, or workflow approval issues.
+---
+
+# Fork PR Operations
+
+Fork PRs — where the head repository differs from the base repository — have a distinct operational lifecycle. GitHub treats them with stricter security defaults that require additional steps not needed for same-repo PRs.
+
+## When to use this skill
+
+- You are pushing to a branch on a forked repository
+- CI checks are stuck in "waiting" status after a push
+- You need to rebase a fork PR branch against upstream/main
+- A bot reviewer posts after every push, creating multiple review rounds
+
+## Workflow approval after push
+
+**Critical:** GitHub requires explicit workflow approval for fork PRs. After every push, CI jobs remain in "waiting" status until a user with write access to the base repository approves the workflow run.
+
+### Approval command
+
+```bash
+# List pending workflow runs for the PR
+gh run list --repo <upstream-owner>/<upstream-repo> --branch <branch-name> --limit 5
+
+# Approve a specific run
+gh api -X POST repos/<upstream-owner>/<upstream-repo>/actions/runs/<run-id>/approve
+```
+
+### Race condition: run not yet created
+
+After pushing, there is a brief window (1-5 seconds) before GitHub creates the workflow run object. If you try to approve too quickly, the run won't exist yet. Retry with a short delay:
+
+```bash
+# Wait for run to appear, then approve
+sleep 5
+gh run list --repo <upstream-owner>/<upstream-repo> --branch <branch-name> --limit 1 --json databaseId,status --jq '.[0]'
+# If status is "waiting", approve:
+gh api -X POST repos/<upstream-owner>/<upstream-repo>/actions/runs/<databaseId>/approve
+```
+
+### Permission requirements
+
+The `gh api -X POST .../approve` call requires `actions: write` permission on the **base** (upstream) repository. This typically means your GitHub token needs the `repo` or `public_repo` scope, and you must have write access to the upstream repo. Fork owners without upstream write access cannot approve workflow runs — only upstream maintainers can.
+
+```bash
+gh auth status
+# Verify you have repo/public_repo scope and write access to the upstream repo
+```
+
+## Remote naming conventions
+
+Standard remote setup for fork-based contributions:
+
+```bash
+# origin = your fork
+git remote add origin https://github.com/<your-username>/<repo>.git
+
+# upstream = canonical repository
+git remote add upstream https://github.com/<canonical-owner>/<repo>.git
+
+# Additional forks by owner name (if collaborating across forks)
+git remote add <collaborator> https://github.com/<collaborator>/<repo>.git
+```
+
+## Force-push protocol
+
+Always use `--force-with-lease`, never bare `--force`:
+
+```bash
+# Safe: verifies remote tracking branch matches expected SHA
+git push --force-with-lease origin <branch-name>
+
+# DANGEROUS: overwrites any remote changes, including work by collaborators
+git push --force origin <branch-name>  # NEVER DO THIS
+```
+
+`--force-with-lease` checks that the remote tracking branch matches your local expectation. If someone else pushed between your last fetch and your force-push, the lease check fails safely instead of destroying their work.
+
+## Rebase workflow
+
+To sync a fork PR branch with upstream/main:
+
+```bash
+# Fetch latest from upstream
+git fetch upstream
+
+# Rebase your branch onto upstream/main
+git rebase upstream/main
+
+# Resolve conflicts if any, then continue
+git rebase --continue
+
+# Force-push the rebased branch to your fork
+git push --force-with-lease origin <branch-name>
+```
+
+After rebase + force-push, the PR head SHA changes. All CI checks re-trigger (subject to workflow approval for fork PRs).
+
+## Stale CI verification
+
+After a rebase or force-push, verify CI check data belongs to the current PR head:
+
+```bash
+# Get current PR head SHA
+gh pr view <number> --repo <upstream-owner>/<upstream-repo> --json headRefOid --jq '.headRefOid'
+
+# Check if CI checks match this SHA
+gh pr checks <number> --repo <upstream-owner>/<upstream-repo> --json name,state,startedAt,completedAt
+```
+
+If check data references an older SHA, the checks are stale. Cancel obsolete runs only after confirming they are not the current head:
+
+```bash
+# Cancel a specific run (only if it's NOT the current head)
+gh run cancel <run-id> --repo <upstream-owner>/<upstream-repo>
+```
+
+## Bot review multi-round awareness
+
+Automated bot reviewers (e.g., hermes-pr-review) post a new review after **every push**. If you push N times, you get N bot reviews. This is expected behavior, not a bug.
+
+### Strategy
+
+1. **Ignore APPROVE rounds** from bots. A bot APPROVE after a trivial push adds no signal.
+2. **Scan for new findings only.** Compare the latest bot review against prior rounds to identify newly raised issues.
+3. **Focus on human reviewer findings.** Bot findings are advisory; human reviewer findings are binding.
+4. **Do not attempt to silence the bot.** The multi-round pattern is by design.
+
+## Cross-references
+
+- `.claude/skills/commit-pr/SKILL.md` — PR publication protocol, including `--force-with-lease` guidance and remote check verification
+- `.opencode/skills/swarm-pr-feedback/SKILL.md` — Feedback closure workflow for addressing review findings
+- `.agents/skills/subprocess-safety/SKILL.md` — Subprocess safety for `gh` CLI calls

package/.opencode/skills/gate-attribution/SKILL.md

@@ -1,5 +1,6 @@
----
+---
 name: gate-attribution
+audience: swarm-plugin
 description: Per-task gate dispatch protocol. Documents single-task attribution plus parseable set-dispatch reviewer/test_engineer rows.
 ---
 

package/.opencode/skills/issue-ingest/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: issue-ingest
+audience: swarm-plugin
 description: >
   Full execution protocol for MODE: ISSUE_INGEST -- GitHub issue intake, localization, spec generation, and transition to planning or tracing.
 ---

package/.opencode/skills/loop/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: loop
+audience: swarm-plugin
 description: >
   Full execution protocol for MODE: LOOP — the compound-engineering loop:
   brainstorm → plan → build → review → improve, iterating under
@@ -116,7 +117,7 @@ directly (skip full discovery dialogue) — the objective is already framed.
 ### Phase 1 — BRAINSTORM (cycle 1 only)
 
 - **Entry gate:** objective is non-empty; no approved plan already covers it.
-- **Action:** Load `file:.opencode/skills/brainstorm/SKILL.md` and run it to
+- **Action:** Load `file:.swarm/bundled-skills/brainstorm/SKILL.md` and run it to
   produce `.swarm/spec.md` and a QA gate profile. With `depth=exhaustive`,
   require at least one non-obvious candidate approach.
 - **Exit gate:** `spec.md` exists with explicit, testable success criteria and
@@ -128,13 +129,13 @@ directly (skip full discovery dialogue) — the objective is already framed.
 
 - **Entry gate:** a spec (or, on cycle 2+, the improvement directives) exists.
 - **Action:**
-  1. Load `file:.opencode/skills/pre-phase-briefing/SKILL.md` (required before
+  1. Load `file:.swarm/bundled-skills/pre-phase-briefing/SKILL.md` (required before
      planning, especially on cycle 2+: it reads the prior retrospective and
      verifies codebase reality so the new plan reflects what actually changed).
-  2. Load `file:.opencode/skills/plan/SKILL.md` to decompose the work into
+  2. Load `file:.swarm/bundled-skills/plan/SKILL.md` to decompose the work into
      tasks and call `save_plan`. With `depth=exhaustive`, prefer finer task
      granularity and deeper localization.
-  3. Load `file:.opencode/skills/critic-gate/SKILL.md` to put the plan through
+  3. Load `file:.swarm/bundled-skills/critic-gate/SKILL.md` to put the plan through
      an independent critic.
 - **Exit gate:** critic verdict is APPROVED (NEEDS_REVISION → revise and
   re-submit, max 2 cycles per the critic-gate skill; REJECTED → stop and report
@@ -143,7 +144,7 @@ directly (skip full discovery dialogue) — the objective is already framed.
 ### Phase 3 — BUILD
 
 - **Entry gate:** a critic-approved plan exists.
-- **Action:** Load `file:.opencode/skills/execute/SKILL.md` and run the plan
+- **Action:** Load `file:.swarm/bundled-skills/execute/SKILL.md` and run the plan
   phase by phase. The coder implements each task; per-task QA gates (tests,
   lint, security, etc.) run as defined by the selected QA profile. The coder
   context is the **generator** — it does not get to declare its own work
@@ -188,7 +189,7 @@ This is what makes the loop compound. Do not declare completion without it.
 
 - **Entry gate:** REVIEW exit gate passed.
 - **Action:**
-  1. Load `file:.opencode/skills/phase-wrap/SKILL.md` and write the mandatory
+  1. Load `file:.swarm/bundled-skills/phase-wrap/SKILL.md` and write the mandatory
      retrospective (the `phase_complete` gate blocks without a valid `retro-N`
      bundle). Rescan the codebase and update documentation exactly as the
      phase-wrap skill directs — that is, scoped to its authorized set

package/.opencode/skills/merge-queue-readiness/SKILL.md

@@ -1,5 +1,6 @@
----
+---
 name: merge-queue-readiness
+audience: swarm-plugin
 description: Pre-queue merge-group CI simulation. Triggered before adding a PR to a GitHub merge queue. Prevents merge-queue kick-outs from integration test failures.
 ---