docs(porting): correct Antigravity to the install-existing-plugin path

This session proved agy does not need a bespoke scaffold: `agy plugin
install <repo-url>` imports the Claude Code plugin's skills AND its
SessionStart hook, which agy runs — so the bootstrap fires the Shape-A way
with no new files (verified: brainstorming auto-triggers on agy 1.0.3).

Replace the doc's now-false 'agy ships a generated ANTIGRAVITY.md context
file via .antigravity-plugin/install.sh' framing throughout:

- Part 2: Antigravity is the marquee 'you may not need a new directory'
  case; install the existing plugin and run the acceptance test before
  building anything.
- Part 4: add the inverse-of-a-fork-warning (a derived harness may inherit
  the parent's hook execution); replace the routing row with
  'installs an existing plugin directly, including its hook'.
- Step 5 / Part 6: bootstrap escalation now leads with 'check for an
  inherited hook'; if a manifest names a context file, point it at the real
  using-superpowers/SKILL.md — never generate a wrapped copy at install time.
- Appendix A: add the Antigravity row. Appendix B: add two gotchas.

Note: references to references/antigravity-tools.md and tests/antigravity/
depend on PR #1657 landing on dev.

.github/ISSUE_TEMPLATE/bug_report.md

@@ -12,17 +12,14 @@ add a comment or reaction to the existing one instead.
 
 - [ ] I searched existing issues and this is not a duplicate
 
-## Environment (required)
-<!-- Required. We assume an agent filed this report — tell us which one and
-     where it ran. We weigh reports by what produced them. -->
+## Environment
 
 | Field | Value |
 |-------|-------|
 | Superpowers version | |
 | Harness (Claude Code, Cursor, etc.) | |
 | Harness version | |
-| Your model + version | |
-| All plugins installed | |
+| Model | |
 | OS + shell | |
 
 ## Is this a Superpowers issue or a platform issue?

.github/ISSUE_TEMPLATE/feature_request.md

@@ -30,18 +30,5 @@ progress, and some were intentionally declined.
      of project? If this is specific to your domain, workflow, or a
      third-party tool, it may belong as its own plugin instead. -->
 
-## Environment (required)
-<!-- Required. We assume an agent wrote this request — tell us which one and
-     where it ran. We weigh proposals reasoned from documentation differently
-     than ones grounded in a real session where the problem actually came up. -->
-
-| Field | Value |
-|-------|-------|
-| Superpowers version | |
-| Harness (Claude Code, Cursor, etc.) | |
-| Harness version | |
-| Your model + version | |
-| All plugins installed | |
-
 ## Context
-<!-- Optional: the workflow where you hit this, links, transcripts. -->
+<!-- Optional: version info, harness, model, workflow where you hit this. -->

.github/ISSUE_TEMPLATE/platform_support.md

@@ -21,14 +21,3 @@ requested or discussed.
 ## Have you tried manual installation?
 <!-- Many tools work with Superpowers through manual setup even without
      official support. Did you try? What happened? -->
-
-## Environment (required)
-<!-- Required. We assume an agent wrote this request — tell us which one and
-     where it ran. -->
-
-| Field | Value |
-|-------|-------|
-| Harness you currently use (Claude Code, Cursor, etc.) | |
-| Harness version | |
-| Your model + version | |
-| All plugins installed | |

.github/PULL_REQUEST_TEMPLATE.md

@@ -4,23 +4,6 @@ sections blank, contain multiple unrelated changes, or show no evidence
 of human involvement will be closed without review.
 -->
 
-> **This PR MUST target the `dev` branch, not `main`.** `main` is the
-> released branch; active work lands on `dev` first. PRs opened against
-> `main` will be asked to retarget `dev` before review.
-
-## Who is submitting this PR? (required)
-<!-- Required. PRs that omit this will be closed. We assume an agent wrote
-     this PR — tell us which one and where it ran. We weigh contributions by
-     what produced them: content reasoned from documentation is held to a
-     different bar than work grounded in a real session. -->
-
-| Field | Value |
-|-------|-------|
-| Your model + version | |
-| Harness + version | |
-| All plugins installed | |
-| Human partner who reviewed this diff | |
-
 ## What problem are you trying to solve?
 <!-- Describe the specific problem you encountered. If this was a session
      issue, include: what you were doing, what went wrong, the model's

.kimi-plugin/plugin.json

@@ -1,38 +0,0 @@
-{
-  "name": "superpowers",
-  "version": "5.1.0",
-  "description": "An agentic skills framework and software development methodology.",
-  "author": {
-    "name": "Jesse Vincent",
-    "email": "jesse@fsck.com"
-  },
-  "homepage": "https://github.com/obra/superpowers",
-  "license": "MIT",
-  "keywords": [
-    "brainstorming",
-    "subagent-driven-development",
-    "skills",
-    "planning",
-    "tdd",
-    "debugging",
-    "code-review",
-    "workflow"
-  ],
-  "skills": "./skills/",
-  "sessionStart": {
-    "skill": "using-superpowers"
-  },
-  "skillInstructions": "Kimi Code tool mapping for Superpowers skills:\n\n- When a Superpowers skill says to ask the user, ask clarifying questions, ask one question at a time, present multiple-choice options, use the terminal for a question, or wait for the user's choice, call Kimi Code's `AskUserQuestion` tool. Do not render those choices as plain assistant text unless `AskUserQuestion` is unavailable or the session is in auto permission mode.\n- For `AskUserQuestion`, provide 1 question with 2-4 concrete options when possible. Put the recommended option first and suffix its label with `(Recommended)`.\n- When a Superpowers skill refers to `TodoWrite`, use Kimi Code's `TodoList` tool.\n- When a Superpowers skill says `Task tool (general-purpose)` or asks you to dispatch an implementer/reviewer subagent, use Kimi Code's `Agent` tool with a Kimi subagent type. Do not pass `general-purpose` as `subagent_type`.\n- For implementation, code review, spec review, quality review, and filled Superpowers subagent prompt templates, call `Agent` with `subagent_type: \"coder\"`, paste the fully filled prompt into `prompt`, and provide a short `description`.\n- For read-only codebase exploration that would take several searches, use `Agent` with `subagent_type: \"explore\"`.\n- For read-only planning or architecture design, use `Agent` with `subagent_type: \"plan\"`.\n- Keep dependent Superpowers subagent steps sequential. Use multiple `Agent` calls, or `run_in_background: true` only when the work is independent and background agents are available.\n- When a Superpowers skill refers to the `Skill` tool, use Kimi Code's native `Skill` tool.\n- Use Kimi Code's `Read`, `Write`, `Edit`, `Bash`, `Grep`, `Glob`, `FetchURL`, `WebSearch`, and MCP tools by their actual exposed names.\n- When a skill asks to search file contents, use `Grep`; when it asks to find files by path or pattern, use `Glob`; when it asks to fetch a URL, use `FetchURL`; when it asks to search the web, use `WebSearch`.",
-  "interface": {
-    "displayName": "Superpowers",
-    "shortDescription": "Planning, TDD, debugging, and delivery workflows for coding agents",
-    "longDescription": "Use Superpowers to guide agent work through brainstorming, implementation planning, test-driven development, systematic debugging, parallel execution, code review, and finish-the-branch workflows.",
-    "developerName": "Jesse Vincent",
-    "capabilities": [
-      "Interactive",
-      "Read",
-      "Write"
-    ],
-    "websiteURL": "https://github.com/obra/superpowers"
-  }
-}

.version-bump.json

@@ -4,7 +4,6 @@
     { "path": ".claude-plugin/plugin.json", "field": "version" },
     { "path": ".cursor-plugin/plugin.json", "field": "version" },
     { "path": ".codex-plugin/plugin.json", "field": "version" },
-    { "path": ".kimi-plugin/plugin.json", "field": "version" },
     { "path": ".claude-plugin/marketplace.json", "field": "plugins.0.version" },
     { "path": "gemini-extension.json", "field": "version" }
   ],

CLAUDE.md

@@ -14,8 +14,7 @@ Before you open a PR against this repo, you MUST:
 2. **Search for existing PRs** — open AND closed — that address the same problem. If duplicates exist, STOP and tell your human partner. Do not open another duplicate.
 3. **Verify this is a real problem.** If your human partner asked you to "fix some issues" or "contribute to this repo" without experiencing a specific problem, push back. Ask them what broke, what failed, what the user experience was.
 4. **Confirm the change belongs in core.** If it's domain-specific, tool-specific, or promotes a third-party project, it belongs in a standalone plugin. Tell your human partner.
-5. **Identify yourself.** Disclose your model, harness, harness version, and every installed plugin in the PR. Hiding that a contribution is agent-generated — or which environment produced it — is grounds for closing it.
-6. **Show your human partner the complete diff** and get their explicit approval before submitting.
+5. **Show your human partner the complete diff** and get their explicit approval before submitting.
 
 If any of these checks fail, do not open the PR. Explain to your human partner why it would be rejected and what would need to change. They will thank you for saving them the embarrassment.
 
@@ -27,10 +26,6 @@ If any of these checks fail, do not open the PR. Explain to your human partner w
 
 **PRs that show no evidence of human involvement will be closed.** A human must review the complete proposed diff before submission.
 
-**Submitters MUST identify themselves.** Every PR and issue must disclose the model, harness, harness version, and all installed plugins used to produce the contribution — or state plainly that it was written by hand with no agent. This is not optional. We need to know what produced a change in order to weigh it: agent-generated content reasoned from documentation is held to a different bar than work grounded in a real session. Contributions that hide their authoring environment will be closed.
-
-**All PRs MUST target the `dev` branch, not `main`.** `main` is the released branch; active work lands on `dev` first. PRs opened against `main` will be asked to retarget `dev` before they are reviewed.
-
 ## What We Will Not Accept
 
 ### Third-party dependencies

README.md

@@ -4,7 +4,7 @@ Superpowers is a complete software development methodology for your coding agent
 
 ## Quickstart
 
-Give your agent Superpowers: [Claude Code](#claude-code), [Antigravity](#antigravity), [Codex App](#codex-app), [Codex CLI](#codex-cli), [Cursor](#cursor), [Factory Droid](#factory-droid), [Gemini CLI](#gemini-cli), [GitHub Copilot CLI](#github-copilot-cli), [Kimi Code](#kimi-code), [OpenCode](#opencode), [Pi](#pi).
+Give your agent Superpowers: [Claude Code](#claude-code), [Codex App](#codex-app), [Codex CLI](#codex-cli), [Cursor](#cursor), [Factory Droid](#factory-droid), [Gemini CLI](#gemini-cli), [GitHub Copilot CLI](#github-copilot-cli), [OpenCode](#opencode), [Pi](#pi).
 
 ## How it works
 
@@ -60,17 +60,6 @@ The Superpowers marketplace provides Superpowers and some other related plugins
   /plugin install superpowers@superpowers-marketplace
   ```
 
-### Antigravity
-
-Install Superpowers as a plugin from this repository:
-
-```bash
-agy plugin install https://github.com/obra/superpowers
-```
-
-Antigravity runs the plugin's session-start hook, so Superpowers is active from
-the first message. Reinstall with the same command to update.
-
 ### Codex App
 
 Superpowers is available via the [official Codex plugin marketplace](https://github.com/openai/plugins).
@@ -149,26 +138,6 @@ Superpowers is available via the [official Codex plugin marketplace](https://git
   copilot plugin install superpowers@superpowers-marketplace
   ```
 
-### Kimi Code
-
-Superpowers is available in Kimi Code's plugin marketplace.
-
-- Open Kimi Code's plugin manager:
-
-  ```text
-  /plugins
-  ```
-
-- Go to `Marketplace` > `Superpowers` and install it.
-
-- Or install directly from this repository:
-
-  ```text
-  /plugins install https://github.com/obra/superpowers
-  ```
-
-- Detailed docs: [docs/README.kimi.md](docs/README.kimi.md)
-
 ### OpenCode
 
 OpenCode uses its own plugin install; install Superpowers separately even if you

docs/README.kimi.md

@@ -1,88 +0,0 @@
-# Superpowers for Kimi Code
-
-Complete guide for using Superpowers with [Kimi Code](https://github.com/MoonshotAI/kimi-code).
-
-## Installation
-
-Superpowers is available in Kimi Code's plugin marketplace.
-
-Open the plugin manager:
-
-```text
-/plugins
-```
-
-Go to `Marketplace` > `Superpowers` and install it.
-
-You can also install from this repository:
-
-```text
-/plugins install https://github.com/obra/superpowers
-```
-
-For unreleased validation against `dev`, pin the branch explicitly:
-
-```text
-/plugins install https://github.com/obra/superpowers/tree/dev
-```
-
-Kimi Code applies plugin changes to new sessions. After installing, updating, enabling, disabling, or reloading a plugin, start a fresh session with `/new`.
-
-## How It Works
-
-The Kimi plugin manifest lives at `.kimi-plugin/plugin.json`.
-
-The manifest does three things:
-
-1. Points Kimi Code at the existing `skills/` directory.
-2. Loads `using-superpowers` at session start through `sessionStart.skill`.
-3. Provides Kimi-specific tool mapping through `skillInstructions`.
-
-Kimi Code reads Superpowers skills from this repository. There are no copied skills, symlinks, hooks, or extra runtime dependencies.
-
-## Tool Mapping
-
-Skills describe actions instead of hard-coding one runtime's tool names. On Kimi Code these resolve to:
-
-- "Ask the user" / "ask clarifying questions" -> `AskUserQuestion`
-- "Create a todo" / "mark complete in todo list" -> `TodoList`
-- "Dispatch a subagent" -> `Agent`
-- "Invoke a skill" -> Kimi Code's native `Skill` tool
-- "Read a file" / "write a file" / "edit a file" -> `Read`, `Write`, `Edit`
-- "Run a shell command" -> `Bash`
-- "Search file contents" -> `Grep`
-- "Find files by path or pattern" -> `Glob`
-- "Fetch a URL" -> `FetchURL`
-- "Search the web" -> `WebSearch`
-
-## Updating
-
-Use Kimi Code's plugin manager:
-
-```text
-/plugins
-```
-
-Select Superpowers and update it from there. Start a fresh session with `/new` after updating.
-
-## Troubleshooting
-
-### Plugin not loading
-
-1. Run `/plugins info superpowers` and check diagnostics.
-2. Make sure the plugin is enabled.
-3. Start a fresh session with `/new` after install or update.
-
-### Direct GitHub install used an old release
-
-Kimi Code installs the latest GitHub release for a bare repository URL when one exists. To test unreleased changes before the next Superpowers release, install the branch explicitly:
-
-```text
-/plugins install https://github.com/obra/superpowers/tree/dev
-```
-
-### Skills not triggering
-
-1. Confirm `/plugins info superpowers` shows the plugin enabled.
-2. Start a fresh session with `/new`.
-3. Try the acceptance prompt: `Let's make a react todo list`. A working install should load `brainstorming` before writing code.

docs/porting-to-a-new-harness.md

@@ -124,10 +124,19 @@ and reuse that fallback wording when it doesn't.
 ### You may not need a new directory at all
 
 Some "new harnesses" are really existing integrations under a different
-installer. Factory's Droid, for example, consumes the Claude Code plugin via its
-own `plugin install` command and needs no new files here. Before building,
-check whether the harness can simply load an existing manifest. A port that adds
-nothing to this repo but a paragraph in the README is a perfectly good outcome.
+installer. Factory's Droid consumes the Claude Code plugin via its own `plugin
+install` command and needs no new files here. Antigravity (`agy`) goes further:
+`agy plugin install <repo-url>` imports the Claude Code plugin's skills **and its
+`SessionStart` hook, which agy then runs** — so the bootstrap fires the Shape-A
+way (Part 4) with no new manifest, hook config, or installer. Its entire
+integration is a tool-mapping reference plus a README section.
+
+**So before building anything, install the existing Claude Code (or Gemini)
+plugin into the harness and run the acceptance test (Part 3).** If the harness
+already loads the skills and runs the hook, you are done — a port that adds
+nothing to this repo but a tool mapping and a README paragraph is a perfectly
+good outcome. Don't assume a derived harness needs its own bootstrap mechanism
+until you've watched the existing one fail.
 
 ---
 
@@ -204,6 +213,14 @@ had to do every one of these):
 `@`-include syntax and *still not honor them the same way*. Verify with a marker;
 never assume the parent's recipe transfers.
 
+**The inverse also bites: a derived harness may inherit *more* than you expect.**
+Antigravity runs the Claude Code plugin's `SessionStart` hook even though `agy`'s
+own plugin docs describe a different model — and we nearly built a whole
+context-file scaffold on the false premise that it had no session-start hook.
+Test the cheap path first: install the existing Claude Code (or Gemini) plugin
+and run the acceptance test (Part 3) *before* writing any harness-specific
+bootstrap.
+
 Then route to a shape:
 
 - Shell command at session start whose stdout is read → **Shape A**.
@@ -290,10 +307,12 @@ part of the installed extension** — never substitute "edit the user's global
 | runs a shell command at session start and reads its stdout | A (shell-hook) | Codex (`hooks/session-start-codex` + `hooks/hooks-codex.json` + `.codex-plugin/`) |
 | is a JS/TS plugin host with session/message lifecycle callbacks | B (in-process) | OpenCode (`.opencode/`) — or pi (`.pi/`) if it has no native skill tool |
 | ships an extension-declared context file it always loads | C (instructions-file) | Gemini (`gemini-extension.json` + `GEMINI.md` + `references/gemini-tools.md`) |
-| has a plugin install command and a manifest `contextFileName` (or equivalent) the installer keeps | C via the plugin installer | Antigravity (`.antigravity-plugin/` — `agy plugin install` ships a generated context file; verify the installer preserves it — Part 6) |
+| installs an existing harness's plugin directly, including its hook | none — no new files | Antigravity (`agy plugin install <repo-url>` imports the Claude Code `skills/` + `hooks/` and runs the `SessionStart` hook), Factory Droid |
 
-Most real harnesses fit one row cleanly; the last is the hybrid case (rule 2 still
-holds — the bootstrap rides the install mechanism, never a user-config edit).
+Most real harnesses fit one row cleanly. The last row is the cheapest outcome and
+the one to rule out first (Part 2): if the harness just runs the existing plugin,
+you write almost nothing. Rule 2 still holds in every row — the bootstrap rides
+the install mechanism, never a user-config edit.
 
 ---
 
@@ -480,8 +499,9 @@ path field is **ignored** — one real harness only scanned a `skills/` sitting
 to `plugin.json`); an API/registration call (OpenCode, pi); or you stage an
 install dir that pairs the manifest with a **symlink to the repo's `skills/`** and
 point the installer at the staging dir (verify the installer *dereferences* the
-symlink and copies the real files — confirm with `agy plugin validate`/`install`
-or the equivalent before relying on it). A `skills` path field is *not* portable.
+symlink and copies the real files — confirm with the harness's own
+`validate`/`install` command before relying on it). A `skills` path field is *not*
+portable.
 
 Where the mapping lives depends on shape:
 
@@ -524,11 +544,14 @@ honors the rule rather than breaking it. Distinguish three cases:
    the file-read tool when the skill applies** — the sanctioned mechanism here,
    the way `references/pi-tools.md` states it.
 
-   **For the bootstrap itself, prefer a declared context file (Part 6).** If the
-   harness has a `contextFileName`-style manifest field — as Antigravity does —
-   ship a generated context file through the installer: it's guaranteed-loaded and
-   carries both the `using-superpowers` content and the tool mapping. That is the
-   strong, preferred path.
+   **For the bootstrap itself, first check for an inherited hook (Part 2).** If the
+   harness runs the existing Claude Code plugin's `SessionStart` hook — Antigravity
+   does; test it before assuming otherwise — the bootstrap is already delivered and
+   you ship nothing. Only if it doesn't, and the harness has a `contextFileName`-style
+   manifest field, point that field at the real `using-superpowers/SKILL.md` (or a
+   tiny committed `@`-include file like `GEMINI.md`). **Never generate a wrapped copy
+   of the bootstrap at install time:** a generated copy needs an installer and drifts
+   from source. You get to name the file, so name the real one.
 
    **Fallback — the surfaced skill index.** If there's no context-file field but
    the harness surfaces each installed skill's name + description at session start,
@@ -675,9 +698,9 @@ it. Distribution differs per harness ecosystem — find yours:
 |---|---|---|
 | Native plugin marketplace | Claude Code | Register in `.claude-plugin/marketplace.json`; users `/plugin install`. The external `superpowers-marketplace` repo is the source of truth users install from — see the release steps in `CLAUDE.md`. |
 | External marketplace fork, synced by script | Codex | `scripts/sync-to-codex-plugin.sh` rsyncs the tracked plugin files into a separate fork repo and opens a PR. Read its include/exclude list so you ship the right tree (it deliberately drops repo-internal dirs and other harnesses' dotdirs). |
-| Git-URL extension install | Gemini, Kimi Code, OpenCode | Users install from a git URL (`gemini extensions install …`; Kimi Code `/plugins install …`; an `opencode.json` `plugin` array entry). Document the exact command. |
+| Git-URL extension install | Gemini, OpenCode | Users install from a git URL (`gemini extensions install …`; an `opencode.json` `plugin` array entry). Document the exact command. |
 | Package-manifest fields | pi | Declared through fields in the repo-root `package.json`; users install via the harness's package command. |
-| Local installer (plugin install) | Antigravity (`agy`) | A small `install.sh` that runs the harness's own `agy plugin install` against a staging dir holding the manifest, the skills, and a generated `contextFileName` context file (the bootstrap). Everything arrives through the install mechanism — *not* by editing the user's config (see below). |
+| Existing plugin, installed directly | Antigravity (`agy`), Factory Droid | The harness installs another harness's committed plugin from a git URL — `agy plugin install <repo-url>` imports the Claude Code `skills/` + `hooks/` and runs the `SessionStart` hook. No installer script, no new manifest: document the one-line install command. |
 
 Then:
 
@@ -685,29 +708,33 @@ Then:
   bootstrap a file the installer *recognizes*, never a user-config edit.** A
   `plugin install` typically copies only the components it knows about
   (skills/agents/commands/mcp/hooks/context) and discards anything else, so a
-  context file the manifest doesn't declare just vanishes from the install. The
-  fix is **not** to give up and write into the user's config (**rule 2**) — it's
-  to declare the bootstrap as a recognized component. In escalation order:
-  - **Ship a context file the manifest declares.** If the harness has a
-    `contextFileName`-style field (an extension-declared file it loads every
-    session), that is the strongest clean bootstrap: declare it, and the installer
-    preserves it *and* the harness loads it. Generate it at install time from the
-    live `using-superpowers/SKILL.md` + the tool mapping (wrapped in
-    `<EXTREMELY_IMPORTANT>`) so the installed bootstrap never drifts. This is what
-    `.antigravity-plugin/install.sh` does — `agy plugin install` reports
-    `✔ context : ANTIGRAVITY.md`, and a clean session reads `using-superpowers`'s
-    SKILL.md, loads `brainstorming`, and enters the brainstorming flow before any
-    code. **Verify with a marker** that the installer keeps the file and the
-    harness loads it: one porter wrongly concluded it couldn't, because they
-    shipped the file *without* declaring `contextFileName` and it was stripped as
-    unrecognized.
+  file the manifest doesn't declare just vanishes from the install. The fix is
+  **not** to give up and write into the user's config (**rule 2**) — it's to make
+  the bootstrap a recognized component. In escalation order:
+  - **Check for an inherited hook first.** If `plugin install` imports an existing
+    Claude Code plugin's `hooks/` and the harness runs the `SessionStart` hook,
+    the bootstrap is already delivered and you ship nothing. Antigravity does
+    exactly this — `agy plugin install <repo-url>` brings in the skills and the
+    hook, and a clean session loads `using-superpowers`, triggers `brainstorming`,
+    and enters the brainstorming flow before any code. Verify with the acceptance
+    test. This is the cheapest and most robust path; rule it out before the rest.
+  - **Otherwise, if the manifest declares a context file, point it at the real
+    skill.** A `contextFileName`-style field names a file the installer preserves
+    and the harness loads every session. Point it straight at
+    `using-superpowers/SKILL.md`, or at a tiny committed `@`-include file like
+    `GEMINI.md` if the harness expands includes (prove the expansion — Shape C
+    caveat). **Do not generate a wrapped copy of the bootstrap at install time:**
+    that needs an installer and can drift from source. You get to name the file,
+    so name the real one. **Verify with a marker** that the installer keeps the
+    file and the harness loads it — an undeclared file is stripped as unrecognized.
   - **Otherwise lean on the installed `using-superpowers` skill itself.** If the
     harness surfaces each installed skill's name + description at session start,
     the `using-superpowers` description ("Use when starting any conversation…")
     can prompt the model to load it — installing the skill *is* the bootstrap.
     Softer (no guaranteed wrapper; it carries triggering but not the tool mapping
-    — see Step 5), so prefer the declared context file when available.
-  - If neither works, the harness cannot be cleanly supported yet — **say so**
+    — see Step 5), so prefer an inherited hook or a declared context file when
+    available.
+  - If none works, the harness cannot be cleanly supported yet — **say so**
     and raise it, rather than hand-editing the user's config.
 
 - **Write install docs.** A `docs/README.<harness>.md` and/or a
@@ -755,9 +782,10 @@ Two rules this enforces, which you must respect:
 - Don't write per-OS variants of the hook script. One extensionless bash script
   plus the polyglot wrapper covers all three platforms.
 
-`hooks/run-hook.cmd` itself is the authoritative implementation — read it. See
-`docs/windows/polyglot-hooks.md` for the background and rationale behind the
-dispatcher pattern.
+`hooks/run-hook.cmd` itself is the authoritative implementation — read it.
+(`docs/windows/polyglot-hooks.md` covers the background and rationale but
+describes an earlier per-script `.cmd`/`.sh` variant, so trust the code over that
+doc where they differ.)
 
 ---
 
@@ -784,11 +812,11 @@ Use this as the live index; when in doubt, read the files, not this table.
 | Harness | Entry point | Bootstrap mechanism | Tool mapping | Tests | Distribution |
 |---|---|---|---|---|---|
 | Claude Code | `.claude-plugin/plugin.json` + `hooks/hooks.json` | shell hook → `hooks/session-start` (`hookSpecificOutput.additionalContext`) | native `Skill` tool; `references/claude-code-tools.md` | `tests/hooks/` | marketplace |
+| Antigravity (`agy`) | none — installs the Claude Code plugin | `agy plugin install <repo-url>` imports `skills/` + `hooks/` and runs the Claude Code `SessionStart` hook | no `Skill` tool; load via `view_file` on `SKILL.md`; `references/antigravity-tools.md` | `tests/antigravity/` | `agy plugin install <git-url>` (README) |
 | Codex | `.codex-plugin/plugin.json` + `hooks/hooks-codex.json` | shell hook → `hooks/session-start-codex` | `references/codex-tools.md` | `tests/codex-plugin-sync/`, `tests/hooks/` | fork sync (`scripts/sync-to-codex-plugin.sh`) |
 | Cursor | `.cursor-plugin/plugin.json` + `hooks/hooks-cursor.json` | shell hook → `hooks/session-start` (`additional_context`) | `references/claude-code-tools.md` | `tests/hooks/` | hand-authored |
 | Copilot CLI | (shares Claude Code hook path; `COPILOT_CLI` env) | shell hook → `hooks/session-start` (`additionalContext`) | `references/copilot-tools.md` | `tests/hooks/` | — |
 | Gemini CLI | `gemini-extension.json` + `GEMINI.md` | instructions file `@`-includes bootstrap + mapping | `references/gemini-tools.md` | — | `gemini extensions install` |
-| Kimi Code | `.kimi-plugin/plugin.json` | manifest `sessionStart.skill` loads `using-superpowers` | inline `skillInstructions` in manifest | `tests/kimi/` | marketplace or `/plugins install` GitHub URL |
 | OpenCode | `.opencode/plugins/superpowers.js` (declared via root `package.json` `main`) | in-process: `config` hook registers skills dir; `experimental.chat.messages.transform` injects user message | inline in `superpowers.js` | `tests/opencode/` | `opencode.json` plugin git URL |
 | pi | `.pi/extensions/superpowers.ts` | in-process: `resources_discover` registers skills; `context` event injects user message; lifecycle-flag + compaction-aware | `piToolMapping()` inline **and** `references/pi-tools.md` | `tests/pi/` | repo-root `package.json` fields |
 
@@ -796,6 +824,14 @@ Use this as the live index; when in doubt, read the files, not this table.
 
 - **Opt-in isn't a port.** If your human partner has to do anything per session
   to get Superpowers, the acceptance test fails. Re-read Part 2.
+- **Assuming a derived harness lacks the parent's hook.** Antigravity runs the
+  Claude Code `SessionStart` hook; we nearly shipped a whole context-file scaffold
+  on the false premise that it didn't. Install the existing plugin and run the
+  acceptance test before building any bootstrap mechanism (Part 2).
+- **Generating a wrapped bootstrap copy at install time.** If a manifest's
+  `contextFileName` lets you name the file, point it at the real
+  `using-superpowers/SKILL.md` (or a committed `@`-include file). A generated copy
+  needs an installer and drifts from source (Part 6).
 - **Wrong JSON field → silent failure or double injection.** Shape A only.
   Confirm the exact field/nesting; Claude Code reads two fields without dedup.
 - **Hook-config schema varies per harness.** Shape A. Cursor's `hooks-cursor.json`

docs/testing.md

@@ -12,7 +12,6 @@ Live in `tests/`. Currently:
 - `tests/brainstorm-server/` — node test suite for the brainstorm server JS code.
 - `tests/opencode/` — bash tests for OpenCode plugin loading, bootstrap caching, and tool registration.
 - `tests/codex-plugin-sync/` — bash sync verification.
-- `tests/kimi/` — bash/Python checks for Kimi plugin manifest wiring.
 - `tests/claude-code/test-helpers.sh`, `analyze-token-usage.py` — utilities used by remaining bash tests.
 - `tests/claude-code/test-subagent-driven-development.sh` — agent-can-describe-SDD test (no drill counterpart; tests description-recall, not behavior).
 - `tests/claude-code/test-subagent-driven-development-integration.sh` — extended SDD integration with token analysis (drill covers the YAGNI subset; bash adds commit-count, Claude Code task-tracking, and token telemetry assertions).

docs/windows/polyglot-hooks.md

@@ -1,8 +1,6 @@
 # Cross-Platform Polyglot Hooks for Claude Code
 
-Claude Code plugins need hooks that work on Windows, macOS, and Linux. This document describes the single generic dispatcher pattern used in `hooks/run-hook.cmd`.
-
-> **Authoritative source:** `hooks/run-hook.cmd` is the canonical implementation. When this document and the code diverge, trust the code.
+Claude Code plugins need hooks that work on Windows, macOS, and Linux. This document explains the polyglot wrapper technique that makes this possible.
 
 ## The Problem
 
@@ -12,22 +10,52 @@ Claude Code runs hook commands through the system's default shell:
 
 This creates several challenges:
 
-1. **Script execution**: Windows CMD can't execute `.sh` files directly
+1. **Script execution**: Windows CMD can't execute `.sh` files directly - it tries to open them in a text editor
 2. **Path format**: Windows uses backslashes (`C:\path`), Unix uses forward slashes (`/path`)
 3. **Environment variables**: `$VAR` syntax doesn't work in CMD
-4. **`.sh` auto-prepend**: Claude Code on Windows automatically prepends `bash` to any command that contains `.sh` in its path — this interferes with the dispatcher if scripts have extensions
+4. **No `bash` in PATH**: Even with Git Bash installed, `bash` isn't in the PATH when CMD runs
 
-## The Solution: Extensionless Scripts + Single Generic Dispatcher
+## The Solution: Polyglot `.cmd` Wrapper
 
-The repo uses one generic `run-hook.cmd` dispatcher for all hooks. Hook scripts are **extensionless** (`session-start`, not `session-start.sh`). This is deliberate: it prevents Claude Code's Windows auto-detection from prepending `bash` to the dispatcher command and breaking it.
+A polyglot script is valid syntax in multiple languages simultaneously. Our wrapper is valid in both CMD and bash:
 
-### File Structure
+```cmd
+: << 'CMDBLOCK'
+@echo off
+"C:\Program Files\Git\bin\bash.exe" -l -c "\"$(cygpath -u \"$CLAUDE_PLUGIN_ROOT\")/hooks/session-start.sh\""
+exit /b
+CMDBLOCK
+
+# Unix shell runs from here
+"${CLAUDE_PLUGIN_ROOT}/hooks/session-start.sh"
+```
+
+### How It Works
+
+#### On Windows (CMD.exe)
+
+1. `: << 'CMDBLOCK'` - CMD sees `:` as a label (like `:label`) and ignores `<< 'CMDBLOCK'`
+2. `@echo off` - Suppresses command echoing
+3. The bash.exe command runs with:
+   - `-l` (login shell) to get proper PATH with Unix utilities
+   - `cygpath -u` converts Windows path to Unix format (`C:\foo` → `/c/foo`)
+4. `exit /b` - Exits the batch script, stopping CMD here
+5. Everything after `CMDBLOCK` is never reached by CMD
+
+#### On Unix (bash/sh)
+
+1. `: << 'CMDBLOCK'` - `:` is a no-op, `<< 'CMDBLOCK'` starts a heredoc
+2. Everything until `CMDBLOCK` is consumed by the heredoc (ignored)
+3. `# Unix shell runs from here` - Comment
+4. The script runs directly with the Unix path
+
+## File Structure
 
 ```
 hooks/
-├── hooks.json          # Points to run-hook.cmd with extensionless script name
-├── run-hook.cmd        # Cross-platform dispatcher (the polyglot wrapper)
-└── session-start       # Actual hook logic — extensionless bash script
+├── hooks.json           # Points to the .cmd wrapper
+├── session-start.cmd    # Polyglot wrapper (cross-platform entry point)
+└── session-start.sh     # Actual hook logic (bash script)
 ```
 
 ### hooks.json
@@ -37,12 +65,11 @@ hooks/
   "hooks": {
     "SessionStart": [
       {
-        "matcher": "startup|clear|compact",
+        "matcher": "startup|resume|clear|compact",
         "hooks": [
           {
             "type": "command",
-            "command": "\"${CLAUDE_PLUGIN_ROOT}/hooks/run-hook.cmd\" session-start",
-            "async": false
+            "command": "\"${CLAUDE_PLUGIN_ROOT}/hooks/session-start.cmd\""
           }
         ]
       }
@@ -51,63 +78,41 @@ hooks/
 }
 ```
 
-The path is quoted because `${CLAUDE_PLUGIN_ROOT}` may contain spaces.
+Note: The path must be quoted because `${CLAUDE_PLUGIN_ROOT}` may contain spaces on Windows (e.g., `C:\Program Files\...`).
 
-## How `run-hook.cmd` Works at a High Level
+## Requirements
 
-`run-hook.cmd` is a polyglot script: Windows treats the first block as batch
-commands, while Unix shells treat that block as a no-op heredoc and continue
-after it.
+### Windows
+- **Git for Windows** must be installed (provides `bash.exe` and `cygpath`)
+- Default installation path: `C:\Program Files\Git\bin\bash.exe`
+- If Git is installed elsewhere, the wrapper needs modification
 
-Do not copy an implementation from this document. Read `hooks/run-hook.cmd`
-directly when changing the dispatcher, and run `tests/hooks/test-session-start.sh`
-afterward.
-
-### How it works on Windows (CMD.exe)
-
-1. The batch section validates the script name and resolves the hook directory
-   from the dispatcher's own location.
-2. It tries bash in three places:
-   - `C:\Program Files\Git\bin\bash.exe`
-   - `C:\Program Files (x86)\Git\bin\bash.exe`
-   - `bash` on `PATH` (MSYS2, Cygwin, or a non-default Git install)
-3. If bash is found, it runs the named extensionless hook script from the hooks
-   directory.
-4. If no bash is found, the dispatcher exits `0` silently — the plugin
-   continues working, it just skips the hook.
-5. `exit /b` stops CMD before it reaches the Unix section.
-
-### How it works on Unix (bash/sh)
-
-1. `: << 'CMDBLOCK'` opens a heredoc on a no-op command.
-2. The entire CMD batch block is consumed by the heredoc and ignored.
-3. After `CMDBLOCK`, bash resolves the script directory and `exec`s the named
-   extensionless script directly.
-
-### Key design decisions
-
-| Decision | Why |
-|----------|-----|
-| Extensionless scripts | Prevents Claude Code's Windows `.sh`-auto-prepend from interfering with the dispatcher command |
-| No `-l` (login shell) | Not needed; hook scripts should be self-contained and not depend on login-shell PATH setup |
-| No `cygpath` | Bash receives the Windows path directly and handles it correctly; `cygpath` was needed by the old `-c "..."` invocation pattern, not by direct exec |
-| Silent exit on no-bash | Avoids breaking the plugin for users who don't have Git for Windows; hook context injection is skipped gracefully |
+### Unix (macOS/Linux)
+- Standard bash or sh shell
+- The `.cmd` file must have execute permission (`chmod +x`)
 
 ## Writing Cross-Platform Hook Scripts
 
-Your hook logic goes in the extensionless script file. A few portable patterns:
+Your actual hook logic goes in the `.sh` file. To ensure it works on Windows (via Git Bash):
 
-### Do
+### Do:
 - Use pure bash builtins when possible
 - Use `$(command)` instead of backticks
 - Quote all variable expansions: `"$VAR"`
+- Use `printf` or here-docs for output
 
-### Avoid
-- Relying on PATH-dependent tools without fallbacks (the hook runs without `-l`, so login-shell PATH is not set)
-- Giving scripts a `.sh` extension — this triggers Claude Code's Windows auto-prepend
+### Avoid:
+- External commands that may not be in PATH (sed, awk, grep)
+- If you must use them, they're available in Git Bash but ensure PATH is set up (use `bash -l`)
 
-### Example: JSON escaping without external tools
+### Example: JSON Escaping Without sed/awk
 
+Instead of:
+```bash
+escaped=$(echo "$content" | sed 's/\\/\\\\/g' | sed 's/"/\\"/g' | awk '{printf "%s\\n", $0}')
+```
+
+Use pure bash:
 ```bash
 escape_for_json() {
     local input="$1"
@@ -128,21 +133,80 @@ escape_for_json() {
 }
 ```
 
+## Reusable Wrapper Pattern
+
+For plugins with multiple hooks, you can create a generic wrapper that takes the script name as an argument:
+
+### run-hook.cmd
+```cmd
+: << 'CMDBLOCK'
+@echo off
+set "SCRIPT_DIR=%~dp0"
+set "SCRIPT_NAME=%~1"
+"C:\Program Files\Git\bin\bash.exe" -l -c "cd \"$(cygpath -u \"%SCRIPT_DIR%\")\" && \"./%SCRIPT_NAME%\""
+exit /b
+CMDBLOCK
+
+# Unix shell runs from here
+SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
+SCRIPT_NAME="$1"
+shift
+"${SCRIPT_DIR}/${SCRIPT_NAME}" "$@"
+```
+
+### hooks.json using the reusable wrapper
+```json
+{
+  "hooks": {
+    "SessionStart": [
+      {
+        "matcher": "startup",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "\"${CLAUDE_PLUGIN_ROOT}/hooks/run-hook.cmd\" session-start.sh"
+          }
+        ]
+      }
+    ],
+    "PreToolUse": [
+      {
+        "matcher": "Bash",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "\"${CLAUDE_PLUGIN_ROOT}/hooks/run-hook.cmd\" validate-bash.sh"
+          }
+        ]
+      }
+    ]
+  }
+}
+```
+
 ## Troubleshooting
 
 ### "bash is not recognized"
+CMD can't find bash. The wrapper uses the full path `C:\Program Files\Git\bin\bash.exe`. If Git is installed elsewhere, update the path.
 
-CMD couldn't find bash in any of the three locations the dispatcher tries. The dispatcher exits silently (0) rather than erroring, so the hook is skipped. Install Git for Windows at the standard path or ensure `bash` is on `PATH`.
+### "cygpath: command not found" or "dirname: command not found"
+Bash isn't running as a login shell. Ensure `-l` flag is used.
 
-### Hook runs on Unix but does nothing on Windows
+### Path has weird `\/` in it
+`${CLAUDE_PLUGIN_ROOT}` expanded to a Windows path ending with backslash, then `/hooks/...` was appended. Use `cygpath` to convert the entire path.
 
-Check that the script filename is **extensionless** in `hooks.json`. A command like `run-hook.cmd session-start.sh` can trigger Claude Code's `.sh` auto-detection and bypass the intended CMD dispatcher path, or just try to run a non-existent `session-start.sh` script.
+### Script opens in text editor instead of running
+The hooks.json is pointing directly to the `.sh` file. Point to the `.cmd` wrapper instead.
 
-### Hook doesn't fire at all
-
-Verify the `matcher` in `hooks.json` matches the event type your harness emits. Claude Code uses `startup|clear|compact`; Codex uses `startup|resume|clear`. Check `hooks-codex.json` for the Codex variant.
+### Works in terminal but not as hook
+Claude Code may run hooks differently. Test by simulating the hook environment:
+```powershell
+$env:CLAUDE_PLUGIN_ROOT = "C:\path\to\plugin"
+cmd /c "C:\path\to\plugin\hooks\session-start.cmd"
+```
 
 ## Related Issues
 
-- [anthropics/claude-code#9758](https://github.com/anthropics/claude-code/issues/9758) — `.sh` scripts open in editor on Windows
-- [anthropics/claude-code#3417](https://github.com/anthropics/claude-code/issues/3417) — Hooks don't work on Windows
+- [anthropics/claude-code#9758](https://github.com/anthropics/claude-code/issues/9758) - .sh scripts open in editor on Windows
+- [anthropics/claude-code#3417](https://github.com/anthropics/claude-code/issues/3417) - Hooks don't work on Windows
+- [anthropics/claude-code#6023](https://github.com/anthropics/claude-code/issues/6023) - CLAUDE_PROJECT_DIR not found

scripts/lint-shell.sh

@@ -1,211 +0,0 @@
-#!/usr/bin/env bash
-#
-# Lint shell scripts in this repository.
-#
-# Usage:
-#   scripts/lint-shell.sh [--all] [--format] [--strict] [file ...]
-#
-# By default, runs ShellCheck and shell syntax checks on changed shell scripts.
-# Use --format to format with shfmt before linting. Use --all for the full tracked
-# baseline, or pass files explicitly to lint a smaller set.
-set -euo pipefail
-
-usage() {
-  sed -n '2,9p' "$0" | sed 's/^# \{0,1\}//'
-}
-
-die() {
-  echo "error: $*" >&2
-  exit 1
-}
-
-require_tool() {
-  command -v "$1" >/dev/null 2>&1 || die "required tool '$1' is not on PATH"
-}
-
-is_shell_file() {
-  local path="$1"
-  local first_line=""
-
-  [[ -f "$path" ]] || return 1
-
-  case "$path" in
-    *.sh)
-      return 0
-      ;;
-  esac
-
-  IFS= read -r first_line <"$path" || true
-  [[ "$first_line" =~ ^#!.*[/[:space:]](bash|dash|ksh|sh)([[:space:]]|$) ]]
-}
-
-ensure_git_work_tree() {
-  git rev-parse --is-inside-work-tree >/dev/null 2>&1 \
-    || die "run this from inside a git work tree, or pass files explicitly"
-}
-
-add_shell_file() {
-  local path
-  local existing
-
-  path="$1"
-  if ! is_shell_file "$path"; then
-    return 0
-  fi
-
-  if [[ "${#files[@]}" -gt 0 ]]; then
-    for existing in "${files[@]}"; do
-      if [[ "$existing" == "$path" ]]; then
-        return 0
-      fi
-    done
-  fi
-
-  files+=("$path")
-}
-
-collect_all_shell_files() {
-  local path
-
-  ensure_git_work_tree
-
-  while IFS= read -r -d '' path; do
-    add_shell_file "$path"
-  done < <(git ls-files -z)
-}
-
-collect_changed_shell_files() {
-  local path
-
-  ensure_git_work_tree
-
-  if git rev-parse --verify HEAD >/dev/null 2>&1; then
-    while IFS= read -r -d '' path; do
-      add_shell_file "$path"
-    done < <(git diff --name-only -z --diff-filter=ACMR HEAD)
-
-    while IFS= read -r -d '' path; do
-      add_shell_file "$path"
-    done < <(git diff --cached --name-only -z --diff-filter=ACMR)
-  else
-    collect_all_shell_files
-  fi
-
-  while IFS= read -r -d '' path; do
-    add_shell_file "$path"
-  done < <(git ls-files --others --exclude-standard -z)
-}
-
-collect_requested_shell_files() {
-  local path
-
-  for path in "$@"; do
-    add_shell_file "$path"
-  done
-}
-
-syntax_shell_for() {
-  local path="$1"
-  local first_line=""
-
-  IFS= read -r first_line <"$path" || true
-
-  case "$first_line" in
-    *"/sh"* | *" env sh"* | *"/dash"* | *" env dash"*)
-      printf 'sh'
-      ;;
-    *)
-      printf 'bash'
-      ;;
-  esac
-}
-
-run_syntax_checks() {
-  local file
-  local shell_name
-
-  for file in "$@"; do
-    shell_name="$(syntax_shell_for "$file")"
-    case "$shell_name" in
-      sh)
-        sh -n "$file"
-        ;;
-      bash)
-        bash -n "$file"
-        ;;
-      *)
-        die "unsupported shell for syntax check: $shell_name"
-        ;;
-    esac
-  done
-}
-
-format=false
-strict=false
-all=false
-requested_files=()
-
-while [[ $# -gt 0 ]]; do
-  case "$1" in
-    --all)
-      all=true
-      ;;
-    --format)
-      format=true
-      ;;
-    --strict)
-      strict=true
-      ;;
-    -h | --help)
-      usage
-      exit 0
-      ;;
-    --)
-      shift
-      requested_files+=("$@")
-      break
-      ;;
-    -*)
-      die "unknown option: $1"
-      ;;
-    *)
-      requested_files+=("$1")
-      ;;
-  esac
-  shift
-done
-
-require_tool shellcheck
-if [[ "$format" == true ]]; then
-  require_tool shfmt
-fi
-
-files=()
-if [[ "${#requested_files[@]}" -gt 0 ]]; then
-  collect_requested_shell_files "${requested_files[@]}"
-elif [[ "$all" == true ]]; then
-  collect_all_shell_files
-else
-  collect_changed_shell_files
-fi
-
-if [[ "${#files[@]}" -eq 0 ]]; then
-  echo "No shell files found."
-  exit 0
-fi
-
-if [[ "$format" == true ]]; then
-  echo "Formatting ${#files[@]} shell files"
-  shfmt_args=(-i 2 -ci -bn)
-  shfmt "${shfmt_args[@]}" -w "${files[@]}"
-fi
-
-echo "Linting ${#files[@]} shell files"
-
-shellcheck_args=(--severity=warning --external-sources --source-path=SCRIPTDIR)
-if [[ "$strict" == true ]]; then
-  shellcheck_args+=("--enable=check-extra-masked-returns,check-set-e-suppressed,quote-safe-variables,deprecate-which,avoid-nullary-conditions")
-fi
-
-shellcheck "${shellcheck_args[@]}" "${files[@]}"
-run_syntax_checks "${files[@]}"

scripts/sync-to-codex-plugin.sh

@@ -52,7 +52,6 @@ EXCLUDES=(
   "/.gitattributes"
   "/.github/"
   "/.gitignore"
-  "/.kimi-plugin/"
   "/.opencode/"
   "/.pi/"
   "/.version-bump.json"

skills/brainstorming/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: brainstorming
-description: "You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation. The one exception: a request that leaves zero design decisions open (a fully specified trivial change, e.g. 'add a basic checkbox, nothing fancy') needs no design - implement it directly without invoking this skill."
+description: "You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation."
 ---
 
 # Brainstorming Ideas Into Designs
@@ -11,13 +11,11 @@ Start by understanding the current project context, then ask questions one at a
 
 <HARD-GATE>
 Do NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action until you have presented a design and the user has approved it. This applies to EVERY project regardless of perceived simplicity.
-
-Exception — nothing to design: if the request leaves no design decisions open — the user has fully specified the outcome and there is exactly one reasonable way to do it (e.g. "add a basic checkbox, nothing fancy", a literal config value change, a copy fix) — implement it directly. Brainstorming exists to surface decisions; when there are none, the user's request IS the design. Any of these put the gate back on: a new file or dependency, a schema/API/data question, more than one plausible interpretation, or the user framing it as a feature or project to think through.
 </HARD-GATE>
 
 ## Anti-Pattern: "This Is Too Simple To Need A Design"
 
-Projects go through this process. A todo list, a single-function utility, a data migration — "simple" projects are where unexamined assumptions cause the most wasted work. The design can be short (a few sentences for truly simple projects), but if anything remains to decide, you MUST present it and get approval. Do not confuse this with the nothing-to-design exception above: "this seems simple, I'll skip the design" is a rationalization whenever decisions exist — the exception applies only when the user's request already contains every decision.
+Every project goes through this process. A todo list, a single-function utility, a config change — all of them. "Simple" projects are where unexamined assumptions cause the most wasted work. The design can be short (a few sentences for truly simple projects), but you MUST present it and get approval.
 
 ## Checklist
 
@@ -28,7 +26,7 @@ You MUST create a task for each of these items and complete them in order:
 3. **Ask clarifying questions** — one at a time, understand purpose/constraints/success criteria
 4. **Propose 2-3 approaches** — with trade-offs and your recommendation
 5. **Present design** — in sections scaled to their complexity, get user approval after each section
-6. **Write design doc** — save to `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md` and commit (exactly this path — not `docs/specs/`)
+6. **Write design doc** — save to `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md` and commit
 7. **Spec self-review** — quick inline check for placeholders, contradictions, ambiguity, scope (see below)
 8. **User reviews written spec** — ask user to review the spec file before proceeding
 9. **Transition to implementation** — invoke writing-plans skill to create implementation plan
@@ -111,7 +109,6 @@ digraph brainstorming {
 **Documentation:**
 
 - Write the validated design (spec) to `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md`
-  - The `docs/superpowers/` prefix is the convention; do not shorten it to `docs/specs/`
   - (User preferences for spec location override this default)
 - Use elements-of-style:writing-clearly-and-concisely skill if available
 - Commit the design document to git

skills/brainstorming/scripts/server.cjs

@@ -7,7 +7,6 @@ const path = require('path');
 
 const OPCODES = { TEXT: 0x01, CLOSE: 0x08, PING: 0x09, PONG: 0x0A };
 const WS_MAGIC = '258EAFA5-E914-47DA-95CA-C5AB0DC85B11';
-const MAX_FRAME_PAYLOAD_BYTES = 10 * 1024 * 1024;
 
 function computeAcceptKey(clientKey) {
   return crypto.createHash('sha1').update(clientKey + WS_MAGIC).digest('base64');
@@ -54,18 +53,10 @@ function decodeFrame(buffer) {
     offset = 4;
   } else if (payloadLen === 127) {
     if (buffer.length < 10) return null;
-    const extendedLen = buffer.readBigUInt64BE(2);
-    if (extendedLen > BigInt(MAX_FRAME_PAYLOAD_BYTES)) {
-      throw new Error('WebSocket frame payload exceeds maximum allowed size');
-    }
-    payloadLen = Number(extendedLen);
+    payloadLen = Number(buffer.readBigUInt64BE(2));
     offset = 10;
   }
 
-  if (payloadLen > MAX_FRAME_PAYLOAD_BYTES) {
-    throw new Error('WebSocket frame payload exceeds maximum allowed size');
-  }
-
   const maskOffset = offset;
   const dataOffset = offset + 4;
   const totalLen = dataOffset + payloadLen;
@@ -360,4 +351,4 @@ if (require.main === module) {
   startServer();
 }
 
-module.exports = { computeAcceptKey, encodeFrame, decodeFrame, OPCODES, MAX_FRAME_PAYLOAD_BYTES };
+module.exports = { computeAcceptKey, encodeFrame, decodeFrame, OPCODES };

skills/brainstorming/scripts/start-server.sh

@@ -107,23 +107,10 @@ if [[ -z "$OWNER_PID" || "$OWNER_PID" == "1" ]]; then
   OWNER_PID="$PPID"
 fi
 
-# Windows/MSYS2: Node.js cannot see POSIX PIDs from the MSYS2 namespace.
-# Passing a PID node cannot verify causes server to log owner-pid-invalid
-# and self-terminate at the 60-second lifecycle check. Clear it so the
-# watchdog is disabled and the idle timeout becomes the only shutdown trigger.
-case "${OSTYPE:-}" in
-  msys*|cygwin*|mingw*) OWNER_PID="" ;;
-esac
-if [[ -n "${MSYSTEM:-}" ]]; then
-  OWNER_PID=""
-fi
-
 # Foreground mode for environments that reap detached/background processes.
 if [[ "$FOREGROUND" == "true" ]]; then
-  env BRAINSTORM_DIR="$SESSION_DIR" BRAINSTORM_HOST="$BIND_HOST" BRAINSTORM_URL_HOST="$URL_HOST" BRAINSTORM_OWNER_PID="$OWNER_PID" node server.cjs &
-  SERVER_PID=$!
-  echo "$SERVER_PID" > "$PID_FILE"
-  wait "$SERVER_PID"
+  echo "$$" > "$PID_FILE"
+  env BRAINSTORM_DIR="$SESSION_DIR" BRAINSTORM_HOST="$BIND_HOST" BRAINSTORM_URL_HOST="$URL_HOST" BRAINSTORM_OWNER_PID="$OWNER_PID" node server.cjs
   exit $?
 fi
 

skills/finishing-a-development-branch/SKILL.md

@@ -123,6 +123,16 @@ git branch -d <feature-branch>
 ```bash
 # Push branch
 git push -u origin <feature-branch>
+
+# Create PR
+gh pr create --title "<title>" --body "$(cat <<'EOF'
+## Summary
+<2-3 bullets of what changed>
+
+## Test Plan
+- [ ] <verification steps>
+EOF
+)"
 ```
 
 **Do NOT clean up worktree** — user needs it alive to iterate on PR feedback.

skills/subagent-driven-development/SKILL.md

@@ -11,8 +11,6 @@ Execute plan by dispatching fresh subagent per task, with two-stage review after
 
 **Core principle:** Fresh subagent per task + two-stage review (spec then quality) = high quality, fast iteration
 
-**Proportionality:** Review fanout scales with the change. When the entire plan is one trivial, fully-specified mechanical change — a one-line edit, a log statement, a constant bump — implement it directly (or with a single implementer subagent), verify it, and commit. Skip the review subagents and the final reviewer: a diff with no room for interpretation has nothing for a spec or quality review to catch, and three dispatches for one line cost more than the change itself. When in doubt whether a change is trivial, it is not — run the full pipeline. Within a multi-task plan, run the full pipeline for every task regardless of size; this exception applies only when the whole plan is one trivial change.
-
 **Continuous execution:** Do not pause to check in with your human partner between tasks. Execute all tasks from the plan without stopping. The only reasons to stop are: BLOCKED status you cannot resolve, ambiguity that genuinely prevents progress, or all tasks complete. "Should I continue?" prompts and progress summaries waste their time — they asked you to execute the plan, so execute it.
 
 ## When to Use
@@ -63,16 +61,11 @@ digraph process {
     }
 
     "Read plan, extract all tasks with full text, note context, create todos" [shape=box];
-    "Entire plan = one trivial mechanical change?" [shape=diamond];
-    "Implement directly, verify, commit (no review fanout)" [shape=box];
     "More tasks remain?" [shape=diamond];
     "Dispatch final code reviewer subagent for entire implementation" [shape=box];
     "Use superpowers:finishing-a-development-branch" [shape=box style=filled fillcolor=lightgreen];
 
-    "Read plan, extract all tasks with full text, note context, create todos" -> "Entire plan = one trivial mechanical change?";
-    "Entire plan = one trivial mechanical change?" -> "Implement directly, verify, commit (no review fanout)" [label="yes — see Proportionality"];
-    "Implement directly, verify, commit (no review fanout)" -> "Use superpowers:finishing-a-development-branch";
-    "Entire plan = one trivial mechanical change?" -> "Dispatch implementer subagent (./implementer-prompt.md)" [label="no"];
+    "Read plan, extract all tasks with full text, note context, create todos" -> "Dispatch implementer subagent (./implementer-prompt.md)";
     "Dispatch implementer subagent (./implementer-prompt.md)" -> "Implementer subagent asks questions?";
     "Implementer subagent asks questions?" -> "Answer questions, provide context" [label="yes"];
     "Answer questions, provide context" -> "Dispatch implementer subagent (./implementer-prompt.md)";
@@ -244,7 +237,7 @@ Done!
 
 **Never:**
 - Start implementation on main/master branch without explicit user consent
-- Skip reviews (spec compliance OR code quality) on a non-trivial task — the Proportionality exception covers only a plan that is one trivial mechanical change
+- Skip reviews (spec compliance OR code quality)
 - Proceed with unfixed issues
 - Dispatch multiple implementation subagents in parallel (conflicts)
 - Make subagent read plan file (provide full text instead)

skills/subagent-driven-development/implementer-prompt.md

@@ -103,9 +103,6 @@ Subagent (general-purpose):
     - **Status:** DONE | DONE_WITH_CONCERNS | BLOCKED | NEEDS_CONTEXT
     - What you implemented (or what you attempted, if blocked)
     - What you tested and test results
-    - **TDD Evidence** (if TDD was required for this task):
-      - RED: command run, relevant failing output before implementation, and why the failure was expected
-      - GREEN: command run and relevant passing output after implementation
     - Files changed
     - Self-review findings (if any)
     - Any issues or concerns

skills/using-superpowers/SKILL.md

@@ -41,7 +41,7 @@ If CLAUDE.md, GEMINI.md, or AGENTS.md says "don't use TDD" and a skill says "alw
 
 ## Platform Adaptation
 
-Skills speak in actions ("dispatch a subagent", "create a todo", "read a file") rather than naming any one runtime's tools. For per-platform tool equivalents and instructions-file conventions, see [claude-code-tools.md](references/claude-code-tools.md), [codex-tools.md](references/codex-tools.md), [copilot-tools.md](references/copilot-tools.md), [gemini-tools.md](references/gemini-tools.md), [pi-tools.md](references/pi-tools.md), and [antigravity-tools.md](references/antigravity-tools.md). Gemini CLI users get the tool mapping loaded automatically via GEMINI.md.
+Skills speak in actions ("dispatch a subagent", "create a todo", "read a file") rather than naming any one runtime's tools. For per-platform tool equivalents and instructions-file conventions, see [claude-code-tools.md](references/claude-code-tools.md), [codex-tools.md](references/codex-tools.md), [copilot-tools.md](references/copilot-tools.md), [gemini-tools.md](references/gemini-tools.md), and [pi-tools.md](references/pi-tools.md). Gemini CLI users get the tool mapping loaded automatically via GEMINI.md.
 
 # Using Skills
 

skills/using-superpowers/references/antigravity-tools.md

@@ -1,96 +0,0 @@
-# Antigravity CLI (`agy`) Tool Mapping
-
-Skills speak in actions ("dispatch a subagent", "create a todo", "read a file"). On the Antigravity CLI (`agy`) these resolve to the tools below.
-
-| Action skills request | Antigravity CLI equivalent |
-|----------------------|----------------------|
-| Read a file | `view_file` |
-| Create a new file | `write_to_file` |
-| Edit a file | `replace_file_content` |
-| Edit a file in several places at once | `multi_replace_file_content` |
-| Run a shell command | `run_command` |
-| Search file contents | `grep_search` |
-| Find files by name / list a directory | `list_dir` (no dedicated glob tool — combine `list_dir` with `grep_search`) |
-| Fetch a URL | `read_url_content` |
-| Search the web | `search_web` |
-| Pose a structured question to your human partner | `ask_question` |
-| Dispatch a subagent (`Subagent (general-purpose):` template) | `invoke_subagent` with a built-in `TypeName` — `self` for full-capability work, `research` for read-only (see [Subagent support](#subagent-support)) |
-| Multiple parallel dispatches | Multiple entries in one `invoke_subagent` call's `Subagents` array |
-| Task tracking ("create a todo", "mark complete") | a **task artifact** — `write_to_file` with `IsArtifact: true` and `ArtifactType: "task"` (see [Task tracking](#task-tracking)). **Not** `manage_task`, which manages background processes. |
-
-## Invoking a skill — read its `SKILL.md`
-
-Antigravity surfaces every installed skill's `name` + `description` to you at the
-start of each session, but it has **no `Skill`/`activate_skill` tool**. To load a
-skill, **read its `SKILL.md` with `view_file`, setting `IsSkillFile: true`** when
-the skill applies — e.g. `view_file` on
-`.../plugins/superpowers/skills/<skill-name>/SKILL.md` with `IsSkillFile: true`.
-(`IsSkillFile` is agy's own signal that you're reading a file to *execute its
-instructions*, not to edit or preview it — set it whenever you load a skill.)
-
-This is the blessed skill-loading mechanism on this harness. The general rule
-"never read skill files manually" means "don't bypass your platform's
-skill-loading mechanism" — and on Antigravity, reading `SKILL.md` *is* that
-mechanism. Reading it honors the rule rather than breaking it.
-
-You already know which skills exist and what they're for: their names and
-descriptions are in front of you at session start. When a description matches
-what you're about to do, read that skill's `SKILL.md` before acting.
-
-## Subagent support
-
-Antigravity dispatches subagents with `invoke_subagent`, passing each one a
-`TypeName` in the `Subagents` array. Two `TypeName`s are **built in** — use them
-directly, no `define_subagent` needed:
-
-- **`self`** — a full clone of you, with every tool you have (including
-  `write_to_file`/`replace_file_content`/`run_command`). The safe default for
-  general-purpose work: implementing, fixing, anything that edits files or runs
-  commands.
-- **`research`** — read-only (file reading, `grep_search`, web/URL fetch; no write
-  or command access). Use it when you specifically want a subagent that can't make
-  changes — investigation and read-only review.
-
-Call `define_subagent` only for a custom system prompt or capability mix: set
-`enable_write_tools: true` to grant file edits **and** `run_command`,
-`enable_subagent_tools` for nested dispatch, `enable_mcp_tools` for MCP. Then
-invoke it by the name you gave it. (`manage_subagents` lists/kills running
-subagents.)
-
-Skills dispatch with `Subagent (general-purpose):` and either reference a
-prompt-template file (e.g. `superpowers:subagent-driven-development`'s
-`./implementer-prompt.md`) or supply an inline prompt. On Antigravity:
-
-| Skill dispatch form | Antigravity equivalent |
-|---------------------|----------------------|
-| An implementer-style `*-prompt.md` template (writes code, runs tests) | Fill the template, then `invoke_subagent` with `TypeName: "self"` and the filled prompt |
-| A read-only reviewer template (`spec-reviewer`, `code-quality-reviewer`, `code-reviewer`, `requesting-code-review`'s `./code-reviewer.md`) | `invoke_subagent` with `TypeName: "research"` and the filled review template |
-| Inline prompt (no template referenced) | `invoke_subagent` with `TypeName: "self"` (or `"research"` if the task only reads) and your inline prompt |
-
-### Prompt filling
-
-Skills provide prompt templates with placeholders like `{WHAT_WAS_IMPLEMENTED}` or
-`[FULL TEXT of task]`. Fill all placeholders before passing the complete prompt to
-`invoke_subagent`. The prompt template itself contains the agent's role, review
-criteria, and expected output format — the subagent will follow it.
-
-### Parallel dispatch
-
-Put multiple entries in a single `invoke_subagent` call's `Subagents` array to run
-independent subagent work in parallel. Keep dependent tasks sequential, but do not
-serialize independent subagent tasks just to preserve a simpler history.
-
-## Task tracking
-
-Antigravity has **no todo / `TodoWrite` tool** (`manage_task` manages background
-processes — `list`/`kill`/`status`/`send_input` — it is *not* a checklist). When a
-skill says to create a todo list or track tasks, maintain a **task artifact**: a
-markdown checklist saved with `write_to_file` (`IsArtifact: true`,
-`ArtifactMetadata.ArtifactType: "task"`), edited with `replace_file_content` /
-`multi_replace_file_content` as you go.
-
-At the start of any multi-step task, create the task artifact listing every step of
-your plan. As you complete each step, edit the artifact to mark it done (`- [x]`).
-If the plan changes, update the checklist. Keep it current — it is your source of
-truth for what remains; once the conversation gets long, re-read it before starting
-each step.

skills/writing-plans/SKILL.md

@@ -7,12 +7,10 @@ description: Use when you have a spec or requirements for a multi-step task, bef
 
 ## Overview
 
-Write comprehensive implementation plans assuming the engineer has zero context for our codebase and questionable taste. Document everything they need to execute: which files to touch for each task, code, testing, docs they might need to check, how to test it. Give them the whole plan as bite-sized tasks. DRY. YAGNI. TDD. Frequent commits.
+Write comprehensive implementation plans assuming the engineer has zero context for our codebase and questionable taste. Document everything they need to know: which files to touch for each task, code, testing, docs they might need to check, how to test it. Give them the whole plan as bite-sized tasks. DRY. YAGNI. TDD. Frequent commits.
 
 Assume they are a skilled developer, but know almost nothing about our toolset or problem domain. Assume they don't know good test design very well.
 
-**Plans reference the spec; they never restate it.** The spec owns the WHAT and WHY — requirements, acceptance criteria, design decisions. The plan owns the HOW — tasks, files, code, commands. Cite the spec by path in the header and by section where a task needs context. Re-deriving spec content inline doubles the documents and lets them drift apart. "Zero context" means the engineer can execute each step mechanically; it does not mean the plan repeats what the spec already says — they can read the spec at the cited path.
-
 **Announce at start:** "I'm using the writing-plans skill to create the implementation plan."
 
 **Context:** If working in an isolated worktree, it should have been created via the `superpowers:using-git-worktrees` skill at execution time.
@@ -55,8 +53,6 @@ This structure informs the task decomposition. Each task should produce self-con
 
 **Goal:** [One sentence describing what this builds]
 
-**Spec:** [Path to the spec doc, e.g. `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md` — requirements and design decisions live there; do not restate them here]
-
 **Architecture:** [2-3 sentences about approach]
 
 **Tech Stack:** [Key technologies/libraries]

tests/antigravity/run-tests.sh

@@ -1,16 +0,0 @@
-#!/usr/bin/env bash
-# Run all Antigravity (agy) integration tests.
-set -euo pipefail
-
-SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
-
-echo "=== Antigravity integration tests ==="
-
-for t in "$SCRIPT_DIR"/test-*.sh; do
-  echo
-  echo ">>> $t"
-  bash "$t"
-done
-
-echo
-echo "=== All Antigravity tests passed ==="

tests/antigravity/test-antigravity-tools.sh

@@ -1,53 +0,0 @@
-#!/usr/bin/env bash
-# Validate the Antigravity (agy) integration. agy installs the existing plugin
-# directly (`agy plugin install <repo-url>`): it loads the bundled skills and
-# runs the SessionStart hook for bootstrap, so there is no agy-specific scaffold
-# to test. What IS agy-specific is the tool mapping — agy has no `Skill` tool and
-# loads skills by reading SKILL.md with view_file — and SKILL.md pointing at it.
-#
-# Mirrors tests/pi/test-pi-extension.mjs's "tools reference documents
-# harness-specific mappings" check. CI-safe: does not require `agy` installed.
-set -euo pipefail
-
-SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
-REPO_ROOT="$(cd "$SCRIPT_DIR/../.." && pwd)"
-
-MAPPING="$REPO_ROOT/skills/using-superpowers/references/antigravity-tools.md"
-SKILL="$REPO_ROOT/skills/using-superpowers/SKILL.md"
-
-fail() { echo "FAIL: $*" >&2; exit 1; }
-
-echo "test-antigravity-tools: checking Antigravity tool mapping"
-
-# --- Mapping exists ---------------------------------------------------------
-[ -f "$MAPPING" ] || fail "tool mapping missing at $MAPPING"
-
-# --- Skill-load mechanism: view_file on SKILL.md (IsSkillFile), no Skill tool -
-grep -qiE "view_file" "$MAPPING" \
-  || fail "mapping does not document view_file as the file/skill-read tool"
-grep -qiE "SKILL\.md" "$MAPPING" \
-  || fail "mapping does not document reading SKILL.md as the skill-load path"
-grep -q "IsSkillFile" "$MAPPING" \
-  || fail "mapping does not document setting IsSkillFile when loading a skill"
-
-# --- Core action→tool mappings are documented -------------------------------
-for tool in write_to_file replace_file_content run_command grep_search invoke_subagent; do
-  grep -q "$tool" "$MAPPING" \
-    || fail "mapping does not document the '$tool' tool"
-done
-
-# --- Subagents use the built-in self/research types -------------------------
-grep -q '`self`' "$MAPPING" \
-  || fail "mapping does not document the built-in 'self' subagent type"
-grep -q '`research`' "$MAPPING" \
-  || fail "mapping does not document the built-in 'research' subagent type"
-
-# --- Task tracking documents the 'task' artifact mechanism ------------------
-grep -qE 'ArtifactType.*task|task. artifact' "$MAPPING" \
-  || fail "mapping does not document task tracking as a 'task' artifact"
-
-# --- SKILL.md Platform Adaptation links the mapping -------------------------
-grep -q "antigravity-tools.md" "$SKILL" \
-  || fail "SKILL.md Platform Adaptation does not reference antigravity-tools.md"
-
-echo "PASS: Antigravity tool mapping valid (view_file skill-load, agy tools, SKILL.md link)"

tests/brainstorm-server/ws-protocol.test.js

@@ -329,21 +329,6 @@ function runTests() {
     assert.strictEqual(result.payload.length, 65536);
   });
 
-  test('rejects oversized 64-bit frames before payload allocation', () => {
-    const mask = Buffer.from([0x00, 0x00, 0x00, 0x00]);
-    const header = Buffer.alloc(14);
-    header[0] = 0x81; // FIN + TEXT
-    header[1] = 0x80 | 127; // masked, 64-bit length
-    header.writeBigUInt64BE(BigInt(ws.MAX_FRAME_PAYLOAD_BYTES) + 1n, 2);
-    mask.copy(header, 10);
-
-    assert.throws(
-      () => ws.decodeFrame(header),
-      /exceeds maximum allowed size/i,
-      'oversized advertised payload must be rejected from header alone'
-    );
-  });
-
   // ========== Close Frame with Status Code ==========
   console.log('\n--- Close Frame Details ---');
 

tests/codex-plugin-sync/test-sync-to-codex-plugin.sh

@@ -175,7 +175,6 @@ write_upstream_fixture() {
 
     mkdir -p \
         "$repo/.codex-plugin" \
-        "$repo/.kimi-plugin" \
         "$repo/.private-journal" \
         "$repo/assets" \
         "$repo/evals/drill" \
@@ -211,13 +210,6 @@ EOF
   "name": "superpowers",
   "version": "$MANIFEST_VERSION"
 }
-EOF
-
-    cat > "$repo/.kimi-plugin/plugin.json" <<EOF
-{
-  "name": "superpowers",
-  "version": "$MANIFEST_VERSION"
-}
 EOF
 
     cat > "$repo/assets/superpowers-small.svg" <<'EOF'
@@ -275,7 +267,6 @@ EOF
 
     git -C "$repo" add \
         .codex-plugin/plugin.json \
-        .kimi-plugin/plugin.json \
         .gitignore \
         assets/app-icon.png \
         assets/superpowers-small.svg \
@@ -424,15 +415,10 @@ EOF
 write_stale_ignored_destination_fixture() {
     local repo="$1"
 
-    mkdir -p \
-        "$repo/plugins/superpowers/.kimi-plugin" \
-        "$repo/plugins/superpowers/.private-journal"
+    mkdir -p "$repo/plugins/superpowers/.private-journal"
     printf 'fixture keep\n' > "$repo/plugins/superpowers/.fixture-keep"
-    printf '{"name":"stale-kimi"}\n' > "$repo/plugins/superpowers/.kimi-plugin/plugin.json"
     printf 'stale ignored leak\n' > "$repo/plugins/superpowers/.private-journal/leak.txt"
-    git -C "$repo" add \
-        plugins/superpowers/.fixture-keep \
-        plugins/superpowers/.kimi-plugin/plugin.json
+    git -C "$repo" add plugins/superpowers/.fixture-keep
 
     commit_fixture "$repo" "Initial stale ignored destination fixture"
 }
@@ -632,7 +618,6 @@ main() {
     assert_contains "$preview_output" "Version:  $MANIFEST_VERSION" "Preview uses manifest version"
     assert_not_contains "$preview_output" "Version:  $PACKAGE_VERSION" "Preview does not use package.json version"
     assert_contains "$preview_section" ".codex-plugin/plugin.json" "Preview includes manifest path"
-    assert_not_contains "$preview_section" ".kimi-plugin/plugin.json" "Preview excludes Kimi manifest from Codex sync"
     assert_contains "$preview_section" "assets/superpowers-small.svg" "Preview includes SVG asset"
     assert_contains "$preview_section" "assets/app-icon.png" "Preview includes PNG asset"
     assert_contains "$preview_section" "hooks/hooks-codex.json" "Preview includes Codex hook manifest"
@@ -659,7 +644,6 @@ main() {
     echo ""
     echo "Convergence assertions..."
     assert_equals "$stale_preview_status" "0" "Stale ignored destination preview exits successfully"
-    assert_matches "$stale_preview_section" "\\*deleting +\\.kimi-plugin/plugin\\.json" "Preview deletes stale Kimi manifest from Codex plugin"
     assert_matches "$stale_preview_section" "\\*deleting +\\.private-journal/leak\\.txt" "Preview deletes stale ignored destination file"
 
     echo ""

tests/kimi/run-tests.sh

@@ -1,6 +0,0 @@
-#!/usr/bin/env bash
-set -euo pipefail
-
-SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
-
-bash "$SCRIPT_DIR/test-plugin-manifest.sh"

tests/kimi/test-plugin-manifest.sh

@@ -1,86 +0,0 @@
-#!/usr/bin/env bash
-set -euo pipefail
-
-SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
-REPO_ROOT="$(cd "$SCRIPT_DIR/../.." && pwd)"
-MANIFEST="$REPO_ROOT/.kimi-plugin/plugin.json"
-
-python3 - "$MANIFEST" <<'PY'
-import json
-import sys
-from pathlib import Path
-
-manifest_path = Path(sys.argv[1])
-manifest = json.loads(manifest_path.read_text(encoding="utf-8"))
-
-def assert_equal(actual, expected, label):
-    if actual != expected:
-        raise AssertionError(f"{label}: expected {expected!r}, got {actual!r}")
-
-def assert_present(text, needle, label):
-    if needle not in text:
-        raise AssertionError(f"{label}: missing {needle!r}")
-
-assert_equal(manifest.get("name"), "superpowers", "plugin name")
-assert_equal(manifest.get("skills"), "./skills/", "skills path")
-assert_equal(
-    manifest.get("sessionStart", {}).get("skill"),
-    "using-superpowers",
-    "sessionStart.skill",
-)
-
-instructions = manifest.get("skillInstructions")
-if not isinstance(instructions, str) or not instructions.strip():
-    raise AssertionError("skillInstructions must be a non-empty string")
-
-for token in [
-    "AskUserQuestion",
-    "TodoList",
-    "Agent",
-    "Skill",
-    "Read",
-    "Write",
-    "Edit",
-    "Bash",
-    "Grep",
-    "Glob",
-    "FetchURL",
-    "WebSearch",
-]:
-    assert_present(instructions, token, "skillInstructions")
-
-version_config = json.loads(
-    (manifest_path.parents[1] / ".version-bump.json").read_text(encoding="utf-8")
-)
-version_entries = version_config.get("files")
-if not isinstance(version_entries, list):
-    raise AssertionError(".version-bump.json must contain files list")
-
-if not any(
-    entry.get("path") == ".kimi-plugin/plugin.json" and entry.get("field") == "version"
-    for entry in version_entries
-    if isinstance(entry, dict)
-):
-    raise AssertionError(
-        ".version-bump.json must update .kimi-plugin/plugin.json version"
-    )
-
-unsupported_fields = [
-    "tools",
-    "commands",
-    "hooks",
-    "apps",
-    "inject",
-    "configFile",
-    "config_file",
-    "bootstrap",
-]
-present_unsupported = sorted(field for field in unsupported_fields if field in manifest)
-if present_unsupported:
-    raise AssertionError(
-        "unsupported Kimi runtime fields present: "
-        + ", ".join(present_unsupported)
-    )
-
-print("Kimi plugin manifest looks good")
-PY

tests/shell-lint/test-lint-shell.sh

@@ -1,179 +0,0 @@
-#!/usr/bin/env bash
-set -euo pipefail
-
-SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
-REPO_ROOT="$(cd "$SCRIPT_DIR/../.." && pwd)"
-SCRIPT_UNDER_TEST="$REPO_ROOT/scripts/lint-shell.sh"
-
-FAILURES=0
-TEST_ROOT="$(mktemp -d)"
-
-cleanup() {
-  rm -rf "$TEST_ROOT"
-}
-trap cleanup EXIT
-
-pass() {
-  echo "  [PASS] $1"
-}
-
-fail() {
-  echo "  [FAIL] $1"
-  FAILURES=$((FAILURES + 1))
-}
-
-assert_contains() {
-  local haystack="$1"
-  local needle="$2"
-  local description="$3"
-
-  if printf '%s' "$haystack" | grep -Fq -- "$needle"; then
-    pass "$description"
-  else
-    fail "$description"
-    echo "    expected to find: $needle"
-    echo "    in:"
-    printf '%s\n' "$haystack" | sed 's/^/      /'
-  fi
-}
-
-assert_not_contains() {
-  local haystack="$1"
-  local needle="$2"
-  local description="$3"
-
-  if printf '%s' "$haystack" | grep -Fq -- "$needle"; then
-    fail "$description"
-    echo "    did not expect to find: $needle"
-    echo "    in:"
-    printf '%s\n' "$haystack" | sed 's/^/      /'
-  else
-    pass "$description"
-  fi
-}
-
-configure_git_identity() {
-  local repo="$1"
-
-  git -C "$repo" config user.name "Test Bot"
-  git -C "$repo" config user.email "test@example.com"
-}
-
-write_stub_tool() {
-  local path="$1"
-  local name="$2"
-
-  cat >"$path" <<EOF
-#!/usr/bin/env bash
-{
-  printf '${name}:'
-  for arg in "\$@"; do
-    printf ' <%s>' "\$arg"
-  done
-  printf '\n'
-} >> "\$SUPERPOWERS_SHELL_LINT_TEST_LOG"
-exit 0
-EOF
-  chmod +x "$path"
-}
-
-make_fixture_repo() {
-  local repo="$1"
-
-  git init -q -b main "$repo"
-  configure_git_identity "$repo"
-
-  mkdir -p "$repo/hooks"
-  cat >"$repo/tracked.sh" <<'EOF'
-#!/usr/bin/env bash
-echo "tracked"
-EOF
-  cat >"$repo/hooks/session-start" <<'EOF'
-#!/bin/sh
-echo "extensionless"
-EOF
-  cat >"$repo/README.md" <<'EOF'
-# Fixture
-
-```bash
-echo "not a shell script"
-```
-EOF
-  cat >"$repo/untracked.sh" <<'EOF'
-#!/usr/bin/env bash
-echo "untracked"
-EOF
-
-  git -C "$repo" add tracked.sh hooks/session-start README.md
-  git -C "$repo" commit -q -m "fixture"
-
-  printf '\necho "changed"\n' >>"$repo/tracked.sh"
-  printf '\necho "changed extensionless"\n' >>"$repo/hooks/session-start"
-}
-
-run_lint_shell() {
-  local repo="$1"
-  local fakebin="$2"
-  local log="$3"
-  shift 3
-
-  (
-    cd "$repo"
-    PATH="$fakebin:$PATH" \
-      SUPERPOWERS_SHELL_LINT_TEST_LOG="$log" \
-      bash "$SCRIPT_UNDER_TEST" "$@"
-  )
-}
-
-echo "Shell lint script tests"
-
-fixture="$TEST_ROOT/repo"
-fakebin="$TEST_ROOT/bin"
-log="$TEST_ROOT/tool.log"
-mkdir -p "$fixture" "$fakebin"
-: >"$log"
-write_stub_tool "$fakebin/shellcheck" "shellcheck"
-write_stub_tool "$fakebin/shfmt" "shfmt"
-make_fixture_repo "$fixture"
-
-if output="$(run_lint_shell "$fixture" "$fakebin" "$log" 2>&1)"; then
-  pass "lint-shell check mode exits successfully with stub tools"
-else
-  fail "lint-shell check mode exits successfully with stub tools"
-  printf '%s\n' "$output" | sed 's/^/      /'
-fi
-
-tool_log="$(cat "$log")"
-assert_contains "$output" "Linting 3 shell files" "reports changed shell file count"
-assert_not_contains "$tool_log" "shfmt:" "does not run shfmt in lint mode"
-assert_contains "$tool_log" "shellcheck:" "runs ShellCheck"
-assert_contains "$tool_log" "<--severity=warning>" "uses warning severity as the baseline"
-assert_contains "$tool_log" "<--external-sources>" "allows ShellCheck to follow sourced files"
-assert_contains "$tool_log" "<--source-path=SCRIPTDIR>" "resolves ShellCheck sources relative to each script"
-assert_contains "$tool_log" "<hooks/session-start>" "includes changed extensionless shell shebang file"
-assert_contains "$tool_log" "<tracked.sh>" "includes changed tracked .sh file"
-assert_contains "$tool_log" "<untracked.sh>" "includes untracked shell files by default"
-assert_not_contains "$tool_log" "README.md" "ignores Markdown with shell snippets"
-
-: >"$log"
-if output="$(run_lint_shell "$fixture" "$fakebin" "$log" --all --format 2>&1)"; then
-  pass "lint-shell --format exits successfully with stub tools"
-else
-  fail "lint-shell --format exits successfully with stub tools"
-  printf '%s\n' "$output" | sed 's/^/      /'
-fi
-
-tool_log="$(cat "$log")"
-assert_contains "$tool_log" "<-w>" "uses shfmt write mode with --format"
-assert_contains "$tool_log" "shellcheck:" "runs ShellCheck after --format"
-assert_contains "$tool_log" "<--severity=warning>" "keeps warning severity after --format"
-assert_contains "$tool_log" "<hooks/session-start>" "--all includes tracked extensionless shell shebang file"
-assert_contains "$tool_log" "<tracked.sh>" "--all includes tracked .sh file"
-assert_not_contains "$tool_log" "untracked.sh" "--all ignores untracked shell files"
-
-if [[ "$FAILURES" -eq 0 ]]; then
-  echo "All shell lint script tests passed"
-else
-  echo "$FAILURES shell lint script test(s) failed"
-  exit 1
-fi