@caddis/cli 0.4.34 → 0.4.36

package/bundles/antigravity-plugin/skills/cloud-phases/SKILL.md

@@ -0,0 +1,185 @@
+---
+name: cloud-phases
+description: Run plan phases in Claude Code cloud sessions — write one prompt per phase, push, hand out paste lines, then take the PRs back
+---
+
+# /caddis:cloud-phases — run plan phases in the cloud, then take them back
+
+Use this when a plan has phases that can run in parallel and you want them to run in Claude Code
+cloud sessions (claude.ai/code) instead of on this machine. This session stays the orchestrator:
+it writes the work orders, and it reviews and merges the results. The cloud sessions only implement.
+
+**How the code moves.** Nothing syncs between the cloud and this disk. GitHub is the only meeting
+point. This session pushes the feature branch and the prompts. Each cloud session clones from
+GitHub, works on its own branch, and opens a pull request (PR) into the feature branch. This session
+merges each PR on GitHub, then pulls. So a cloud session sees only what is committed and pushed.
+
+Arguments: `$ARGUMENTS`
+
+Two modes:
+- `/caddis:cloud-phases [plan] [phases]` — **dispatch**: Steps 1–6.
+- `/caddis:cloud-phases intake` — **intake**: Step 7, after the owner has run the sessions.
+
+With no plan argument, use the active plan (`python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_todo.py" active-plan`,
+or the one `status: current` plan in `.caddis/plans/`). If there is none, or more than one, ask.
+
+## Step 1 — check the preconditions (stop on any failure)
+
+```
+git remote get-url origin
+git branch --show-current
+git status --short
+gh auth status
+```
+
+- `origin` must be a GitHub repository. Cloud sessions clone from GitHub; a repo with no GitHub
+  remote cannot use this command. Say so and stop.
+- The current branch must be the plan's feature branch, never the default branch. The cloud PRs
+  target this branch, and it goes to `main` later through the normal `/caddis:ship-pr`.
+- Tracked changes must be committed. A cloud session cannot see uncommitted work.
+- `gh` must be signed in as an account that can push to the repository and open PRs.
+
+## Step 2 — pick the phases for the cloud
+
+Take the plan's not-done Tracker rows (or the phase numbers given). Keep a phase **local** when
+any of these is true, and say why:
+- It needs a tool the cloud does not have: Codex, agy, GLM, DeepSeek, a local database, a VPN
+  host, or real data.
+- It needs a gitignored file (for example `.caddis/relay/`, `.env`, keys). The cloud clone does
+  not have them.
+- It needs the owner's go-ahead when it runs (model evals, production), or it is orchestrator
+  work (verification, measurement, release judgement).
+- It depends on a phase that has not merged yet.
+
+Then check the **Touches** lists. Two cloud phases may run at the same time only if they share no
+file. When two phases touch the same file — a shared registry or manifest is the usual case — run
+them one after the other, or keep that shared edit local and make it yourself after both merge.
+
+## Step 3 — check the facts each phase depends on (rule: think before you send)
+
+For each cloud phase, at the feature branch's current head:
+- Confirm every path, function and line number the phase names. Record what you found, with
+  line numbers and the short SHA.
+- Write the edge cases the implementer must handle.
+- Find the exact CI commands for the files it touches (read `.github/workflows/`).
+
+A cloud session cannot ask you anything mid-run. Anything you do not write down, it will guess.
+
+## Step 4 — write one prompt per phase
+
+Write `.caddis/prompts/<release-or-feature>-cloud-phase-<NN>.md`. Every prompt is self-contained,
+with these sections in this order:
+
+```markdown
+---
+type: prompt
+title: <feature> Phase <N> (cloud) — <phase goal in a few words>
+created: <YYYY-MM-DD>
+---
+
+# <feature> Phase <N> — <phase title>
+
+Suggested model: <Opus | Sonnet> (`/model <alias>`). <one line on why>
+
+## Where you are
+- Repository `<owner>/<repo>`. Start from branch `<feature branch>` at its current head.
+  Create branch `<prefix>/phase-<NN>` from it. Work only on that branch.
+- You run in a Claude cloud session. You have no Codex, agy, GLM or DeepSeek, and you cannot see
+  gitignored files. This file and the tracked repo hold everything you need.
+- Read `AGENTS.md` at the repo root first. For background only, read the "Constraints" section of
+  `<plan path>`. Where it differs, this file wins.
+
+## The phase (copied from the plan)
+<Goal, Touches, Design, TDD, Exit gate, Commit message — copied, not summarised>
+
+## Facts already checked (<date>, at <short SHA>)
+- <path:line — what is there>
+
+## Edge cases to handle
+- <edge case>
+
+## Checks to run before you open the PR (the same as CI)
+- `<exact command>`
+Report the literal result of each.
+
+## Finish
+1. Commit on `<prefix>/phase-<NN>` with the commit message above. Stage named files only.
+2. Push the branch: `git push -u origin <prefix>/phase-<NN>`.
+3. Open a PR into `<feature branch>` (never into the default branch). Put the check results in
+   the PR description.
+4. Do not merge. Do not touch other branches. Stop and report the PR link.
+```
+
+The repository may be public. A prompt is committed and pushed, so it must hold no secrets, no
+internal host names, no machine paths and no credentials.
+
+## Step 5 — commit and push, then prove GitHub has it
+
+```
+git add <each prompt file by name>
+git commit -m "docs(prompts): cloud prompts for <feature> phases <N, M>"
+git push -u origin <feature branch>
+git rev-parse HEAD
+git ls-remote origin refs/heads/<feature branch>
+```
+
+The two SHAs must match. If they do not, the cloud sessions will start from old code — stop and fix
+the push first.
+
+## Step 6 — hand the owner the paste table, then stop
+
+Print one row per cloud phase:
+
+| Phase | Model | Branch to pick | Paste this |
+|---|---|---|---|
+| <N> | <Sonnet> | `<feature branch>` | `Read .caddis/prompts/<file> and follow it exactly.` |
+
+Tell the owner, in these words: open https://claude.ai/code, choose repository `<owner>/<repo>`,
+choose branch `<feature branch>`, paste the line, and start. Phases in the table share no file, so
+they can run at the same time. Then **stop**. Record "dispatched to cloud, PR pending" in each
+phase's Tracker row. When the PRs exist, the owner runs `/caddis:cloud-phases intake`.
+
+Do not use the Agent tool with `isolation: "remote"` for this. It has run locally instead of in the
+cloud, which uses no cloud credit and leaves a worktree behind.
+
+## Step 7 — intake: review and merge each PR, then pull
+
+```
+gh pr list --base <feature branch> --state open --json number,title,headRefName,headRefOid
+```
+
+For each PR from a `<prefix>/phase-<NN>` branch, one at a time:
+1. Read the whole diff (`gh pr diff <N>`). Check it against the phase's Design and Touches. A file
+   outside Touches is a finding.
+2. Wait for CI: `gh pr checks <N> --watch` (or the ci-watch lane, if this caddis has it).
+3. Review under the three rules: one review, stop at the first CLEAN; after two blocking reviews,
+   ask the owner. A fix goes back to the same cloud session or is made locally on the PR branch.
+4. Just before merging, re-read `gh pr view <N> --json headRefOid,mergeStateStatus`. Merge only if
+   the head SHA is the one you reviewed and CI passed on it:
+   `gh pr merge <N> --squash --delete-branch`.
+5. Pull: `git pull --ff-only origin <feature branch>`.
+6. Run the phase's exit gate locally, and after the last PR, the full test suite.
+7. Update the phase's Tracker row: status, PR number, merge commit, review result. Set the prompt's
+   frontmatter `status: done` so `/caddis:handoff` tidies it.
+
+Merge in dependency order. If a later PR conflicts after an earlier merge, ask its session to
+rebase on the feature branch, or resolve it locally on that PR branch — never on the feature branch
+directly.
+
+## Running the orchestrator in the cloud too
+The orchestrator can itself be a cloud session. Nothing above needs this machine, because every
+step goes through GitHub. What changes:
+- The owner still opens each worker session by hand at claude.ai/code. An orchestrator cannot
+  start cloud sessions itself.
+- The cloud orchestrator has no Codex, agy, GLM or DeepSeek. Phases on those lanes, and
+  second-vendor reviews, stay for a local session.
+- It cannot see gitignored files, so there is no relay: `/caddis:handoff` state does not carry to
+  the next session. Put the resume state in the plan's Tracker and push it.
+- Its container ends with the session. Push before you stop, every time.
+
+## Rules
+- This command never merges into the default branch. The feature branch goes there later through
+  `/caddis:ship-pr`, and the production boundary check still applies there.
+- One phase, one prompt, one branch, one PR.
+- The orchestrator reads every diff. A green CI run proves only that the tests pass, not that the
+  phase did what its Design says.

package/bundles/antigravity-plugin/skills/code-documentation/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: code-documentation
-description: Writing effective code documentation - API docs, README files, inline comments, and technical guides. Use for documenting codebases, APIs, or writing developer guides.
+description: "Write code documentation: API docs, README files, inline comments and developer guides."
 source: wshobson/agents
 license: MIT
 ---

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

@@ -1,7 +1,7 @@
 ---
 name: code-review
 context: fork
-description: Automated code review for pull requests using specialized review patterns. Analyzes code for quality, security, performance, and best practices. Use when reviewing code changes, PRs, or doing code audits.
+description: Automated code review for quality, security, performance and best practices. Use when reviewing code changes, PRs, or doing code audits.
 source: anthropics/claude-code
 license: Apache-2.0
 ---

package/bundles/antigravity-plugin/skills/codebase-audit/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: codebase-audit
 context: fork
-description: Systematic codebase audit methodology for unfamiliar codebases before architecture or implementation work. Use for new codebase, unfamiliar codebase, pre-implementation audit, codebase review, technical due diligence, or onboarding to an existing project. Produces AUDIT-FINDINGS.md and QUESTIONS.md. Routes to Architect, Planner, or Code Reviewer agents.
+description: Audit an unfamiliar codebase before architecture or implementation work. Use for a new codebase, pre-implementation audit, codebase review, technical due diligence or onboarding. Produces AUDIT-FINDINGS.md and QUESTIONS.md.
 ---
 
 # Codebase Audit Skill

package/bundles/antigravity-plugin/skills/confluence-hla/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: confluence-hla
-description: Author enterprise High-Level Architecture (HLA) documents in Simplified Technical English and generate Confluence Storage Format XHTML with self-contained PlantUML diagrams, wrapped tables, and zero AI fingerprints. Use when creating high-level architecture designs, architecture documentation for Confluence, or converting markdown architecture to Confluence storage format.
+description: High-Level Architecture (HLA) documents in Simplified Technical English as Confluence Storage Format XHTML with PlantUML. Use for Confluence architecture docs or converting markdown architecture.
 ---
 
 # Confluence High-Level Architecture (HLA) Authoring Skill

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

@@ -154,6 +154,21 @@ session that is handed a phase belonging to another lane spawns that lane rather
 work; a headless one records the deviation in the Tracker. Write the launch command out in full, per
 phase — it is executed verbatim.
 
+**Choose each phase's Lane from the routing table.** Run
+`python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_routing.py" show --json`. A phase the orchestrator
+does itself (verification, measurement, release judgement) uses the `critical` role. A phase whose
+Implementer line says "light" uses `light`. Every other phase uses `coding`. Take the first model
+of that role and write its Lane line as follows:
+
+- `opus`: `claude — /model opus`
+- `sonnet`: `claude — /model sonnet`
+- `claude`: `claude — this session`
+- `codex`: codex — `codex exec --ephemeral --sandbox workspace-write "HEADLESS RUN RULES. Read <plan path> and its Constraints. Implement Phase N only in the current checkout. Do not switch or create branches, commit, push, or edit files outside this phase. Run its exit gate and report the literal result."`
+- `agy`: agy — `agy --mode accept-edits --dangerously-skip-permissions --add-dir . --print-timeout 20m --output-format text -p "HEADLESS RUN RULES. Read <plan path> and its Constraints. Implement Phase N only in the current checkout. Do not switch or create branches, commit, push, or edit files outside this phase. Run its exit gate and report the literal result."`
+
+Replace `<plan path>` and `N` with this plan's path and phase number. If the routing command fails
+or exits 3, use `claude — this session` and state the reason in that phase.
+
 #### A phase may take a no-escalation lane only if its exit gate would fail on a spec error
 `glm-headless` cannot escalate: it does what the phase says. So completeness is only half the test —
 the other half is whether being **wrong** would be caught. Ask literally: *"if the instruction I just
@@ -257,6 +272,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