@zfdx123/dsh-superpowers 1.0.8 → 1.0.9

package/README.en.md

@@ -1,6 +1,6 @@
 # @zfdx123/dsh-superpowers
 
-Brings the [obra/superpowers](https://github.com/obra/superpowers) software-development methodology to [DeepSeek Harness](https://github.com/deepseek-ai/deepseek-harness): it registers 14 skills on `ctx.skills` (brainstorming, planning, TDD, systematic debugging, code review, and more) and injects the `using-superpowers` bootstrap as a system-prompt section, so it is present from the first request and survives context compaction. The skills are registered at runtime and never written to disk, so nothing is copied into `~/.dsh/skills` and no preset or profile skill directory has to change. This is version 1.0.0, targeting DSH `^0.1.6-alpha.1`.
+Brings the [obra/superpowers](https://github.com/obra/superpowers) software-development methodology to [DeepSeek Harness](https://github.com/deepseek-ai/deepseek-harness): it registers 15 skills on `ctx.skills` (brainstorming, planning, TDD, systematic debugging, code review, session diagnosis, and more) and injects the `using-superpowers` bootstrap as a system-prompt section, so it is present from the first request and survives context compaction. The skills are registered at runtime and never written to disk, so nothing is copied into `~/.dsh/skills` and no preset or profile skill directory has to change. This is version 1.0.9, targeting DSH `^0.1.7-rc.2`.
 
 ## Installation
 
@@ -32,7 +32,7 @@ If the bootstrap never arrives, check the session's preset — a preset whose pe
 
 ## What it does
 
-- Registers all 14 skills on `ctx.skills`. They appear in the skill catalog and load on demand through the native `skill` tool; nothing is ever written to `~/.dsh/skills`.
+- Registers all 15 skills on `ctx.skills`. They appear in the skill catalog and load on demand through the native `skill` tool; nothing is ever written to `~/.dsh/skills`.
 - Registers `using-superpowers` as the `superpowers:bootstrap` prompt section at order 50: after the persona prefix (0), before the plan policy (500) and the tool guidance (1000+). It is present on the first request and survives context compaction because it is part of the system prompt, not a one-off session message.
 - On the first agent of a workspace, warns once when a project or preset skill shadows one of the bundled names, naming the copy the model will actually load (provider, source and path). It reports once because every subagent of a session shares the same composition and would only repeat the warning.
 - Maps Claude Code-style tool names onto the DSH tool vocabulary: `Task` → `subagent`, `TodoWrite` → `todo_write`, `Bash`/`Read`/`Write`/`Edit`/`Glob`/`Grep` → their lowercase equivalents, and so on. The mapping also notes that this environment exposes no hook or slash-command API, so an instruction to install a hook or register a command should be carried out with those tools instead.
@@ -59,9 +59,9 @@ Every field is validated against the plugin's own schema (`@deepseek-ai/schemast
 
 ## Requirements
 
-- DeepSeek Harness `^0.1.6-alpha.1` (`engines.dsh`)
+- DeepSeek Harness `^0.1.7-rc.2` (`engines.dsh`)
 - Node `^22.19.0 || >=24.0.0`
-- The peer `@deepseek-ai/cordis ^4.0.2`, plus the optional peers `@deepseek-ai/dsh-skill` and `@deepseek-ai/dsh-system-prompt` (both `^0.1.6-alpha.1`)
+- The peer `@deepseek-ai/cordis ^4.0.4`, plus the optional peers `@deepseek-ai/dsh-skill` and `@deepseek-ai/dsh-system-prompt` (both `^0.1.7-rc.2`)
 - One runtime dependency, `@deepseek-ai/schemastery` (the config schema): a registry install pulls it in, while a `link:` install needs `npm install` in the checkout first or the plugin fails to load
 
 ## Limitations
@@ -70,7 +70,7 @@ Every field is validated against the plugin's own schema (`@deepseek-ai/schemast
 
 Under such a preset:
 
-- The bootstrap is not delivered, so the skills never self-trigger. The 14 skills are still registered on `ctx.skills`, but whether the model can reach them is the preset's decision, because the preset also decides which tools exist — `minimal` exposes only the persistent shell, so no `skill` tool is available there either.
+- The bootstrap is not delivered, so the skills never self-trigger. The 15 skills are still registered on `ctx.skills`, but whether the model can reach them is the preset's decision, because the preset also decides which tools exist — `minimal` exposes only the persistent shell, so no `skill` tool is available there either.
 - `bootstrap: true` cannot make the section appear, and `bootstrap: false` reports nothing: the section was never going to be delivered.
 
 Use a preset whose persona is not complete to get the bootstrap. The limitation is pinned by an executable probe: `verify/src-02-complete-persona-shadow.mjs` mounts the real `SystemPrompt`, `SkillRegistry` and scope machinery, applies this plugin exactly as the loader does, and asserts that a scope with a complete persona delivers that section alone and that no `system-prompt/assemble` listener can put the text back; if the mechanism ever changes, the probe fails and says the documentation is stale.
@@ -88,6 +88,6 @@ node verify/src-02-complete-persona-shadow.mjs   # the complete-persona mechanis
 
 ## License
 
-The skills under `skills/` are vendored unmodified from [obra/superpowers](https://github.com/obra/superpowers) v6.3.0 at commit [`b36e082`](https://github.com/obra/superpowers/commit/b36e0829c6d0140e93cfef2ca599b1b07d4a7797). The exact upstream version, commit and repository are recorded in `package.json`'s `superpowers` field. The optional visual companion in `brainstorming` loads an upstream-hosted logo containing the Superpowers version; it sends no project or prompt content. Set `SUPERPOWERS_DISABLE_TELEMETRY` to a true value to disable it.
+The skills under `skills/` are taken from [obra/superpowers](https://github.com/obra/superpowers) v6.4.2 at commit [`8ca22db`](https://github.com/obra/superpowers/commit/8ca22dba9a94f28898bbce59f2537ff4d87c747d); the exact upstream version, commit and repository are recorded in `package.json`'s `superpowers` field. **The one deviation from upstream is formatting**: `brainstorming/scripts/helper.js`, `brainstorming/scripts/server.cjs`, `systematic-debugging/condition-based-waiting-example.ts` and `writing-skills/render-graphs.js` were reflowed by this repository's prettier (no semantic change, and upstream did not touch them in 6.4.x); every other file is byte-for-byte upstream. The optional visual companion in `brainstorming` loads an upstream-hosted logo containing the Superpowers version; it sends no project or prompt content. Set `SUPERPOWERS_DISABLE_TELEMETRY` to a true value to disable it.
 
 Two MIT license notices apply: the adapter is © its contributors under [LICENSE](LICENSE), while the bundled skills are © Jesse Vincent and the Superpowers contributors under [LICENSE.superpowers](LICENSE.superpowers). The Chinese `README.md` is this package's primary document; this file is its English mirror.

package/README.md

@@ -1,6 +1,6 @@
 # @zfdx123/dsh-superpowers
 
-把 [obra/superpowers](https://github.com/obra/superpowers) 的软件开发方法论接进 [DeepSeek Harness](https://github.com/deepseek-ai/deepseek-harness)：在 `ctx.skills` 上注册 14 个技能（需求澄清、任务规划、TDD、系统化调试、代码审查等），并把 `using-superpowers` 引导语作为系统提示词段落注入，让它从第一条请求起就生效、在上下文压缩后依然存在。技能是**运行时注册**的、不落盘，所以既不往 `~/.dsh/skills` 复制任何文件，也不要求改动预设或 profile 里的技能目录。当前版本 1.0.0，面向 DSH `^0.1.6-alpha.1`。
+把 [obra/superpowers](https://github.com/obra/superpowers) 的软件开发方法论接进 [DeepSeek Harness](https://github.com/deepseek-ai/deepseek-harness)：在 `ctx.skills` 上注册 15 个技能（需求澄清、任务规划、TDD、系统化调试、代码审查、会话诊断等），并把 `using-superpowers` 引导语作为系统提示词段落注入，让它从第一条请求起就生效、在上下文压缩后依然存在。技能是**运行时注册**的、不落盘，所以既不往 `~/.dsh/skills` 复制任何文件，也不要求改动预设或 profile 里的技能目录。当前版本 1.0.9，面向 DSH `^0.1.7-rc.2`。
 
 ## 安装
 
@@ -32,7 +32,7 @@ dsh --profile web --dump-config
 
 ## 它做什么
 
-- 在 `ctx.skills` 注册全部 14 个技能。它们出现在技能目录里，并通过原生 `skill` 工具按需加载；`~/.dsh/skills` 不会被写入任何东西。
+- 在 `ctx.skills` 注册全部 15 个技能。它们出现在技能目录里，并通过原生 `skill` 工具按需加载；`~/.dsh/skills` 不会被写入任何东西。
 - 把 `using-superpowers` 注册为 `superpowers:bootstrap` 提示词段落，order 50：位于 persona 前缀（0）之后、计划策略（500）与工具指导（1000+）之前。它在第一条请求就存在，并能在上下文压缩后继续存在——因为它属于系统提示词，而不是一次性会话消息。
 - 每个工作区的首个 agent 创建时，若某个内置技能名被项目技能或预设技能遮蔽，会告警一次，并指明模型实际会加载的那份副本（provider、来源与路径）。只报一次，因为同一会话的子 agent 共享同一套组合，重复告警没有信息量。
 - 把 Claude Code 风格的工具名映射到 DSH 的工具词汇：`Task` → `subagent`、`TodoWrite` → `todo_write`、`Bash`/`Read`/`Write`/`Edit`/`Glob`/`Grep` → 对应的小写工具等。映射里同时说明当前环境不提供 hooks 与斜杠命令 API，所以遇到「安装 hook / 注册斜杠命令」的指令时，应改用这些工具把活干完。
@@ -59,9 +59,9 @@ dsh --profile web --dump-config
 
 ## 前置要求
 
-- DeepSeek Harness `^0.1.6-alpha.1`（`engines.dsh`）
+- DeepSeek Harness `^0.1.7-rc.2`（`engines.dsh`）
 - Node `^22.19.0 || >=24.0.0`
-- peer `@deepseek-ai/cordis ^4.0.2`，以及可选的 peer `@deepseek-ai/dsh-skill`、`@deepseek-ai/dsh-system-prompt`（均为 `^0.1.6-alpha.1`）
+- peer `@deepseek-ai/cordis ^4.0.4`，以及可选的 peer `@deepseek-ai/dsh-skill`、`@deepseek-ai/dsh-system-prompt`（均为 `^0.1.7-rc.2`）
 - 一个运行时依赖 `@deepseek-ai/schemastery`（提供配置 schema）：从 registry 安装会自动带上；用 `link:` 安装需要先在检出目录执行 `npm install`，否则插件加载失败
 
 ## 已知限制
@@ -70,7 +70,7 @@ dsh --profile web --dump-config
 
 在该类预设下：
 
-- bootstrap 不会下发，技能因此不会自动触发。14 个技能仍注册在 `ctx.skills` 上，但模型能否取到它们由预设决定——预设同时决定有哪些工具：`minimal` 只挂常驻 shell，所以那里也没有 `skill` 工具。
+- bootstrap 不会下发，技能因此不会自动触发。15 个技能仍注册在 `ctx.skills` 上，但模型能否取到它们由预设决定——预设同时决定有哪些工具：`minimal` 只挂常驻 shell，所以那里也没有 `skill` 工具。
 - `bootstrap: true` 不会让它出现，`bootstrap: false` 也不会有任何提示：这个段落本来就不会下发。
 
 要拿到 bootstrap，请使用 persona 不是 complete 的预设。这条限制由可执行探针钉住：`verify/src-02-complete-persona-shadow.mjs` 会挂载真实的 `SystemPrompt`、`SkillRegistry` 与 scope 机制、按加载器的方式应用本插件，并断言「带 complete persona 的 scope 只交付它自己，且任何 `system-prompt/assemble` 监听器都补不回来」；机制一旦变化，探针会失败并提示文档已经过期。
@@ -88,6 +88,6 @@ node verify/src-02-complete-persona-shadow.mjs   # 上面那条 complete persona
 
 ## 许可
 
-`skills/` 下的技能原样取自 [obra/superpowers](https://github.com/obra/superpowers) v6.3.0，对应 commit [`b36e082`](https://github.com/obra/superpowers/commit/b36e0829c6d0140e93cfef2ca599b1b07d4a7797)，未做修改；`package.json` 的 `superpowers` 字段记录了确切的上游版本、commit 与仓库地址。`brainstorming` 的可选视觉组件会从上游网站加载带 Superpowers 版本号的 logo，不包含项目或提示词内容；把 `SUPERPOWERS_DISABLE_TELEMETRY` 设为任一 true 值即可关闭。
+`skills/` 下的技能取自 [obra/superpowers](https://github.com/obra/superpowers) v6.4.2，对应 commit [`8ca22db`](https://github.com/obra/superpowers/commit/8ca22dba9a94f28898bbce59f2537ff4d87c747d)；`package.json` 的 `superpowers` 字段记录了确切的上游版本、commit 与仓库地址。**唯一偏离上游的是格式**：`brainstorming/scripts/helper.js`、`brainstorming/scripts/server.cjs`、`systematic-debugging/condition-based-waiting-example.ts`、`writing-skills/render-graphs.js` 这 4 个文件被本仓库的 prettier 重排过（语义未变，上游在 6.4.x 也没动它们），其余文件逐字节同上游。`brainstorming` 的可选视觉组件会从上游网站加载带 Superpowers 版本号的 logo，不包含项目或提示词内容；把 `SUPERPOWERS_DISABLE_TELEMETRY` 设为任一 true 值即可关闭。
 
 这里同时适用两份 MIT 许可声明：适配器版权归其贡献者所有，依据 [LICENSE](LICENSE) 许可；内置技能版权归 Jesse Vincent 与 Superpowers 贡献者所有，依据 [LICENSE.superpowers](LICENSE.superpowers) 许可。中文文档 `README.md` 是本包的主文档，英文版见 [README.en.md](README.en.md)。

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@zfdx123/dsh-superpowers",
-  "version": "1.0.8",
+  "version": "1.0.9",
   "description": "Superpowers（移植自 obra/superpowers）：把整套软件开发方法论技能与会话引导语作为 dsh 插件提供，技能在运行时注册，首轮对话自动注入引导。",
   "license": "MIT",
   "author": "zfdx123",
@@ -61,8 +61,8 @@
     }
   },
   "superpowers": {
-    "upstreamVersion": "6.3.0",
-    "upstreamCommit": "b36e0829c6d0140e93cfef2ca599b1b07d4a7797",
+    "upstreamVersion": "6.4.2",
+    "upstreamCommit": "8ca22dba9a94f28898bbce59f2537ff4d87c747d",
     "upstreamRepository": "https://github.com/obra/superpowers"
   }
 }

package/skills/brainstorming/SKILL.md

@@ -11,12 +11,48 @@ Start by classifying how much process the request needs, then work
 through your path: understand the context, refine the idea, present a
 design, and get your human partner's approval.
 
+## Establish Shared Understanding
+
+The outcome of brainstorming is an understanding your human partner can
+recognize and correct, grounded in what they want to accomplish.
+
+1. **Discover intent.** Use the request and available context to identify
+   the intended outcome, who it is for, and what success looks like. When
+   that information is missing, ask one focused question about purpose or
+   intended use before proposing features or an approach. Knowing the app
+   genre does not tell you why your partner wants it. Gathering missing
+   requirements does not ask them to authorize the task again.
+2. **Write back your understanding.** Summarize the intended outcome,
+   relevant constraints, and success criteria in a short note your partner
+   can assess. Separate what they said from assumptions. Invite correction
+   and incorporate their answer before treating this as the design brief.
+3. **Carry intent into the design.** Preserve the agreed understanding in
+   the selected path's design artifact: the written spec for architectural
+   work, or the in-chat design/probe for bounded work and spikes. Check
+   proposed features and technical choices against that understanding.
+
+When the request already supplies the purpose and constraints, reflect
+that understanding instead of asking the same questions again. Keep the
+note concise; its accuracy and the opportunity to correct it matter.
+
 <HARD-GATE>
-Do NOT invoke any implementation skill, write any code, scaffold any
-project, or take any implementation action until you have told your
-human partner what you intend and they have approved it. This applies
-to EVERY task on EVERY path below — the ceremony scales with the task;
-the approval gate never does.
+Before taking any implementation action, including invoking an
+implementation skill, writing product code, scaffolding, installing
+product dependencies, or creating an external project, complete the
+selected path's prerequisites:
+
+- Spike: the human partner approves the question and probe.
+- Bounded: the human partner approves the short in-chat design.
+- Architectural: the human partner reviews and approves the written spec,
+  then reviews the written implementation plan and selects its execution
+  method. Conversational design approval only permits writing the spec;
+  written-spec approval only permits invoking writing-plans.
+
+A reply approves the stage actually presented. Approval of an idea or
+feature scope does not approve artifacts that do not exist yet. Resume
+at the earliest incomplete stage; do not turn one approval into permission
+to skip the rest of the selected path. Read-only project exploration is
+allowed while those prerequisites remain incomplete.
 </HARD-GATE>
 
 ## Three Paths
@@ -53,18 +89,17 @@ stop, say so, and step up. Nothing downgrades mid-task.
 
 ## Anti-Pattern: "Too Simple To Need Approval"
 
-Every path ends with your human partner approving your intent before
-implementation. A todo list, a single-function utility, a config
-change — the design may be two sentences in chat, but you MUST present
-it and get approval. "Simple" tasks are where unexamined assumptions
-cause the most wasted work. What scales with simplicity is the
-artifact, never the approval.
+Every path ends with your human partner approving the required design
+before implementation. A bounded change may need only two sentences in
+chat. A new todo-list project is architectural and requires the written
+spec and planning handoffs. Scale the artifact to the selected path;
+complete that path's reviews before implementation.
 
 ## Red Flags
 
 | Thought | Reality |
 |---------|---------|
-| "This is too simple to need a design" | Simple means a short design, not no design. Two sentences in chat, then approval. |
+| "This is too simple to need a design" | Follow the selected path: a bounded change gets a short chat design; an architectural change gets the written spec and planning handoffs. |
 | "I'll call it bounded and skip the spec" | Reaching for a label to skip work IS the doubt — take the heavier path. |
 | "It's bounded and the design is obvious — I'll start while they read it" | The gate is the approval, not the design's length. Present, then stop until you hear yes. |
 | "I understand this kind of app, so it's bounded" | Bounded measures the repo, not your familiarity. A new project has no existing flow — it is architectural. |

package/skills/brainstorming/visual-companion.md

@@ -35,7 +35,7 @@ The server watches a directory for HTML files and serves the newest one to the b
 ```bash
 # Start AFTER the user approves the companion. --open auto-opens their browser on
 # the first screen; --project-dir persists mockups and enables same-port restart.
-scripts/start-server.sh --project-dir /path/to/project --open
+bash scripts/start-server.sh --project-dir /path/to/project --open
 
 # Returns: {"type":"server-started","port":52341,
 #           "url":"http://localhost:52341/?key=ab12…",
@@ -62,7 +62,7 @@ without repeating it.
 **Claude Code:**
 ```bash
 # Default mode works — the script backgrounds the server itself.
-scripts/start-server.sh --project-dir /path/to/project --open
+bash scripts/start-server.sh --project-dir /path/to/project --open
 ```
 
 On Windows, the script auto-detects and switches to foreground mode (which blocks the tool call). Use `run_in_background: true` on the Bash tool call so the server survives across conversation turns, then read `$STATE_DIR/server-info` on the next turn to get the URL and port.
@@ -71,14 +71,14 @@ On Windows, the script auto-detects and switches to foreground mode (which block
 ```bash
 # Codex reaps background processes. The script auto-detects CODEX_CI and
 # switches to foreground mode. Run it normally — no extra flags needed.
-scripts/start-server.sh --project-dir /path/to/project --open
+bash scripts/start-server.sh --project-dir /path/to/project --open
 ```
 
 **Gemini CLI:**
 ```bash
 # Use --foreground and set is_background: true on your shell tool call
 # so the process survives across turns
-scripts/start-server.sh --project-dir /path/to/project --open --foreground
+bash scripts/start-server.sh --project-dir /path/to/project --open --foreground
 ```
 
 **Copilot CLI:**
@@ -95,7 +95,7 @@ bash scripts/start-server.sh --project-dir /path/to/project --open --foreground
 If the URL is unreachable from your browser (common in remote/containerized setups), bind a non-loopback host:
 
 ```bash
-scripts/start-server.sh \
+bash scripts/start-server.sh \
   --project-dir /path/to/project \
   --host 0.0.0.0 \
   --url-host localhost
@@ -288,7 +288,7 @@ If `$STATE_DIR/events` doesn't exist, the user didn't interact with the browser
 ## Cleaning Up
 
 ```bash
-scripts/stop-server.sh $SESSION_DIR
+bash scripts/stop-server.sh $SESSION_DIR
 ```
 
 If the session used `--project-dir`, mockup files persist in `.superpowers/brainstorm/` for later reference. Only `/tmp` sessions get deleted on stop.

package/skills/diagnosing-superpowers/SKILL.md

@@ -0,0 +1,120 @@
+---
+name: diagnosing-superpowers
+description: Use when a superpowers session went wrong and your human partner wants to know why — repeated work, ignored plans, stumbles, poor results, a skill that didn't fire, "it took too long", "why is it so expensive", "what is it doing" — or wants to build a bug report for the superpowers maintainers, for the current session or a past one identified by id or path, on any harness.
+---
+
+# Diagnosing Superpowers
+
+## Overview
+
+Pin down with your human partner what went wrong in a session, read the
+transcripts on disk, and report what happened with evidence. You report;
+you do not diagnose superpowers. Whoever triages the bundle or the issue
+decides whether superpowers changes.
+
+**Core principle:** Every finding cites `path:line`. No citation, no
+finding. Every number comes from the transcript or from a command you ran,
+never from memory.
+
+## Workflow
+
+Create a todo per step. Steps 5–7 run only on their stated condition.
+
+1. **Problem intake.** Ask one question at a time until you can write a
+   statement naming the session(s), the turn range if known, what your
+   partner expected, what happened, and the observable they care about
+   (wall-clock, tokens, repeated actions, one specific action). "It took
+   too long" is a complaint, not a problem statement. Note whether the
+   goal is a superpowers bug report.
+2. **Locate.** Resolve each session to verified absolute filesystem paths using
+   `references/session-discovery.md`. Confirm a past session by quoting its
+   first prompt and timestamp, and list every candidate you rejected with the
+   reason, or "none". Enumerate subagent transcripts. Create
+   `~/.superpowers/diagnosing-superpowers/<session-id>/`, tell your
+   partner the path, and fill `templates/case.md` there, following its
+   provenance rules for environment and skill observations.
+3. **Triage.** Read the region around the reported problem yourself. Then
+   dispatch one analyst subagent per dimension in parallel, each given the
+   case file path, `prompts/analyst-common.md`, and one dimension file from
+   `prompts/`: `skill-timeline.md`,
+   `plan-adherence.md`, `repeated-work.md`, `stumbles.md`,
+   `quality-evidence.md`, `request-conflicts.md`, `cost-and-time.md`.
+   Split a dimension by turn range when the transcript is long. Discard
+   any returned finding without `path:line`.
+4. **Report.** Fill every section of `templates/report.md` in order, write
+   it to the workspace, show it, and give the path. Check what cited content
+   actually proves and preserve the supporting case; a symlink alias is not a
+   redundant copy.
+5. **GitHub issues** — when report §7 says possible or likely, or your
+   partner asks. Search open and closed issues for the symptoms per
+   `references/github-issues.md`. Show matches and suggest adding the
+   report to the closest. If none match, fill `templates/issue.md`, write
+   it to the workspace, show the exact text, and create the issue only
+   after approval. `gh` cannot attach files; if a bundle exists, give
+   your partner its path to attach in the browser.
+6. **Export** — only when your partner asks for a bundle; never build one
+   unprompted. If the intake goal was a bug report, say once that a
+   scrubbed bundle is available on request, then wait. Ask the redaction
+   level, stating what each includes: skeleton (no tool-result bodies),
+   evidence (bodies only for cited events), full. Build the bundle per
+   `templates/bundle-README.md`, dispatch `prompts/scrub.md`, then
+   `prompts/scrub-audit.md`, repeating both until the audit returns CLEAN.
+   Complete the bundle template's evidence check and reconciliation before
+   showing the final scrub log, file list, and privacy and evidence outcomes.
+   Archive (`zip -r` or `tar -czf`) only after approval. With the archive
+   path, state what it contains, point at the scrub log for replacements, and
+   say scrubbing can miss things: they must review every file before sharing.
+7. **Similar sessions** — when asked. Turn confirmed findings into a
+   signature, list candidates by mtime and size, find marker line numbers,
+   dispatch `prompts/similar-session.md` per candidate in parallel, and
+   append report §9.
+
+## Quick reference
+
+All seven analysts always run. This table says which region to read
+yourself in step 3 and which findings to lead with in the verdict.
+
+| Complaint | Read first, lead with |
+|---|---|
+| "It took too long" | cost-and-time, stumbles |
+| "Why did it do this extra work?" | repeated-work, plan-adherence |
+| "Why is it so expensive?" | cost-and-time |
+| "What the hell is it doing?" (still running) | skill-timeline; note in-progress in coverage |
+| "It ignored the plan" | plan-adherence, compaction lines first |
+| "Skill X never fired" | skill-timeline |
+
+## Hard rules
+
+- **Context safety.** One transcript line can be a megabyte. Follow
+  `references/context-safety.md` on every session file, every time.
+- **Read-only.** Never modify, move, or delete a session file.
+- **Exact paths to subagents.** A subagent's "current session" is its
+  own. Pass absolute paths and ids.
+- **Human prompts only.** Hook output, system reminders, and tool results
+  are not your partner's words. In a subagent transcript, "user" is the
+  parent agent.
+- **No superpowers diagnosis.** Report §7 states involvement and stops.
+  Never name a defect in a skill or propose a change. Your partner
+  pressing for a fix does not waive this; point at the issue step and
+  mention that a bundle is available on request. No advice to your
+  partner either.
+- **Approval gates.** No archive before your partner has seen the scrub
+  log and file list. No issue or comment before they approve the exact
+  text.
+- **Intake before analysis.** Nothing in steps 2–7 starts until your
+  partner has answered. If they are away, write the questions and stop.
+  A statement you reconstructed for them is not an answer. An
+  already-scoped request — one specific event, what is running now, or
+  the analysis to run — is itself the statement: answer it, then ask.
+  A whole-session "why" is a complaint.
+
+## Red Flags
+
+| Thought | Reality |
+|---------|---------|
+| "The problem is obvious, skip intake" | The problem statement scopes everything. Ask. |
+| "They're away, so I'll reconstruct the statement" | You cannot reconstruct what they wanted. Write the questions and stop. |
+| "I'll sweep everything now and ask at the end" | An unscoped sweep spends their budget on the wrong question. Ask first. |
+| "They want a bug report, so I'll build the bundle now" | The bundle is their session data, packaged. Build it only when they ask for it. |
+| "Small, targeted edit, no restructuring needed" | Not your call, however small. Report the evidence; the triager decides. |
+| "The price per token is well known" | Numbers you did not compute from the transcript are invented. Cite or drop. |

package/skills/diagnosing-superpowers/prompts/analyst-common.md

@@ -0,0 +1,38 @@
+You are an analyst subagent. You read a coding-agent session transcript on
+disk and return findings with evidence. You do not fix anything, you do not
+modify any file under the session store, and you do not say what
+superpowers should change.
+
+Inputs (from your dispatcher):
+- CASE: absolute path of the case file. Read it first. It names the session
+  files, the discovered sources and record meanings to use, and the
+  context-safety rules you must follow. Use the recorded meanings rather than
+  repeating discovery or assuming a harness format.
+- RANGE (optional): a turn range or line range. If present, analyze only
+  that range and say so in your Checked line.
+
+Context safety: follow `references/context-safety.md`, named in CASE, on
+every file before reading it, and extract fields with the recorded commands or
+queries. "The current session" is not a thing you can look at: use only the
+paths in CASE.
+
+Human prompts are the records the case file identifies as human-typed. Hook
+output, system reminders, and tool results are not human prompts. In a subagent
+transcript, "user" is the parent agent.
+
+Return format (nothing else):
+
+```
+## <Dimension> findings
+
+- finding: <one sentence, what happened>
+  evidence: <absolute path>:<line> — "<quote, at most 200 characters>"
+  turns: <first human turn>–<last human turn>
+  confidence: high | medium | low
+
+Checked: <what you examined: files, line ranges, commands used>
+```
+
+The dispatcher discards any finding without a `path:line`, so do not
+write one. If you found nothing, return `- none found` and the Checked
+line.

package/skills/diagnosing-superpowers/prompts/cost-and-time.md

@@ -0,0 +1,28 @@
+Read `prompts/analyst-common.md` first; it gives your role, inputs,
+context-safety rules, and the return format. This file adds the dimension.
+
+Dimension: Cost and time
+
+Account for where tokens and wall-clock went.
+
+1. Tokens. Use only the usage records and counter meanings established in the
+   case file. State whether each counter is incremental or cumulative before
+   calculating totals; difference cumulative observations without turning a
+   missing observation into zero. Report the five turns with the largest
+   supported totals and the supported totals per associated session.
+2. Wall-clock. Use the evidenced timestamp fields, event boundaries, and units
+   recorded in the case file. Report the five longest supported turns and any
+   gap longer than ten minutes between consecutive events (idle, waiting on an
+   associated session, or waiting on your human partner; say which only when
+   the records show it).
+3. Largest tool results: use the case file's evidenced tool-result records to
+   report the ten largest results with their tool and turn. Measure records
+   before extracting bounded content.
+4. Compactions: count and locate records whose meaning as compaction events was
+   established during discovery. Report available before/after counters and
+   what the session was doing when each fired; mark unsupported fields absent.
+5. Associated sessions: count them and report supported usage, duration, and
+   dispatching turn for each.
+6. Report the turns, subagents, tools, or repeats that dominate the
+   totals, with numbers. Do not speculate about why a
+   turn was expensive beyond what the transcript shows.

package/skills/diagnosing-superpowers/prompts/plan-adherence.md

@@ -0,0 +1,29 @@
+Read `prompts/analyst-common.md` first; it gives your role, inputs,
+context-safety rules, and the return format. This file adds the dimension.
+
+Dimension: Plan adherence
+
+Recover the plan the session agreed to, then map each plan step to what
+happened. "Plan" here means any agreed course of action, not git commits.
+
+1. Find the agreed plan: a design or plan agreed in chat (look for the
+   assistant text preceding a human "yes/ok/go ahead"), a spec or plan file
+   written during the session (tool calls that write under `docs/`,
+   `plans/`, `specs/`, or any file the human named), a todo-list record whose
+   meaning was established in the case file, or any numbered checklist in
+   assistant text. Quote each plan step with its `path:line`.
+2. Mark structural events between the plan and its execution: compaction
+   events identified during discovery, resumes, aborted turns, and associated
+   session dispatches. Note their line numbers; plan drift right after one of
+   these is a distinct finding.
+3. For each plan step, find the tool calls and assistant text that
+   executed it, or establish that none did. Report:
+   - steps skipped (no execution found; quote the plan step);
+   - steps executed out of order (line numbers show the order);
+   - steps silently changed (execution differs from the plan step in a
+     way the assistant never announced; quote both);
+   - steps invented (work done that no plan step covers);
+   - drift immediately after a structural event (cite the event line and
+     the first divergent action).
+4. If there is no recoverable plan, say so as the only finding, with
+   the lines you checked.

package/skills/diagnosing-superpowers/prompts/quality-evidence.md

@@ -0,0 +1,26 @@
+Read `prompts/analyst-common.md` first; it gives your role, inputs,
+context-safety rules, and the return format. This file adds the dimension.
+
+Dimension: Quality evidence
+
+Judge the process against its own claims. This is not a code review; do
+not evaluate the code the session produced.
+
+1. Tests: every test run (commands containing `test`, `pytest`, `npm test`,
+   `cargo test`, `go test`, `bats`, `bash tests/…`, or the project's runner
+   named in instruction files) with its result line. Report runs that
+   failed and what the assistant did next.
+2. Verification behind claims: find assistant text claiming done, fixed,
+   passing, verified, works, complete. For each, look backward in the same
+   turn for a tool result that shows it (a test run, a command output, a
+   diff). Report claims with no supporting result in that turn.
+3. Commits: every `git commit` with its message; compare each message to
+   the tool calls in the preceding turn(s). Report commits whose message
+   claims work that no tool call performed, and work performed that was
+   never committed when the agreed plan said it would be.
+4. Review feedback: where a reviewer (human or subagent) raised points,
+   find the response. Report points acknowledged but not acted on, and
+   points dismissed without a stated reason.
+5. Acceptance criteria: if the case file's problem statement or the
+   agreed plan states criteria, report each as met / not met /
+   not checked with the evidence line.

package/skills/diagnosing-superpowers/prompts/repeated-work.md

@@ -0,0 +1,30 @@
+Read `prompts/analyst-common.md` first; it gives your role, inputs,
+context-safety rules, and the return format. This file adds the dimension.
+
+Dimension: Repeated work
+
+Find work the session did more than once.
+
+1. Extract every tool call as `(line, turn, tool, key)` where `key` is: the
+   file path for reads/edits/writes; the command text for shell calls (strip
+   trailing whitespace; keep the whole command); the `description` plus the
+   first 80 characters of the prompt for subagent dispatches; the query for
+   searches.
+2. Group by `(tool, key)` and report the groups at or over threshold:
+
+   | Category | Threshold | Exempt |
+   |---|---|---|
+   | reads, searches | 3 | |
+   | edits | 2 | |
+   | shell commands | 2 | status checks and test runs (`git status`, `ls`, `pwd`, test runners) |
+   | subagent dispatches | 2 with the same description | |
+3. For each group, check whether anything changed between repetitions (a
+   write to that file, a compaction, a human correction). Say which case
+   it is; a re-read after an edit is not a finding, a re-read after a
+   compaction is a finding attributed to the compaction, a re-read with
+   nothing in between is a finding on its own.
+4. Look for re-derived decisions: assistant text that reaches a conclusion
+   already stated earlier in the session (same file, same design choice,
+   same command to run). Quote both places.
+5. One finding per group, with the first and last line numbers and the
+   count.

package/skills/diagnosing-superpowers/prompts/request-conflicts.md

@@ -0,0 +1,20 @@
+Read `prompts/analyst-common.md` first; it gives your role, inputs,
+context-safety rules, and the return format. This file adds the dimension.
+
+Dimension: Request conflicts
+
+1. List every human prompt with line and turn. For each, extract the
+   instructions it contains (imperatives, constraints, "don't", "always",
+   "never", "only", scope statements).
+2. Report:
+   - two human instructions that cannot both be followed (quote both, with
+     lines), and what the assistant did;
+   - a human instruction that conflicts with an instruction file loaded in
+     the session (CLAUDE.md, AGENTS.md, GEMINI.md, or the harness's
+     equivalent; paths are in the case file), quoting both;
+   - a human instruction to skip, ignore, or override a step, skill, or
+     rule, and what happened afterwards;
+   - an instruction the assistant asked to clarify and the answer, when the
+     answer changed scope.
+3. Do not judge whether your human partner was right. Report the conflict
+   and the assistant's resolution.

package/skills/diagnosing-superpowers/prompts/scrub-audit.md

@@ -0,0 +1,33 @@
+Read and follow `references/redaction-policy.md` before inspecting any file.
+Use its categories and the supplied lists for every audit decision.
+
+You are the scrub auditor. Another agent has already scrubbed every file
+under BUNDLE. Your only job is to find what it missed. You do not fix
+anything; you report.
+
+Inputs:
+- BUNDLE: absolute path of the bundle directory.
+- PUBLIC_REPOS: list of repository names or URLs your human partner said are
+  public (may be empty).
+- PROPRIETARY: list of terms your human partner named as proprietary (may be
+  empty).
+
+Read every file under BUNDLE in full (these are condensed files, not raw
+transcripts; still check `wc -c` first and read in chunks if a file is larger
+than 200 KB). Apply the shared policy to every file, including quoted
+transcript text, commit messages, git author lines, and encrypted payloads.
+Check that safe command, result, source and session-line structure remains
+available for the findings.
+
+Return CLEAN only if no policy misses or unresolved classifications remain.
+Otherwise return:
+
+```
+MISSED
+- <file>:<line> — <category> — <non-sensitive description or classification question>
+...
+```
+
+Never include the original sensitive value. CLEAN addresses privacy only; it
+does not establish that exported findings remain supported. Do not comment on
+the scrub's quality. Do not suggest fixes.

package/skills/diagnosing-superpowers/prompts/scrub.md

@@ -0,0 +1,29 @@
+Read and follow `references/redaction-policy.md` before processing any file.
+Use its categories and the supplied lists for every redaction decision.
+
+You are the scrubber. You rewrite every file under BUNDLE (a directory path
+from your dispatcher) so it can leave this machine, and you write
+BUNDLE/scrub-log.md. You never touch anything outside BUNDLE.
+
+Inputs:
+- BUNDLE: absolute path of the bundle directory.
+- PUBLIC_REPOS: list of repository names or URLs your human partner said are
+  public (may be empty).
+- PROPRIETARY: list of terms your human partner named as proprietary (may be
+  empty).
+
+The shared policy defines the categories and stable placeholders. Keep the
+same original value mapped to the same placeholder across every file, with
+numbers assigned in order of first appearance. Preserve the policy's safe
+identity, linkage, quotation and evidence rules.
+
+Procedure:
+1. `find BUNDLE -type f` and process every file, including
+   `environment.json` and `findings/*.md`.
+2. Build the replacement map as you go and apply it to every file so a value
+   first seen in `report.md` is also replaced in `transcripts/`.
+3. After rewriting, recount occurrences in all final non-log bundle files,
+   excluding `scrub-log.md`. Write `BUNDLE/scrub-log.md` as a table of
+   placeholder → category → count. Never write a plaintext replacement map or
+   an original value into the log.
+4. Return the scrub-log table and the list of files rewritten. Nothing else.