@caddis/cli 0.4.34 → 0.4.35

package/bundles/antigravity-plugin/skills/cross-review/SKILL.md

@@ -96,10 +96,18 @@ as a diff that silently is not read. Name a provider explicitly only when you ha
 ## Interpret the exit code
 - **0 — REVIEW: CLEAN** → no blocking issues. Proceed.
 - **1 — REVIEW: BLOCKING** → read the printed findings, then **FIX each blocking item** (or explicitly
-  justify why one is a false positive). Re-run until CLEAN.
+  justify why one is a false positive). Re-run once. A second BLOCKING goes to the owner (rule 3).
 - **4 — error** → no verdict parsed, or a git/endpoint failure. Read stderr; do NOT treat as clean.
 - **3 — misconfigured** → `REVIEW_API_KEY` is unset. Set it (see Prerequisite) and re-run.
 
+## 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.
+
+A diff over the batch ceiling is split into batches. Each batch prompt lists every file in the
+change, so a batch does not report the others as missing.
+
 ## Rules
 - Read-only second opinion — the tool never edits, commits, or pushes. YOU apply fixes in the main thread.
 - Treat exit **3 or 4** as blocking-unknown, never as approval (the tool is fail-closed by

package/bundles/antigravity-plugin/skills/css-architecture/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: css-architecture
-description: CSS architecture, design token strategy, Tailwind conventions, CSS Modules, container queries, dark mode, responsive patterns, and animation architecture. Use for design token naming, CSS custom properties, Tailwind config, container queries, dark mode implementation, fluid typography, or CSS animation decisions. Complements frontend-design (what to achieve) with how to implement it.
+description: "CSS architecture: design tokens, custom properties, Tailwind config, CSS Modules, container queries, dark mode, fluid typography, animation. Covers how to implement styling; frontend-design covers what to achieve."
 ---
 
 # CSS Architecture Skill

package/bundles/antigravity-plugin/skills/dashboard-perf-sweep/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: dashboard-perf-sweep
 context: fork
-description: Re-measure an app's dashboard/API endpoints for load-time regressions and decide, with a documented checklist (not a black-box verdict), whether a slow one is a candidate for the rs-kit summary-table refresher pattern — or needs an index, keyset paging, gzip, or nothing at all. Use when the user says "sweep dashboard performance", "check if this app needs rs-kit", "re-measure the perf tracker", "is this endpoint a refresher candidate", or when a dashboard-performance-tracker.md is stale and needs re-validating. Read-only by default (dev servers only; prod requires an explicit opt-in and human confirmation) and human-invoked, never scheduled -- it surfaces candidates, it does not enroll them.
+description: Re-measure dashboard/API endpoints for load-time regressions and decide by checklist if a slow one needs the rs-kit refresher, an index, keyset paging, gzip, or nothing. Use when the user says "sweep dashboard performance", "check if this app needs rs-kit", "re-measure the perf tracker", "is this endpoint a refresher candidate", or dashboard-performance-tracker.md is stale. Read-only.
 ---
 
 # dashboard-perf-sweep — re-measure, then judge the shape, not just the time

package/bundles/antigravity-plugin/skills/database-design/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: database-design
-description: Database schema design, optimization, and migration patterns for PostgreSQL, MySQL, and NoSQL databases. Use for designing schemas, writing migrations, or optimizing queries.
+description: Database schema design, migrations and query optimization for PostgreSQL, MySQL and NoSQL.
 source: wshobson/agents
 license: MIT
 ---

package/bundles/antigravity-plugin/skills/db-diagram/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: db-diagram
 context: fork
-description: Turn a SQL artifact — a stored procedure, view, query, .sql file, or table name — into a diagram that explains it to a human. Use when the user says "diagram this query/proc/view/schema", "explain this SQL visually", "draw the ER diagram", "show me the data flow of this stored proc", "/mermaid-db", or "/excalidraw-db". Produces Mermaid (default, git-diffable) or Excalidraw (for design reviews). Read-only — never touches the database.
+description: Diagram a SQL artifact (stored proc, view, query, .sql file, table) as Mermaid or Excalidraw. Use when the user says "diagram this query/proc/view/schema", "explain this SQL visually", "draw the ER diagram", "show me the data flow of this stored proc", "/mermaid-db", or "/excalidraw-db". Read-only.
 ---
 
 # db-diagram — explain SQL as a diagram

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

@@ -0,0 +1,61 @@
+---
+name: decide
+description: Record a decision in one step — .caddis/decisions/<date>-<slug>.md
+---
+
+# /caddis:decide — record a decision, once, before it gets re-litigated
+
+A decision made mid-task and never written down gets re-argued the next time someone hits the same
+fork. This command writes it as a single-step decision record.
+
+The request is **$ARGUMENTS** — the decision, in a few words.
+
+## Step 1 — build the slug
+Lower-case the decision text, replace each run of characters outside `a-z0-9` with one `-`, trim
+`-` from both ends, cap at 60 characters (`Use SQLite, not Postgres` → `use-sqlite-not-postgres`). 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/decisions/<YYYY-MM-DD>-<slug>.md`, using today's date (UTC). Create
+`.caddis/decisions/` 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) decision text so the slug
+comes out differently.
+
+## Step 3 — write the file
+
+```markdown
+---
+type: adr
+status: accepted
+found: <YYYY-MM-DD>
+---
+
+# <decision, verbatim>
+
+## Context
+<what forced the decision — the constraint, the conflicting options>
+
+## Decision
+<what was decided, as one plain sentence>
+
+## Consequences
+<what this makes easier, what it makes harder, what it rules out>
+```
+
+## 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.
+
+## Rules
+- **Never** overwrite an existing decision file. There is no ID allocator and no revision counter —
+  a changed decision is new decision text, which naturally gives it a new slug and a new file.
+- This command records a decision already made; it does not itself weigh the options.

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

@@ -6,9 +6,9 @@ description: Park the current workstream on the stack and switch to a new task
 # /caddis:digress — park the current task, switch, never lose the thread
 
 You are about to leave the current task for a related-but-different one (a design decision, a sub-feature,
-or a blocker that must be fixed first). This command **records the original task on a workstream stack** so
-neither you nor the user has to remember and re-state it later — `/catchup [name]` pops it back with its exact
-resume point, and every SessionStart surfaces it (`⛏ Parked workstream: …`).
+or a blocker that must be fixed first). This command **saves the original task as a workstream relay** (`.caddis/relay/<name>.md`) so
+neither you nor the user has to remember and re-state it later — `/catchup <name>` loads it back with its exact
+resume point, and every SessionStart lists it in the workstream index. Loading never removes it.
 
 The reason for the detour is **$ARGUMENTS** (if empty, derive a one-line reason yourself from what the
 user just asked for).
@@ -27,30 +27,48 @@ next-not-started one).
 The single next concrete action for the parked task — copy it from the plan's Tracker or from relay.md's
 `## Next step`. Example: `next: wire the parser to the staging table (see plan Tracker row 2)`.
 
-## Step 3 — push the frame onto `.caddis/workstreams.json`
-The state file is a JSON object `{"version": 1, "stack": [ … ]}`; `stack` is LIFO (last element = most
-recently parked). Each frame has exactly these fields:
-
-```json
-{
-  "plan": ".caddis/plans/<slug>.md",
-  "phase": "<current phase>",
-  "resumePointer": "<the one-line next action from Step 2>",
-  "reason": "<$ARGUMENTS or your derived one-liner>",
-  "repo": null,
-  "pushedAt": "<now, ISO-8601 UTC>"
-}
+## Step 3 — write the workstream relay to `.caddis/relay/<name>.md`
+Write it through the locked script, never with a plain file edit (that would skip the conflict
+check another session relies on). Scripts are in `${CLAUDE_PLUGIN_ROOT}/scripts/` (source
+checkout: `scripts/`).
+
+Your session id is printed at session start as `[caddis] this session's id: <id>`; use it for
+`session_id` and `--session-id`, never a guess.
+
+1. `caddis_workstreams.py hash <name>` — note the printed hash (`none` for a new workstream).
+2. Put the relay below in a temp file, then
+   `caddis_workstreams.py write <name> <temp-file> --expected-hash <hash>`. Exit 1 prints the diff
+   against what another session saved and writes nothing: show it, merge, retry with the new hash.
+3. `caddis_workstreams.py render-index --session-id <id> --branch <branch>` refreshes `.caddis/relay.md`.
+   If it refuses a legacy `.caddis/relay.md`, or an old `.caddis/workstreams.json` stack exists, run
+   `caddis_workstreams.py migrate-legacy` once (it backs up both), then retry.
+
+Relay content, with the standard frontmatter:
+
+```markdown
+---
+type: relay
+workstream: <name>
+branch: <branch>
+session_id: <session_id>
+plan: <plan>
+generated:
+  at: <now, ISO-8601 UTC>
+---
+
+# Relay — <name>
+
+## Current workstream
+<Active plan path + phase>
+
+## Next step (exact)
+<the one-line next action from Step 2>
 ```
 
-- `repo`: `null` means "the plan lives in THIS repo". If the parked plan lives in a **different** repo, set
-  `repo` to that repo's absolute path (the digression spanned repos).
-- Read the file (create `{"version": 1, "stack": []}` if absent). **Idempotency guard:** if the
-  top-of-stack frame's `plan` already equals the plan you are parking, UPDATE that frame in place (refresh
-  `phase`, `resumePointer`, `reason`, `pushedAt`) instead of pushing a duplicate. Otherwise APPEND the new
-  frame. Preserve any unknown fields already present. Write the whole file back (pretty-printed is fine).
+- **Idempotency:** parking the same workstream again replaces its relay through the same hash-checked write; it never duplicates it.
 
 ## Step 4 — confirm, then continue
-Tell the user: `Parked: <plan> @ <phase>. Now switching to: <the new task>.` Then proceed with whatever the
+Tell the user: `Parked workstream: <name>. Saved to .caddis/relay/<name>.md. Now switching to: <the new task>.` Then proceed with whatever the
 user asked — the digression IS the new work.
 
 ## Rules

package/bundles/antigravity-plugin/skills/error-handling/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: error-handling
-description: Error handling patterns for Python and TypeScript applications. Use when designing error hierarchies, implementing retry logic, building error boundaries, or establishing logging strategies. Covers custom exceptions, result types, circuit breakers, and user-facing error messages.
+description: "Error handling for Python and TypeScript: error hierarchies, custom exceptions, result types, retries, circuit breakers, error boundaries, logging, user-facing messages."
 ---
 
 # Error Handling Skill

package/bundles/antigravity-plugin/skills/explainer-doc/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: explainer-doc
 context: fork
-description: Write a document that hands off work to a team who did NOT do the investigation — an external vendor, another team, a contractor — and who must be able to act on it alone. Use when the user says "write a spec for the X team", "document this for someone outside the team", "explainer doc", "implementation spec for a vendor", "hand this off to Y", or is about to write a design doc whose primary reader did not live through the debugging/design process. NOT for internal specs where the reader already has full context (use technical-writing or writing-plans instead) — this is specifically for the "stranger must follow it alone" case.
+description: Hand-off doc for a team that did NOT do the investigation (vendor, contractor, another team) — the "stranger must follow it alone" case. Use when the user says "write a spec for the X team", "document this for someone outside the team", "explainer doc", "implementation spec for a vendor", or "hand this off to Y". Not for readers with full context.
 ---
 
 # explainer-doc — write for the reader who has no other context

package/bundles/antigravity-plugin/skills/feature-plan/SKILL.md

@@ -257,6 +257,11 @@ yourself (relay + Tracker) before stopping — do not hand back "run `/caddis:ha
 <same structure>
 
 ## Execution protocol (standing rules — this plan is the memory, not anyone's head)
+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.
+
 - One phase at a time: read this plan → run the phase on its **Lane** → RED→GREEN→VERIFY→CROSS-REVIEW→
   COMMIT → update the **Tracker** row. The Tracker is the resume signal for every future session.
 - **Session boundaries:** the executor WRITES the handoff (durable `relay.md` + Tracker) after any

package/bundles/antigravity-plugin/skills/frontend-design/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: frontend-design
-description: Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, artifacts, posters, or applications. Generates creative, polished code that avoids generic AI aesthetics while strictly adhering to the user's technical standards.
+description: Create distinctive, production-grade frontend interfaces that avoid generic AI aesthetics. Use when the user asks to build web components, pages, artifacts, posters or applications.
 ---
 
 # Frontend Design Skill

package/bundles/antigravity-plugin/skills/gate-preflight/SKILL.md

@@ -8,6 +8,18 @@ description: Deterministic headless preflight — validates a plan against the a
 Validate the implementation plan at **$ARGUMENTS** against the ACTUAL codebase before any code is
 written.
 
+**Which plan.** An explicit plan argument always wins. Only when `$ARGUMENTS` is 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 validate it.
+- **Exit 3** → no single active plan. Do not ask: name the candidates it printed on stderr (or
+  "none") and end with `PREFLIGHT: FAIL`.
+
 This command exists because `/caddis:preflight` is a model-invoked `context: fork` **SKILL**, and
 skills do not reliably activate under headless `claude -p` — proven live (2026-07-08): a run saw
 the raw `/caddis:code-review <sha-range>` text, didn't recognise it, and replied "I don't see a

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

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

@@ -98,6 +98,20 @@ Watch the PR's checks job-by-job until completion:
 - 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:
@@ -143,6 +157,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
 ---