@wenaixi/dsh-superpower 7.4.1 → 7.5.1

package/skills/brainstorming/visual-companion.md

@@ -1,54 +1,51 @@
-# 可视化辅助指南
+# Visual Companion Guide
 
-基于 DSH 官方文档预览的头脑风暴辅助工具，用于展示原型、图表和选项。
+Browser-based visual brainstorming companion for showing mockups, diagrams, and options, built on DSH's official document preview.
 
-## 何时使用
+## When to Use
 
-按问题逐个判断，而非按会话判断。判断标准：**用户看图是否比看文字更易理解？**
+Decide per-question, not per-session. The test: **would the user understand this better by seeing it than reading it?**
 
-**内容本身是可视化的场景，适合用浏览器预览：**
+**Use the browser preview** when the content itself is visual:
 
-- **界面原型** — 线框图、布局、导航结构、组件设计
-- **架构图** — 系统组件、数据流、关系图谱
-- **并排可视化对比** — 对比两种布局、两种配色方案、两种设计方向
-- **设计打磨** — 问题涉及外观与质感、间距、视觉层级
-- **空间关系** — 状态机、流程图、实体关系等以图形方式呈现
+- **UI mockups** — wireframes, layouts, navigation structures, component designs
+- **Architecture diagrams** — system components, data flow, relationship maps
+- **Side-by-side visual comparisons** — comparing two layouts, two color schemes, two design directions
+- **Design polish** — when the question is about look and feel, spacing, visual hierarchy
+- **Spatial relationships** — state machines, flowcharts, entity relationships rendered as diagrams
 
-**内容为文本或表格的场景，适合使用终端：**
+**Use the terminal** when the content is text or tabular:
 
-- **需求与范围问题** — 「这是什么意思？」，「哪些功能在范围内？」
-- **概念性的 A/B/C 选择** — 在文字描述的方案之间做选择
-- **权衡清单** — 优缺点、对比表格
-- **技术决策** — API 设计、数据建模、架构方案选型
-- **澄清性问题** — 任何答案是文字而非视觉偏好的问题
+- **Requirements and scope questions** — "what does X mean?", "which features are in scope?"
+- **Conceptual A/B/C choices** — picking between approaches described in words
+- **Tradeoff lists** — pros/cons, comparison tables
+- **Technical decisions** — API design, data modeling, architectural approach selection
+- **Clarifying questions** — anything where the answer is words, not a visual preference
 
-一个*关于*界面主题的问题并不自动等同于可视化问题。「你想要哪种向导？」是概念性问题——使用终端。「这些向导布局中哪一个更合适？」是可视化问题——使用浏览器预览。
+A question *about* a UI topic is not automatically a visual question. "What kind of wizard do you want?" is conceptual — use the terminal. "Which of these wizard layouts feels right?" is visual — use the browser preview.
 
-## 工作原理
+## How It Works
 
-你把 HTML 写入工作区的一个约定目录，DSH 的文档预览面板读取并渲染它。用户在浏览器侧的文档栏打开该文件即见画面。
+You write HTML to a convention directory in the workspace; DSH's document preview reads and renders it. The user opens the file in the document sidebar to see it.
 
-**选择结果不会自动回传给你。** 预览是一个隔离的 iframe 文档，它无法把你的选择送达会话。所以：让用户在终端里回答。绝不要声称读到了用户在预览里的点击。
+**Selection results are not sent back to you automatically.** The preview is an isolated iframe document and cannot deliver your user's choices to the session. So: ask the user to answer in the terminal. Never claim to have read a click inside the preview.
 
-## 写文件
+## Writing Files
 
-把每一页 HTML 写成一个自包含的完整文档。三条硬要求：
+Write every page as a self-contained HTML document. Three hard requirements:
 
-1. **完整文档。** 官方预览不做内容包裹，不提供任何现成 CSS 类。
-   `<div class="options">` 在这里没有任何含义，页面上什么都不会出现。
-2. **自包含。** 不引用外部相对路径的 CSS 或脚本——相对依赖只在交互预览
-   开关打开时才被打包。写单文件最稳。
-3. **不依赖 iframe 外的能力。** 预览文档与宿主页面不共享上下文，
-   `window.parent` 拿不到任何东西。
+1. **Full document.** The official preview wraps nothing and provides no ready-made CSS classes. `<div class="options">` means nothing here; nothing renders on the page.
+2. **Self-contained.** Do not reference external relative CSS or scripts — relative dependencies are bundled only when interactive preview is enabled. A single file is safest.
+3. **No outside-iframe capabilities.** The preview document does not share the host page context; `window.parent` gets nothing.
 
-### 最小示例
+### Minimal example
 
 ```html
 <!DOCTYPE html>
-<html lang="zh">
+<html lang="en">
 <head>
 <meta charset="utf-8">
-<title>布局方案</title>
+<title>Layout options</title>
 <style>
   body { font: 15px/1.7 system-ui, sans-serif; margin: 0; padding: 40px; }
   h1 { font-size: 20px; margin: 0 0 6px; }
@@ -60,65 +57,64 @@
 </style>
 </head>
 <body>
-  <h1>哪种布局更合适？</h1>
-  <p class="subtitle">请考虑可读性与视觉层级</p>
+  <h1>Which layout fits better?</h1>
+  <p class="subtitle">Consider readability and visual hierarchy</p>
   <div class="cards">
     <div class="card">
-      <h3>A 单列</h3>
-      <p>阅读体验最好，信息密度最低</p>
+      <h3>A Single column</h3>
+      <p>Best reading experience, lowest information density</p>
     </div>
     <div class="card">
-      <h3>B 两列</h3>
-      <p>空间利用率高，需要额外样式约束</p>
+      <h3>B Two columns</h3>
+      <p>Higher space utilization, needs extra style constraints</p>
     </div>
   </div>
 </body>
 </html>
 ```
 
-深色环境下把配色换成跟随 `prefers-color-scheme`，或直接用中性灰阶。
+In dark environments, switch colors to follow `prefers-color-scheme` or use neutral grays.
 
-## 目录与命名
+## Directory and Naming
 
-约定目录：项目根下的 `.superpowers/brainstorm/`。会话结束后由你自行删除。
+Convention directory: `.superpowers/brainstorm/` under the project root. Delete it yourself when the session ends.
 
-- 使用语义化名称：`platform.html`、`visual-style.html`、`layout.html`
-- 不要复用文件名——每次迭代写一个新文件，`layout-v2.html`、`layout-v3.html`
-- 用户打开的是他指定的那一个文件；改完告诉他新文件名
+- Use semantic names: `platform.html`, `visual-style.html`, `layout.html`
+- Do not reuse filenames — write a new file each iteration, `layout-v2.html`, `layout-v3.html`
+- The user opens the specific file they were told about; tell them the new filename when you rewrite
 
-若项目的 `.gitignore` 尚未包含 `.superpowers/`，提醒用户添加。
+If the project's `.gitignore` does not yet include `.superpowers/`, remind the user to add it.
 
-## 循环流程
+## Loop Flow
 
-1. **写入 HTML** 到约定目录，用文件工具创建，不要用 `cat`/heredoc（会在终端产生大量噪音）。
-2. **告知用户预期内容并结束本轮**：
-   - 提醒文件路径，以及如何在右侧文档栏打开它；
-   - 简要文字概括这一页在展示什么（例如「正在展示首页的 3 种布局方案」）；
-   - 请他们在终端里回答。措辞要让人知道在哪里回答。
-3. **读用户的终端回复**。这是唯一的选择回传通道。
-4. **迭代或推进** —— 若反馈改变了当前页面，写一个新版本文件。
-5. **回到终端时清场** —— 下一步不需要预览时，删除不再需要的 HTML 文件，
-   避免用户在文档栏看到早已解决的问题。
-6. 重复直至完成。
+1. **Write HTML** to the convention directory with file tools, not `cat`/heredoc (they flood the terminal).
+2. **Tell the user what to expect and end the turn**:
+   - Remind the file path and how to open it in the right-hand document sidebar;
+   - Summarize in words what this page shows (e.g. "showing 3 layout options for the homepage");
+   - Ask them to answer in the terminal, and say where.
+3. **Read the user's terminal reply.** This is the only selection return channel.
+4. **Iterate or move on** — if feedback changes the current page, write a new version file.
+5. **Clean up when back in the terminal** — delete HTML files no longer needed, so the user does not see stale problems in the document sidebar.
+6. Repeat until done.
 
-## 逐题决策
+## Per-Question Decisions
 
-即使用户已接受预览，仍需针对每个问题决定是否值得画出来：
+Even after the user accepts the preview, decide per question whether it is worth drawing:
 
-- **使用预览** 处理视觉内容——原型、线框、布局对比、架构图、并排视觉设计
-- **使用终端** 处理文本内容——需求问题、概念抉择、权衡清单、A/B/C/D 文本选项、范围决策
+- **Use preview** for visual content — mockups, wireframes, layout comparisons, architecture diagrams, side-by-side visual designs
+- **Use terminal** for text content — requirement questions, conceptual choices, tradeoff lists, A/B/C/D text options, scope decisions
 
-涉及 UI 话题的问题不一定是视觉问题。「在此上下文中 personality 指什么？」是概念问题——使用终端。「哪种向导布局更合适？」是视觉问题——使用预览。
+A question about a UI topic is not necessarily visual. "What does personality mean in this context?" is conceptual — use the terminal. "Which wizard layout feels better?" is visual — use the preview.
 
-## 设计建议
+## Design Advice
 
-- **按问题匹配保真度**——布局问题用线框图，视觉打磨问题再做精细化
-- **在每页上说明问题**——「哪种看起来更专业？」而非仅仅「选一个」
-- **先迭代再推进**——若反馈改变了当前页面，先写一个新版本
-- **每屏最多 2-4 个选项**
-- **在重要场景使用真实内容**——真实文案与真实配色比占位文本更能暴露问题
-- **保持原型简洁**——聚焦布局与结构，而非像素级完美
+- **Match fidelity to the question** — wireframes for layout questions, polish only for visual-fidelity questions
+- **State the question on each page** — "Which looks more professional?" rather than just "pick one"
+- **Iterate before pushing** — if feedback changes the page, write a new version first
+- **At most 2-4 options per screen**
+- **Use real content for important scenarios** — real copy and colors expose problems better than placeholder text
+- **Keep mockups lean** — focus on layout and structure, not pixel perfection
 
-## 清理
+## Cleanup
 
-删除本次会话写下的所有 HTML 文件。若用了项目目录，提醒用户该目录已在 `.gitignore` 中。
+Delete every HTML file written this session. If a project directory was used, remind the user that the directory is in `.gitignore`.

package/skills/diagnosing-superpowers/SKILL.md

@@ -1,58 +1,122 @@
 ---
 name: diagnosing-superpowers
-description: "Superpower Skill：当 superpowers 会话出错、human partner 想查原因（重复工作、忽略计划、技能未触发、耗时过长、成本过高、结果不佳）或想为维护者建缺陷报告时，适用当前或历史会话。"
+description: "Superpower Skill: 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."
+description_zh: "Superpower Skill：当 superpowers 会话出错、human partner 想查原因（重复工作、忽略计划、技能未触发、耗时过长、成本过高、结果不佳）或想为维护者建缺陷报告时，适用当前或历史会话。"
 ---
 
-# 诊断 superpowers
 
-## 概览
+# Diagnosing Superpowers
 
-与你的 human partner 一起确定会话中哪里出了问题，读取磁盘上的 transcript，并基于证据报告实际发生的情况。你负责报告；你不对 superpowers 做诊断。由分诊 bundle 或 issue 的人决定 superpowers 是否要改。
+## Overview
 
-**核心原则：** 每条发现都引用 `path:line`。没有引用就没有发现。每个数字都来自 transcript 或你运行的命令，绝不来自记忆。
+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.
 
-每个步骤创建一个 todo。步骤 5–7 仅在其所述条件满足时运行。
+## Workflow
 
-1. **问题收集。** 一次只问一个问题，直到你能写出一份陈述：指明会话（们）、已知的回合范围、你的 human partner 期望什么、实际发生了什么、以及他们关心的可观察量（墙钟时间、token 数、重复动作、某个具体动作）。"耗时太长"是抱怨，不是问题陈述。同时记录目标是否为提交 superpowers 缺陷报告。
-2. **定位。** 使用 `references/session-discovery.md` 把每个会话解析为经过验证的绝对文件系统路径。通过引用其首个 prompt 与时间戳来确认历史会话，并列出你拒绝的每个候选及其原因，没有则写"无"。枚举 subagent transcript。创建 `~/.superpowers/diagnosing-superpowers/<session-id>/`，把路径告诉你的 human partner，并按 `templates/case.md` 在其中填写 case 文件，遵循其对环境与技能观察的来源（provenance）规则。
-3. **分诊。** 亲自阅读报告问题周围的区域。然后按维度并行派出分析师 subagent，每个 subagent 获得 case 文件路径、`prompts/analyst-common.md` 以及 `prompts/` 中的一个维度文件：`skill-timeline.md`、`plan-adherence.md`、`repeated-work.md`、`stumbles.md`、`quality-evidence.md`、`request-conflicts.md`、`cost-and-time.md`。transcript 较长时按回合范围拆分维度。丢弃任何缺少 `path:line` 的返回发现。
-4. **报告。** 按顺序填满 `templates/report.md` 的每一节，写入 workspace，展示并给出路径。检查引用的内容实际证明了什么，并保留支撑性 case；符号链接别名不是冗余副本。
-5. **GitHub issues** — 当报告 §7 显示"可能（possible）"或"很可能（likely）"，或你的 human partner 要求时。按 `references/github-issues.md` 搜索已开与已关闭 issue 中的症状。展示匹配项并建议把报告附加到最接近的一条。若无匹配，填写 `templates/issue.md`，写入 workspace，展示确切文本，仅在批准后创建 issue。`gh` 无法附加文件；若存在 bundle，把路径交给你的 human partner 在浏览器中附加。
-6. **导出** — 仅当你的 human partner 要求 bundle 时；绝不未经要求构建。若收集阶段的目标是缺陷报告，说一次"可按需提供已脱敏的 bundle"，然后等待。询问脱敏级别，说明各级包含什么：skeleton（无工具结果正文）、evidence（仅被引用事件有正文）、full。按 `templates/bundle-README.md` 构建 bundle，派出 `prompts/scrub.md`，然后 `prompts/scrub-audit.md`，重复两者直到审计返回 CLEAN。完成 bundle 模板的证据检查与对账后，再展示最终脱敏日志、文件清单与隐私和证据结论。仅在批准后归档（`zip -r` 或 `tar -czf`）。给出归档路径时，说明其包含内容、指出脱敏日志中的替换，并说明脱敏可能遗漏：他们必须在分享前审阅每个文件。
-7. **相似会话** — 应要求时。把已确认的发现转为签名（signature），按 mtime 与大小列出候选，找出标记行号，对每个候选并行派出 `prompts/similar-session.md`，并把报告 §9 追加进去。
+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.
 
-七个分析师始终运行。本表说明步骤 3 中你要亲自读哪个区域，以及在结论中优先展示哪些发现。
+## 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 |
 |---|---|
-| "耗时太长" | cost-and-time, stumbles |
-| "为什么做了这份额外工作？" | repeated-work, plan-adherence |
-| "为什么这么贵？" | cost-and-time |
-| "它在搞什么鬼？"（仍在运行） | skill-timeline；在覆盖范围注明进行中 |
-| "它忽略了计划" | plan-adherence，压缩行优先 |
-| "技能 X 从未触发" | skill-timeline |
-
-## 铁律
-
-- **上下文安全。** 一行 transcript 可能有一兆字节。对每个会话文件的每次读取都遵循 `references/context-safety.md`。
-- **只读。** 绝不修改、移动或删除会话文件。
-- **给 subagent 的绝对路径。** subagent 的"当前会话"是它自己的。传递绝对路径与 id。
-- **仅限人类 prompt。** 钩子输出、系统提醒与工具结果不是你的 human partner 的话。在 subagent transcript 中，"user"是父代理。
-- **不做 superpowers 诊断。** 报告 §7 说明参与程度并就此打住。绝不在技能中指认缺陷或提出修改。你的 human partner 催促修复并不豁免这一点；指向 issue 步骤并提及可按需提供 bundle。也不给你的 human partner 任何建议。
-- **审批关卡。** 在你的 human partner 看到脱敏日志与文件清单之前，不归档。他们批准确切文本之前，不创建 issue 或评论。
-- **分析前先收集。** 步骤 2–7 的任何事情都要等你的 human partner 回答后才开始。若他们不在，写下问题并停止。你为他们重构的陈述不是回答。已界定范围的请求——某个具体事件、现在正在运行什么、或要运行的分析——本身就是陈述：先回答它，再提问。对整个会话的"为什么"是抱怨。
-
-## 红旗
-
-| 想法 | 实际情况 |
+| "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 |
 |---------|---------|
-| "问题很明显，跳过收集" | 问题陈述界定了所有范围。问。 |
-| "他们不在，我重构陈述" | 你无法重构他们想要的东西。写下问题并停止。 |
-| "我先全量扫描，最后再问" | 未界定范围的扫描把他们的预算花在错误的问题上。先问。 |
-| "他们要缺陷报告，我这就构建 bundle" | bundle 是他们的会话数据被打包。仅当他们要求时才构建。 |
-| "小范围、有针对性的编辑，无需重构" | 这不是你说了算，无论多小。报告证据；由分诊者决定。 |
-| "每 token 的价格众所周知" | 你不是从 transcript 算出的数字都是编造的。引用或删除。 |
+| "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

@@ -1,24 +1,38 @@
-你是分析师 subagent。你读取磁盘上的编码代理会话 transcript，并返回带证据的发现。你不修复任何东西，不修改会话存储下的任何文件，也不说 superpowers 应该改什么。
-
-输入（来自你的派发者）：
-- CASE：case 文件的绝对路径。先读它。它指明会话文件、要使用的已发现来源与记录含义，以及你必须遵守的上下文安全规则。使用已记录的含义，而不是重复发现或假定 harness 格式。
-- RANGE（可选）：回合范围或行范围。若存在，只分析该范围，并在你的 Checked 行中说明。
-
-上下文安全：读取每个文件前，遵循 CASE 中点名的 `references/context-safety.md`，并用已记录的命令或查询提取字段。"当前会话"不是你能查看的东西：只使用 CASE 中的路径。
-
-人类 prompt 是 case 文件识别为人类输入的记录。钩子输出、系统提醒与工具结果不是人类 prompt。在 subagent transcript 中，"user"是父代理。
-
-返回格式（无其他内容）：
+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: <一句话，发生了什么>
-  evidence: <绝对路径>:<行> — "<引文，至多 200 字符>"
-  turns: <首个人类回合>–<末个人类回合>
-  confidence: 高 | 中 | 低
+- 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: <你检查了什么：文件、行范围、用到的命令>
+Checked: <what you examined: files, line ranges, commands used>
 ```
 
-派发者丢弃任何缺少 `path:line` 的发现，所以不要写这样的发现。若你什么都没找到，返回 `- none found` 与 Checked 行。
+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

@@ -1,12 +1,28 @@
-先读 `prompts/analyst-common.md`；它给出你的角色、输入、上下文安全规则与返回格式。本文件补充维度。
+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
 
-核算 token 与墙钟时间花在哪里。
+Account for where tokens and wall-clock went.
 
-1. Token。只使用 case 文件中确立的用量记录与计数器含义。计算总计前先说清每个计数器是增量还是累计；对累计观测做差分，且不把缺失观测变成零。报告支撑总量最大的五个回合，以及每个关联会话的支撑总量。
-2. 墙钟时间。使用 case 文件中记录的、有证据的时间戳字段、事件边界与单位。报告支撑时间最长的五个回合，以及相邻事件之间超过十分钟的任何间隔（空闲、等待关联会话、或等待你的 human partner；记录显示是哪种才说哪种）。
-3. 最大的工具结果：使用 case 文件有证据的工具结果记录，报告最大的十个结果及其工具与回合。提取有界内容前先量记录。
-4. 压缩：统计并定位在发现阶段确立含义为压缩事件的记录。报告可用的前后计数器，以及每次触发时会话在做什么；缺失的字段标记为不存在。
-5. 关联会话：统计数量，并报告每个的支撑用量、时长与派发回合。
-6. 报告主导总量的回合、subagent、工具或重复，附数字。除 transcript 显示的内容外，不要推测回合昂贵的原因。
+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

@@ -1,15 +1,29 @@
-先读 `prompts/analyst-common.md`；它给出你的角色、输入、上下文安全规则与返回格式。本文件补充维度。
+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
 
-恢复会话商定的计划，然后把每个计划步骤映射到实际发生的事情。"计划"这里指任何商定的行动路线，而非 git 提交。
+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. 找出商定的计划：对话中商定的设计或计划（查找人类 "yes/ok/go ahead" 之前的助手文本）、会话期间写下的规格或计划文件（写入 `docs/`、`plans/`、`specs/` 下的任何文件的工具调用，或人类点名的任何文件）、含义在 case 文件中确立的待办列表记录、或助手文本中的任何编号清单。用 `path:line` 引用每个计划步骤。
-2. 标记计划与其执行之间的结构性事件：发现阶段识别的压缩事件、恢复、中止回合与关联会话派发。记录其行号；紧接此类事件之后的计划漂移是独立的发现。
-3. 对每个计划步骤，找到执行它的工具调用与助手文本，或确立没有任何执行。报告：
-   - 跳过的步骤（未找到执行；引用计划步骤）；
-   - 乱序执行的步骤（行号显示顺序）；
-   - 被静默改动的步骤（执行与计划步骤的差异方式助手从未宣布；两处都引用）；
-   - 发明的步骤（执行了计划步骤未覆盖的工作）；
-   - 结构性事件之后的立即漂移（引用事件行与第一个偏离动作）。
-4. 若无可恢复的计划，把它作为唯一发现说明，附你检查过的行。
+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

@@ -1,11 +1,26 @@
-先读 `prompts/analyst-common.md`；它给出你的角色、输入、上下文安全规则与返回格式。本文件补充维度。
+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. 测试：每次测试运行（包含 `test`、`pytest`、`npm test`、`cargo test`、`go test`、`bats`、`bash tests/…` 或指令文件中点名的项目运行器的命令）及其结果行。报告失败的运行与助手接下来做了什么。
-2. 声明背后的验证：寻找声称 done、fixed、passing、verified、works、complete 的助手文本。对每一条，在同一回合中向后查找能证明它的工具结果（测试运行、命令输出、diff）。报告该回合中无支撑结果的声明。
-3. 提交：每次 `git commit` 及其消息；把每条消息与前一回合（们）的工具调用对比。报告消息声称了工作而没有任何工具调用执行它的提交，以及商定计划说会提交却从未提交的执行工作。
-4. 评审反馈：reviewer（人或 subagent）提出观点的地方，找到回应。报告被承认但未落实的观点，以及无陈述理由就被驳回的观点。
-5. 验收标准：若 case 文件的问题陈述或商定计划陈述了标准，把每条报告为 达成 / 未达成 / 未检查，附证据行。
+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

@@ -1,19 +1,30 @@
-先读 `prompts/analyst-common.md`；它给出你的角色、输入、上下文安全规则与返回格式。本文件补充维度。
+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. 把每次工具调用提取为 `(line, turn, tool, key)`，其中 `key` 是：读取/编辑/写入的文件路径；shell 调用的命令文本（去掉尾部空白；保留整条命令）；subagent 派发的 `description` 加 prompt 的前 80 个字符；搜索的查询。
-2. 按 `(tool, key)` 分组，报告达到或超过阈值的组：
+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 |
    |---|---|---|
-   | 读取、搜索 | 3 | |
-   | 编辑 | 2 | |
-   | shell 命令 | 2 | 状态检查与测试运行（`git status`、`ls`、`pwd`、测试运行器） |
-   | subagent 派发 | 2 且 description 相同 | |
-
-3. 对每组，检查重复之间是否有什么变化（对该文件的写入、压缩、人类纠正）。说明属于哪种情况：编辑后的重读不是发现；压缩后的重读是归因于压缩的发现；之间什么都没有的重读本身就是发现。
-4. 寻找重新推导的决定：助手文本得出了会话早前已陈述的结论（同一文件、同一设计选择、同一要运行的命令）。两处都引用。
-5. 每组一条发现，附首末行号与计数。
+   | 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.