@caddis/cli 0.4.34 → 0.4.36

package/bundles/antigravity-plugin/skills/handoff/SKILL.md

@@ -5,7 +5,7 @@ description: End-of-session handoff — capture exact state so the next session
 
 # /handoff — stop cleanly, write the resume doc
 
-You are ending a work session. Produce/refresh the resume doc (`.caddis/relay.md`) so the next session
+You are ending a work session. Produce/refresh this workstream's resume doc (`.caddis/relay/<name>.md`) so the next session
 (you, a future you, or another agent on any tool) can resume immediately. This is the anti-context-rot checkpoint.
 
 ## Step 1 — capture learnings FIRST (knowledge-transfer)
@@ -103,21 +103,42 @@ Nothing to say is the normal answer. Say nothing and move on — this must not b
 <!-- /shared:harness-friction-question -->
 
 ## Step 3 — write the resume doc (overwrite) with exactly these sections
-> **Where to write:** solo / single active branch → `.caddis/relay.md` (default).
-> **Team / parallel branches** → write `.caddis/relay/<current-branch>.md` instead, so two
-> developers never merge-conflict on one shared relay doc. The SessionStart hook prefers the
-> per-branch file automatically when it exists, then `.caddis/relay.md`, then the legacy
-> `.claude/relay/<branch>.md` and root `relay.md` (back-compat during the migration).
+> **Where to write:** this session's own workstream relay, `.caddis/relay/<name>.md`, through the
+> locked script — never with a plain file edit, which would skip the conflict check. `.caddis/relay.md`
+> is a generated index of all workstreams; do not write it by hand.
 >
-> A repo still on the pre-rename `.claudster/` won't see this relay until it's converted —
-> `/caddis:migrate-dir` does that.
+> Your session id is printed at session start as `[caddis] this session's id: <id>`; use it for
+> `session_id` and `--session-id`. Never guess one: a wrong id disables session matching.
+>
+> 1. **Name the workstream** (active plan's `feature`, else the branch; the script prints nothing
+>    on the default branch with no plan — then ask the user for a short name):
+>    `python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_workstreams.py" resolve --plan <feature> --branch <branch> --default-branch <main>`
+> 2. **Legacy repo:** if `.caddis/relay.md` exists and does not start with
+>    `<!-- caddis-workstream-index-v1 -->`, or an old `/digress` stack `.caddis/workstreams.json`
+>    exists, run `caddis_workstreams.py migrate-legacy` once first.
+>    It backs up the old file and stops without deleting anything on a conflict; report a conflict
+>    to the user and stop.
+> 3. **Read the stored version's hash** before you compose: `caddis_workstreams.py hash <name>`
+>    (prints `none` for a new workstream).
+> 4. **Write** the relay below to a temp file, then
+>    `caddis_workstreams.py write <name> <temp-file> --expected-hash <hash>`. Exit 1 means another
+>    session changed the relay since step 3: it prints the diff and writes nothing. Show the diff,
+>    merge by hand, and retry with the new hash. Never force it.
+> 5. **Refresh the index:** `caddis_workstreams.py render-index --session-id <id> --branch <branch>`.
+>
+> (Source checkout: `scripts/caddis_workstreams.py`.) A repo still on the pre-rename `.claudster/`
+> won't see this relay until it's converted — `/caddis:migrate-dir` does that.
 
 ```markdown
 ---
 type: relay
 workstream: <name>
 branch: <branch>
-generated: { by: <model>, at: <ISO time> }
+plan: <plan file name, or empty>
+session_id: <session id>
+generated:
+  by: <model>
+  at: <ISO time>
 ---
 
 # Relay — <feature>
@@ -148,7 +169,7 @@ advisory-context audit: <N candidates → M gaps → landed in <path>> | n/a (no
 
 ## Resume prompt
 \`\`\`
-Read relay.md, then the plan it points to. Continue from <phase/step>. Next action: <exact>.
+Read .caddis/relay/<name>.md, then the plan it points to. Continue from <phase/step>. Next action: <exact>.
 \`\`\`
 ```
 
@@ -168,7 +189,7 @@ handoff over it.
 ## Step 5 — check the handover you just wrote
 
 ```
-python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_gate.py" handover-check --doc .caddis/relay.md
+python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_gate.py" handover-check --doc .caddis/relay/<name>.md --max-chars 4000
 ```
 (falls back to `scripts/caddis_gate.py` in a source checkout; degrades open when the script is
 missing.) **Run it in the repo the handover is about** — a handover describing another repo will
@@ -181,13 +202,53 @@ incoming Hub looking for a prompt that was never written. Fix what it lists, the
 It also notes any generated artefact committed before its generator last changed. That is advisory,
 not blocking — but do not quote a report the note names without rebuilding it first.
 
+## Step 6 — reconcile task rows from session-state
+Run task reconciliation against the newest session-state file:
+```
+python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_todo.py" reconcile --session-state .caddis/session-state/<session-id>.md
+```
+This marks ad-hoc to-do items done by metadata ID; it never edits the Tracker and ignores phase rows.
+
+## Step 6b — record usage and tidy session state
+The Stop hook only writes the session-state file. These two used to run on every turn; they run
+here, once:
+```
+python "${CLAUDE_PLUGIN_ROOT}/scripts/session_state.py" usage --session-id <session-id>
+python "${CLAUDE_PLUGIN_ROOT}/scripts/session_state.py" prune
+```
+`usage` finds this session's transcript by its id and appends one token-and-skill record to
+`.caddis/usage-log.jsonl`, which `/usage-review` reads. Pass `--transcript <path>` if you know the
+path and it is not under the Claude config folder. `prune` keeps the newest 8 files in
+`.caddis/session-state/`; run it after Step 6, which reads this session's file. Include the
+`[USAGE]` line in your output. Both always exit 0; if the script is missing, skip this step.
+
+Then list old local state (falls back to `scripts/caddis_tidy.py`; skip if missing):
+```
+python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_tidy.py" --prune
+```
+It only lists: session-state files older than 7 days, logs over 5 MB to rotate, and (report
+only, never deleted) orphan `.lock` files and lane worktrees older than 7 days. Include its report. **Never
+add `--apply` yourself**; deleting is the user's choice. If they ask, run `--prune --apply`.
+
+## Step 7 — push prompt (interactive only)
+If this is an interactive session, ask the user every time — never reuse an earlier answer:
+`Push this note for another machine? (y/N)`
+Only on an explicit `y` in this session, run:
+```
+python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_relay_git.py" push <name> --user-said-yes
+```
+It publishes only `.caddis/relay/<name>.md` to `refs/caddis/relay/<name>` — never the branch, the
+index or staged files — after the secret filter passes. Report its one-line result. Anything but
+`y` means do nothing. Headless runs never ask and never push (the script also refuses headless).
+On the other machine, `/catchup <name>` fetches it.
+
 ## Rules
 - **One next action, by priority ladder.** `## Next step` names exactly ONE action — not a menu. Pick it in
   order: (1) interrupted mid-phase work → finish + commit it; else (2) the active plan's next not-started
   phase; else (3) the top open question/decision. Everything else is context, not the next step.
 - Only verified facts and real paths. Mark anything unconfirmed as `Unknown`.
 - Update the plan's tracker rows too (status + last commit) — relay and tracker must agree.
-- Don't commit unless asked. Report where `relay.md` was written and the one next action.
+- Don't commit unless asked. Report which `.caddis/relay/<name>.md` was written and the one next action.
 - **Never hand off a Hub session on the strength of "the context doc is designed for this."** That is the
   one instinct that has been measured and found wrong. Run Step 2b's audit instead.
 - **Prune the Done section — two rules, both apply:**
@@ -198,5 +259,5 @@ not blocking — but do not quote a report the note names without rebuilding it
      are more, collapse the oldest into one summary line:
      `- [N prior milestones — see git log for full history]`
      Keep the 8 most recent bullets below it.
-  Target: relay.md stays under ~80 lines on disk. inject_relay.py caps injection at 120 lines as a
+  Target: the relay stays at most 4,000 characters (handover-check enforces it). inject_relay.py caps injection at 120 lines as a
   safety net, but the file itself should never reach that ceiling.

package/bundles/antigravity-plugin/skills/implement/SKILL.md

@@ -7,6 +7,19 @@ description: Headless plan executor — implement an approved plan phase-by-phas
 
 Implement the plan at **$ARGUMENTS** (falls back to the `DOCKET_PLAN` env var if `$ARGUMENTS` is empty).
 
+**Which plan.** An explicit plan always wins: `$ARGUMENTS` first, then the `DOCKET_PLAN` env var
+(it counts as an explicit argument). Only when both are empty, find the active plan:
+
+```bash
+python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_todo.py" active-plan
+```
+
+- **Exit 0** → stdout is the plan path. Say which plan you picked ("No plan given; using
+  `<path>`.") and implement it.
+- **Exit 3** → no single active plan. Do not guess and do not ask. Stop before any change, list the
+  candidates it printed on stderr (or "none") in the review file, and end with the
+  `"implemented":false` JSON block from step 6.
+
 This command is the **docket Implement lane's driver**. It is spawned autonomously by the docket runner —
 **no human is present**. It does not design or re-plan: the plan is the intelligence, you are the executor.
 The runner independently re-runs the tests and a fresh code-review after you finish and decides success
@@ -35,6 +48,14 @@ depend on them:
   AskUserQuestion. Where the plan leaves a genuine gap, make the smallest reasonable assumption, record it
   in the review file, and proceed — asking is always wrong here.
 
+## Three rules: one attempt, one review
+1. **Think before you send.** Before a task goes to any coder, write its edge cases and check the facts it depends on (one query or one file read).
+2. **Run it before review.** The coder runs the same checks as CI (name the exact commands in the task). Then run the change once on real data.
+3. **Review once.** Use whatever reviewer is available. Stop at the first CLEAN. After two blocking reviews, ask the owner.
+
+This run is headless, so "ask the owner" means: stop the phase, do not commit it, and record the
+two blocking reviews in the review file.
+
 ## What to do
 
 **1. Read the plan.** Load the plan file (`$ARGUMENTS` / `DOCKET_PLAN`). Read its `## Phases`, `## Affected
@@ -145,8 +166,16 @@ row, visible to any later reader without an Advisory Hub having to catch it live
     lane worktrees and branches. It reports unmerged or dirty ones. It pushes the feature branch.
     The plan is not done until it prints `LEFTOVERS: 0`. Then run `/caddis:ship-pr`. Merging and
     post-merge cleanup stay with `/caddis:ship-merge` after the owner's go.
-10. **When Claude is out of budget**, the owner opens `caddis-run codex -m gpt-6-astra` and asks it
-    to follow this same subsection.
+10. **When a dispatched Claude run is out of budget**, read the output from the subagent or
+    `claude -p`. If it holds Claude usage-limit text (for example `You've hit your session limit`
+    or `You're out of extra usage`; the full list is `BUDGET_PATTERNS["claude"]` in
+    `caddis_lanes.py`), run `python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_lanes.py" next-lane --role <the phase's role> --after <the model that ran>`.
+    Re-dispatch the same phase prompt to the printed lane with its direct launch command:
+    `codex exec ...` or `agy ... -p "..."`, using the same form that `/feature-plan` writes.
+    An out-of-budget switch is not an attempt (item 4). Record the fallback in the Tracker
+    `Lane` column, for example `sonnet -> agy (claude out of budget)`.
+    If `next-lane` exits 3, stop and report that no lane is left. As a last resort, the owner can
+    open `caddis-run codex -m gpt-6-astra` and ask it to follow this same subsection.
 
 **Advisory-Hub mode (conditional — OFF by default).** Check whether a companion file
 `<plan-dir>/<plan-stem>-advisory-context.md` exists (e.g. plan `.caddis/plans/foo.md` → look for

package/bundles/antigravity-plugin/skills/mermaid-diagrams/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: mermaid-diagrams
 context: fork
-description: Create software diagrams using Mermaid text-based syntax. Use for class diagrams (domain modeling, OOP design), sequence diagrams (API flows, interactions), flowcharts (processes, algorithms, user journeys), ERD (database schemas), C4 architecture diagrams, state diagrams, git graphs, gantt charts, and data visualization.
+description: "Software diagrams in Mermaid: class, sequence, flowchart, ERD, C4, state, git graph, gantt. Use for domain models, API flows, processes and database schemas."
 ---
 
 # Mermaid Diagramming

package/bundles/antigravity-plugin/skills/mmr/SKILL.md

@@ -20,6 +20,14 @@ An unknown flag returns a usage error.
 The exit codes follow `caddis_exit.py`: 0 clean, 1 blocked, 2 advisory, 3 could not run,
 4 error or bad usage. In particular, `caddis_adhoc.py` returns 4 for bad usage.
 
+## Three rules: one attempt, one review
+1. **Think before you send.** Before a task goes to any coder, write its edge cases and check the facts it depends on (one query or one file read).
+2. **Run it before review.** The coder runs the same checks as CI (name the exact commands in the task). Then run the change once on real data.
+3. **Review once.** Use whatever reviewer is available. Stop at the first CLEAN. After two blocking reviews, ask the owner.
+
+`/mmr` is for handing a task to another model, not for normal reviews. For a normal review, use
+`/cross-review`.
+
 ## Natural Language Triggers
 You can trigger MMR naturally without typing the full slash command:
 - *"Run this on another lane: &lt;task&gt;"* &rarr; `/mmr "<task>"`

package/bundles/antigravity-plugin/skills/particle-art/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: particle-art
 version: 1.0.0
-description: Generate animated particle art React/Next.js components — zero dependencies, spring physics, CSS-variable theming, DPR-correct canvas, mouse interaction. Use when the user wants animated hero art, a living logo, a branded initial or monogram, a constellation background, or any "particles that form a shape". Triggers on "particle animation", "node network", "animated letter/logo/initials", "living letter", "morphing particles", "constellation", "neural net art", "dot field", "stipple portrait", "halftone animation", "ASCII art animation", "background art for my site", or "art that reacts to mouse". Covers — text/initials → spring-node letter; preset patterns (constellation, helix, spiral, DNA, hex-grid, wave, infinity); custom SVG paths; custom polygon points; Unicode halftone stipple; Gaussian dot field with sparks; SVG circuit traces; hybrid combos. Outputs a complete, self-contained, copy-paste-ready React component. Prefer this over p5.js (zero-dep, React-native, TypeScript), tsParticles (richer spring physics, CSS-var theming), Three.js (lightweight, no WebGL).
+description: Zero-dependency animated particle art as a React/Next.js component (spring physics, CSS-variable theming, mouse interaction). Use for animated hero art or a living logo, or on "particles that form a shape", "particle animation", "node network", "animated letter/logo/initials", "living letter", "morphing particles", "constellation", "neural net art", "dot field", "stipple portrait", "halftone animation", "ASCII art animation", "background art for my site", or "art that reacts to mouse".
 ---
 
 # Particle Art Generator

package/bundles/antigravity-plugin/skills/playwright/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: playwright
 context: fork
-description: Complete browser automation with Playwright. Auto-detects dev servers, writes clean test scripts to /tmp. Test pages, fill forms, take screenshots, check responsive design, validate UX, test login flows, check links, automate any browser task. Use when user wants to test websites, automate browser interactions, validate web functionality, or perform any browser-based testing.
+description: "Browser automation and testing with Playwright: auto-detects dev servers; tests pages, forms, logins, links, screenshots and responsive layouts. Use to test websites or automate any browser task."
 ---
 
 **IMPORTANT - Path Resolution:**

package/bundles/antigravity-plugin/skills/port-to-github/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: port-to-github
-description: Move (port) an app or repository to GitHub from ANY source - a Gitea/GitLab/any git server URL, a local folder, a network (UNC) share, or a folder on a remote Windows box reached over WinRM - with or without existing git history. Keeps every branch and tag, verifies by SHA, translates Gitea/Forgejo Actions CI, enforces a source-only content policy (runtimes, binaries, data exports and dependencies stay out of the repo, over ALL history, with a runtime manifest and provisioning script so the environment is still reproducible), switches deploy checkouts to GitHub with automatic rollback, and retires the old host safely. Use when the user says "move this app to GitHub", "port X to GitHub", "migrate from Gitea", "put this folder on GitHub", "this app only exists on the server", "import the repo from the prod box", "keep binaries / MariaDB / PHP out of the repo", "check the repo only holds source", or "cut the deploy over to GitHub".
+description: Port an app or repo to GitHub from any source (git server, local folder, UNC share, Windows box over WinRM) — all branches and tags, SHA-verified, CI translated, history kept source-only, deploy cut over with rollback. Use when the user says "move this app to GitHub", "port X to GitHub", "migrate from Gitea", "put this folder on GitHub", "this app only exists on the server", "import the repo from the prod box", "keep binaries / MariaDB / PHP out of the repo", "check the repo only holds source", or "cut the deploy over to GitHub".
 ---
 
 # port-to-github

package/bundles/antigravity-plugin/skills/pr-merge/SKILL.md

@@ -94,13 +94,38 @@ what failed.
 
 Watch the PR's checks job-by-job until completion:
 - Gitea lane: poll the run for the PR's head SHA via the API (`deploy-local` skill procedure).
-- GitHub lane: `gh pr checks <pr> --watch` / `gh run watch` (`gh-cli` skill).
+- GitHub lane: first record the head you are about to watch, then wait for PR checks outside the Claude session via `ci-watch`:
+  ```bash
+  gh pr view <pr> --json headRefOid        # write down headRefOid as <watched-sha>
+  python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_lanes.py" ci-watch --pr <pr>
+  ```
+  Exit codes: **0** pass → continue; **1** fail → read `FAILING:` and the gh output, classify the cause, apply the minimum source fix, and re-push (stop before merging); **3** could not tell → stop and report, do not merge.
+  Fallback when `caddis_lanes.py` is not available: watch in-session with `gh pr checks <pr> --watch` / `gh run watch` (`gh-cli` skill).
 - If any check fails (red check): report the failure, classify the cause, and **stop before merging**.
   Do not merge a failing PR. Apply the minimum source fix and re-push.
 
+## Step 6b — Deploy boundary (before the merge; nothing skips it)
+
+The PR exists and is green. Run this before the merge:
+
+```bash
+python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_gate.py" deploy-boundary --repo .
+```
+
+Exit **0** — go on to Step 7. Exit **1** (a push to the default branch deploys to production), exit
+**3** (it cannot tell), or any other non-zero code — **stop. Do not merge.** Hand the merge to the
+owner with the PR link; skip Steps 7–9. Show the gate's output and end the command. This holds
+whatever confirmation was given: `--yes`, a confirm flag, "just merge it" or an earlier approval
+cannot bypass it.
+
 ## Step 7 — Merge to default branch
 
 Once all required checks are **green**, there are no merge conflicts, and review requirements are satisfied:
+- Re-read PR head and merge state before merging (GitHub lane):
+  ```bash
+  gh pr view <pr> --json headRefOid,mergeStateStatus
+  ```
+  Merge only when `headRefOid` equals `<watched-sha>`, the head recorded before the watch started and `mergeStateStatus` is `CLEAN` (or `HAS_HOOKS`/`UNSTABLE` only if the repo's own rules allow it; else stop and report). The ci-watch report is a signal, not proof.
 - Use the repo's configured **merge strategy** — read it from repo settings (Gitea repo settings API /
   `gh repo view --json squashMergeAllowed,mergeCommitAllowed,rebaseMergeAllowed`) and `AGENTS.md`;
   an explicit argument wins. Options: **squash**, **merge-commit**, rebase-merge. **Don't assume** —
@@ -114,7 +139,12 @@ Once all required checks are **green**, there are no merge conflicts, and review
 
 If the default branch triggers an automated deployment pipeline:
 - Gitea: `lint_and_test` → `deploy_prod` → `release_metadata` (`deploy-local` skill).
-- GitHub: `gh run watch <run-id> --exit-status` on the default branch. If CI-only, note that no deploy occurs.
+- GitHub: wait for the deploy run on the default branch outside the Claude session via `ci-watch`:
+  ```bash
+  python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_lanes.py" ci-watch --run <run-id>
+  ```
+  Exit codes: **0** pass → continue; **1** fail → read `FAILING:` and the gh output, classify, apply the minimum source fix; **3** could not tell → stop, report, and **skip cleanup** (Step 9).
+  Fallback when `caddis_lanes.py` is not available: watch in-session with `gh run watch <run-id> --exit-status` on the default branch (`gh-cli` skill). If CI-only, note that no deploy occurs.
 - Validate health and deployed SHA if a live service is deployed. If deploy validation fails, report
   immediately and **skip cleanup** (Step 9).
 
@@ -143,6 +173,7 @@ Cleanup:       remote branch deleted / local branch deleted / backup ref dropped
 ## Rules
 
 - Never merge a PR whose required checks are red or absent.
+- Never merge unless `deploy-boundary` exited 0 on this run. No confirmation overrides it.
 - Never delete a feature branch before its merge is confirmed and any deploy validated.
 - Never `git add -A` without reviewing `git status` first (stage named files only).
 - Never force-push without a `backup/*-preship` recovery ref; force pushes are `--force-with-lease` only.

package/bundles/antigravity-plugin/skills/python/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: python-development
-description: Modern Python development with Python 3.12+, Django, FastAPI, async patterns, and production best practices. Use for Python projects, APIs, data processing, or automation scripts.
+description: Modern Python 3.12+ (Django, FastAPI, async) with production best practices. Use for Python projects, APIs, data processing or scripts.
 source: wshobson/agents
 license: MIT
 ---

package/bundles/antigravity-plugin/skills/rca/SKILL.md

@@ -0,0 +1,97 @@
+---
+name: rca
+description: Record a root cause in one step — .caddis/rca/<date>-<slug>.md — or close one with the fixing commit
+---
+
+# /caddis:rca — record a root cause, or close one
+
+A root cause found mid-task gets forgotten by the next session that hits the same symptom. This
+command writes one down in a single step, and closes it later with the commit that fixed it.
+
+The request is **$ARGUMENTS**.
+
+## Mode select
+
+| `$ARGUMENTS` | Do this |
+|---|---|
+| starts with `done ` | Go to **Close mode** |
+| anything else | Go to **File mode** — the text is the symptom |
+
+---
+
+## File mode
+
+### Step 1 — build the slug
+Lower-case the symptom text, replace each run of characters outside `a-z0-9` with one `-`, trim
+`-` from both ends, cap at 60 characters (`Login fails: 401!` → `login-fails-401`). If nothing is left after cleaning, **stop and ask the user for a shorter title** — the
+one question this command may ask.
+
+### Step 2 — pick the path
+`.caddis/rca/<YYYY-MM-DD>-<slug>.md`, using today's date (UTC). Create `.caddis/rca/` first if it
+does not exist.
+
+**If that exact path already exists, refuse — never overwrite it.** Print the existing path and
+stop; the user can open it directly, or pick different (more specific) symptom text so the slug
+comes out differently.
+
+### Step 3 — write the file
+
+```markdown
+---
+type: rca
+status: open
+found: <YYYY-MM-DD>
+---
+
+# <symptom, verbatim>
+
+## Symptom
+<what was observed — the exact error, command, or behaviour>
+
+## Root cause
+<why it happened, not just what happened>
+
+## Fix
+<what changed to remove the cause>
+
+## How verified
+<the command or check that proves the fix, and its result>
+```
+
+Leave a section as its one-line prompt if the answer is not known yet — `/rca done` below is where
+it gets filled in for real.
+
+### Step 4 — verify
+
+```bash
+python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_gate.py" docs-check --root .
+```
+
+Exit 0 means the header is valid. Do not report the item as filed until this passes.
+
+### Step 5 — report
+One line: the path. Nothing else.
+
+---
+
+## Close mode — `done <file>`
+
+`<file>` is a path under `.caddis/rca/`, optionally followed by a commit SHA.
+
+1. If the file does not exist, say so and change nothing.
+2. If its header does not carry `type: rca`, say so and change nothing.
+3. If its `status:` is already `done`, say so and change nothing — closing an already-closed RCA is
+   a no-op, not a re-close.
+4. Otherwise set `status: done` and add `commit: <short SHA>` to the header. The SHA is whatever the
+   user gave after the filename in `$ARGUMENTS`; if none was given, use `git rev-parse --short HEAD`.
+   It must match `^[0-9a-f]{7,40}$`; if it does not, say so and change nothing.
+5. Fill in **Root cause**, **Fix**, and **How verified** only with facts from this session or the
+   fixing commit. A section you do not know stays as its Step 3 prompt; never guess.
+6. Run the Step 4 docs-check. If it does not exit 0, restore the file and report the error.
+7. Report the path and the recorded commit. Nothing else.
+
+## Rules
+- **Never** overwrite an existing RCA file. A repeat symptom is either the same file (edit it by
+  hand) or genuinely different (use different symptom text so the slug comes out different).
+- This command records facts about what already happened; it does not investigate or fix anything
+  itself.

package/bundles/antigravity-plugin/skills/react-dev/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: react-dev
 version: 1.0.0
-description: This skill should be used when building React components with TypeScript, typing hooks, handling events, or when React TypeScript, React 19, Server Components are mentioned. Covers type-safe patterns for React 18-19 including generic components, proper event typing, and routing integration (TanStack Router, React Router).
+description: "Type-safe React 18-19 with TypeScript: components, generic components, hooks, events, Server Components, TanStack Router and React Router. Use when React TypeScript or React 19 is involved."
 ---
 
 # React TypeScript

package/bundles/antigravity-plugin/skills/safe-cleanup/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: safe-cleanup
-description: Use BEFORE deleting any directory tree, clearing a scratchpad, removing git worktrees, or "tidying up" generated folders - especially on Windows, where a recursive delete that meets a junction or symlink destroys the link's TARGET. Also use when verifying that a Python venv or node_modules survived a cleanup, because pip check and file counts both report healthy on a half-deleted environment.
+description: Use BEFORE deleting a directory tree, scratchpad or git worktree, or "tidying up" generated folders, especially on Windows, where deleting through a junction or symlink destroys its target; and to verify a venv or node_modules survived.
 ---
 
 # Safe Cleanup

package/bundles/antigravity-plugin/skills/ship/SKILL.md

@@ -9,10 +9,11 @@ Ship the current working changes via this repo's actual delivery pipeline. The p
 repo, so **detect it first**, then follow the matching lane. Preflight, staging, and commit are
 identical across lanes; only monitoring and validation differ.
 
-> **This is the express lane** — on repos where a push to the default branch deploys, `/ship` sends
-> work straight to prod with no review pause. Right for a hotfix. **For feature work, use the
-> reviewed lane instead: `/ship-pr`** (open a PR, monitor CI, stop at green) **→ `/ship-merge`**
-> (merge the green PR behind a deploy-confirm, validate, clean up).
+> **This is the express lane** — it pushes straight to the default branch with no review pause.
+> Right for a hotfix. On a repo where that push deploys to production, Step 2c stops it before the
+> push and the owner merges. **For feature work, use the reviewed lane instead: `/ship-pr`** (open a
+> PR, monitor CI, stop at green) **→ `/ship-merge`** (merge the green PR behind a deploy-confirm,
+> validate, clean up).
 
 Optional message: **$ARGUMENTS** (if empty, derive a conventional commit message from staged changes)
 
@@ -63,6 +64,19 @@ over 400 changed lines. No judgement in any of those — deliberately, because j
 what failed.
 <!-- /shared:cross-review-trigger -->
 
+**2c. DEPLOY BOUNDARY** — before the push; nothing skips it:
+
+```bash
+python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_gate.py" deploy-boundary --repo .
+```
+
+Exit **0** (no deploy signal found) — push. Exit **1** (a push to the default branch deploys to
+production), exit **3** (it cannot tell), or any other non-zero code — **stop. Do not merge or push to
+the default branch.** The commit stays local. If it sits on the default branch, move it to a feature
+branch first (`git switch -c <feature-branch>`). Then open a PR with `/ship-pr` and hand the merge
+to the owner with the PR link. Show the gate's output and end the command. This holds whatever confirmation was given:
+`--yes`, a confirm flag, "just merge it" or an earlier approval cannot bypass it.
+
 **3. PUSH** — to the repo's default branch (confirm the branch first; don't assume `main`):
 ```
 git push origin <branch>
@@ -81,12 +95,17 @@ Track jobs in order: `lint_and_test` → `frontend_checks` (if present) → `dep
 `release_metadata` → `notify`. Report status as each job completes. On failure, classify it and apply
 the minimum fix (see `deploy-local` skill §6).
 
-**GitHub lane** — Watch the run the push triggered via the `gh` CLI:
-```
+**GitHub lane** — Find the run id for the pushed SHA, then wait outside the Claude session via `ci-watch`:
+```bash
 gh run list --branch <branch> --limit 1                 # find the run id for the pushed SHA
-gh run watch <run-id> --exit-status                      # stream until done; non-zero on failure
+python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_lanes.py" ci-watch --run <run-id>
+```
+Exit codes: **0** pass → continue; **1** fail → read `FAILING:` and the gh output, classify, apply the minimum source fix; **3** could not tell → stop and report.
+On failure, pull only the failing job logs:
+```bash
 gh run view <run-id> --log-failed                        # on failure, pull only the failing job logs
 ```
+Fallback when `caddis_lanes.py` is not available: watch in-session with `gh run watch <run-id> --exit-status` (`gh-cli` skill).
 Report each job's status as it resolves. On failure, classify it and apply the minimum source fix.
 
 **Local-only lane** — no CI; skip monitoring.
@@ -113,6 +132,7 @@ Release tag:     <tag> → <sha> | n/a
 
 ## Rules
 - Never push before preflight gates are green.
+- Never push to the default branch unless `deploy-boundary` exited 0 on this run.
 - Never use `git add -A` without reviewing `git status` first.
 - Do not edit a workflow file (`.gitea/workflows/` or `.github/workflows/`) to make a failing gate
   pass — fix the source.

package/bundles/antigravity-plugin/skills/ship-merge/SKILL.md

@@ -28,6 +28,20 @@ Resolve the target PR from `$ARGUMENTS`, else the current branch's open PR. No o
 that and point at `/ship-pr`. Read `AGENTS.md` + the workflow file(s) for the repo's real deploy
 job names and default branch — never assume.
 
+## Step 0b — Deploy boundary (before the confirm; nothing skips it)
+
+Run it before asking for any confirmation, in a checkout of the PR's own repository. If the
+PR belongs to another repository, treat that as exit **3**.
+
+```bash
+python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_gate.py" deploy-boundary --repo .
+```
+
+Exit **0** — go on to Step 1. Exit **1** (a push to the default branch deploys to production), exit
+**3** (it cannot tell), or any other non-zero code — **stop. Do not merge.** Hand the merge to the
+owner with the PR link. Show the gate's output and end the command. This holds whatever confirmation
+was given: `--yes`, a confirm flag, "just merge it" or an earlier approval cannot bypass it.
+
 ## Step 1 — Refuse unless green + mergeable + reviewed
 
 All of, per the repo's own rules:
@@ -50,10 +64,24 @@ future run — ask every time, even for the same PR five minutes later.
 
 ## Step 3 — Merge
 
+Re-read PR head and merge state before merging (GitHub lane):
+```bash
+gh pr view <pr> --json headRefOid,mergeStateStatus
+```
+Merge only when `headRefOid` equals `<head-sha>` (the head that Step 1 found green and Step 2's
+confirmation named) and `mergeStateStatus` is `CLEAN` (or `HAS_HOOKS`/`UNSTABLE` only if the repo's
+own rules allow it). Otherwise stop and report: a new push needs a fresh Step 1 and a fresh confirm.
+A check report is a signal, not proof.
+
 Use the repo's configured **merge strategy** — read it from repo settings (Gitea repo settings API /
 `gh repo view --json squashMergeAllowed,mergeCommitAllowed,rebaseMergeAllowed`) and `AGENTS.md`;
-an explicit argument wins. Options: **squash**, **merge-commit**, rebase-merge. **Don't assume** —
+an explicit argument wins. Options: **squash**, **merge-commit**, **rebase-merge**. **Don't assume** —
 if detection is inconclusive, say so and use merge-commit (never silently squash someone's history).
+
+Then merge:
+- GitHub: `gh pr merge <pr>` with `--squash` (squash), `--merge` (merge-commit) or `--rebase` (rebase-merge).
+- Gitea: call the Gitea PR merge API with the chosen strategy.
+
 Record the merge SHA.
 
 ## Step 4 — Monitor the deploy
@@ -61,8 +89,12 @@ Record the merge SHA.
 The merge lands on the default branch and triggers the pipeline. Watch it via the lane's skill:
 - Gitea: `lint_and_test` → `frontend_checks` (if present) → **`deploy_prod`** → `release_metadata`
   → `notify` (`deploy-local` skill §monitoring; classify + minimum-fix on failure).
-- GitHub: `gh run watch <run-id> --exit-status` on the default branch; if the workflow has a deploy
-  job, watch it through; if CI-only, note that no deploy occurs.
+- GitHub: wait for the deploy run on the default branch outside the Claude session via `ci-watch`:
+  ```bash
+  python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_lanes.py" ci-watch --run <run-id>
+  ```
+  Exit codes: **0** pass → continue; **1** fail → read `FAILING:` and the gh output, classify, apply the minimum source fix; **3** could not tell → stop, report, and **skip cleanup** (Step 6).
+  Fallback when `caddis_lanes.py` is not available: watch in-session with `gh run watch <run-id> --exit-status` on the default branch (`gh-cli` skill). If the workflow has a deploy job, watch it through; if CI-only, note that no deploy occurs.
 
 ## Step 5 — Post-deploy validation
 
@@ -94,6 +126,7 @@ Cleanup:       remote branch ✗ deleted / local ✗ deleted / backup ref droppe
 
 ## Rules
 - Never merge without: green required checks **and** the explicit human deploy-confirm.
+- Never merge unless `deploy-boundary` exited 0 on this run. No confirmation overrides it.
 - Never delete a branch before its deploy is validated green.
 - Never `git add -A` without reviewing `git status`; never edit a workflow file to make a gate pass.
 - Local-only lane: no PR, no merge — refuse and point at `/ship`.

package/bundles/antigravity-plugin/skills/ship-pr/SKILL.md

@@ -103,7 +103,12 @@ what failed.
 Watch the PR's checks job-by-job (never the deploy — PRs don't deploy here), including the
 scope-guard check when present:
 - Gitea lane: poll the run for the PR's head SHA via the API (`deploy-local` skill procedure).
-- GitHub lane: `gh pr checks <pr> --watch` / `gh run watch` (`gh-cli` skill).
+- GitHub lane: wait for PR checks outside the Claude session via `ci-watch`:
+  ```bash
+  python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_lanes.py" ci-watch --pr <pr>
+  ```
+  Exit codes: **0** pass → continue; **1** fail → read `FAILING:` and the gh output, classify, apply the minimum source fix, then re-push (through Step 4's safety if history must change); **3** could not tell → stop and report, do not merge.
+  Fallback when `caddis_lanes.py` is not available: watch in-session with `gh pr checks <pr> --watch` / `gh run watch` (`gh-cli` skill).
 On a red check, classify the failure and apply the minimum **source** fix, then re-push (through
 Step 4's safety if history must change).
 

package/bundles/antigravity-plugin/skills/skill-creator/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: skill-creator
 context: fork
-description: Create new skills, modify and improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, edit, or optimize an existing skill, run evals to test a skill, benchmark skill performance with variance analysis, or optimize a skill's description for better triggering accuracy.
+description: Create, edit and improve skills, run evals and benchmarks, and optimize a skill's description for triggering accuracy.
 ---
 
 # Skill Creator

package/bundles/antigravity-plugin/skills/sql/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: sql
-description: Write high-quality, optimized SQL with best practices for performance, NULL handling, security, and readability. Database-agnostic patterns with dialect-specific notes.
+description: "Write optimized, secure, readable SQL: performance, NULL handling, dialect-specific notes."
 ---
 
 # SQL Expert Skill