diagnosing-superpowers

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Diagnosing Superpowers

诊断 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.
与你的伙伴一起确定会话中出了什么问题,读取磁盘上的transcript,并用证据报告发生的事情。你只负责报告;你不负责诊断superpowers本身。由分诊triage bundle或issue的人决定superpowers是否改变。
核心原则: 每个发现都引用
path:line
。没有引用就没有发现。每个数字都来自transcript或你运行的命令,绝不来自记忆。

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.
为每个步骤创建todo。步骤5-7仅在指定条件下运行。
  1. 问题接收。 一次只问一个问题,直到你能写出一个陈述,说明会话标识、如果已知的轮次范围、你的伙伴期望什么、发生了什么,以及他们关心的可观察量(墙钟时间、tokens、重复操作、一个具体操作)。"耗时太长"是抱怨,不是问题陈述。注意目标是否是superpowers bug报告。
  2. 定位。 使用
    references/session-discovery.md
    将每个会话解析为验证过的绝对文件系统路径。通过引用其第一个提示词和时间戳来确认过去的会话,并列出你拒绝的每个候选及其原因,或"无"。枚举子代理transcripts。创建
    ~/.superpowers/diagnosing-superpowers/<session-id>/
    ,告诉你的伙伴该路径,并在那里填充
    templates/case.md
    ,遵循其关于环境和skill观察的来源规则。
  3. 分诊。 自己阅读报告问题周围的区域。然后为每个维度并行派发一个分析师子代理,每个子代理获得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
    的每一部分,写入工作区,展示它,并给出路径。检查引用的内容实际证明了什么,并保留支持的case;符号链接别名不是冗余副本。
  5. GitHub issues — 当报告§7说可能或很可能,或你的伙伴要求时。按照
    references/github-issues.md
    搜索已开放和已关闭的issue以查找症状。展示匹配结果,并建议将报告添加到最接近的issue。如果没有匹配,填写
    templates/issue.md
    ,写入工作区,展示确切文本,并且仅在批准后创建issue。
    gh
    无法附加文件;如果存在bundle,给伙伴其路径以在浏览器中附加。
  6. 导出 — 仅当你的伙伴要求bundle时;从不主动构建。如果接收目标是bug报告,说一次经清理的bundle可按要求提供,然后等待。询问脱敏级别,说明每个级别包含的内容:skeleton(无工具结果正文)、evidence(仅引用事件有正文)、full。按照
    templates/bundle-README.md
    构建bundle,派发
    prompts/scrub.md
    ,然后
    prompts/scrub-audit.md
    ,重复两者直到审计返回CLEAN。在展示最终清理日志、文件列表以及隐私和证据结果之前,完成bundle模板的证据检查和核对。仅在批准后归档(
    zip -r
    或
    tar -czf
    )。给出归档路径时,说明其包含内容,指向清理日志以进行替换,并说清理可能会遗漏:他们必须在共享前审查每个文件。
  7. 类似会话 — 当被要求时。将确认的发现转换为签名,按mtime和大小列出候选,找到标记行号,并行派发每个候选的
    prompts/similar-session.md
    ,并追加报告§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.
ComplaintRead 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
所有七个分析师都始终运行。此表说明在第3步中你自己应阅读哪个区域,以及在结论中应首先提出哪些发现。
投诉首先阅读,首先提出
"耗时太长"cost-and-time, stumbles
"为什么它做这些额外工作?"repeated-work, plan-adherence
"为什么这么贵?"cost-and-time
"它到底在做什么?"(仍在运行)skill-timeline;在覆盖范围内注明进行中
"它忽略了计划"plan-adherence,先看compaction行
"Skill X从未触发"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.
  • 上下文安全。 一行transcript可能有一兆字节。每次处理会话文件都要遵循
    references/context-safety.md
    。
  • 只读。 绝不修改、移动或删除会话文件。
  • 子代理的精确路径。 子代理的"当前会话"是其自身的。传递绝对路径和id。
  • 仅人类提示词。 hook输出、系统提醒和工具结果不是伙伴的话。在子代理transcript中,"user"是父代理。
  • 不诊断superpowers。 报告§7陈述参与并停止。绝不在skill中命名缺陷或提出更改。你的伙伴施压要求修复并不免除这一点;指向issue步骤并提到可按要求提供bundle。也不要给你的伙伴建议。
  • 批准门。 在伙伴看到清理日志和文件列表之前不归档。在批准确切文本之前不创建issue或评论。
  • 接收先于分析。 在第2-7步中的任何操作都不会开始,直到你的伙伴回答。如果他们离开,写下问题并停止。你为他们重构的陈述不是回答。一个已经限定的请求——一个具体事件、现在正在运行什么、或者要运行的分析——本身就是那个陈述:回答它,然后提问。整个会话的"为什么"是抱怨。

Red Flags

红旗

ThoughtReality
"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.
想法现实
"问题很明显,跳过接收"问题陈述限制了所有内容。提问。
"他们离开了,所以我会重构陈述"你不能重构他们想要的。写下问题并停止。
"我现在全部扫描,最后再问"无范围的扫描会花他们的预算在错误的问题上。先问。
"他们想要bug报告,所以我现在构建bundle"Bundle是他们的会话数据打包。只有当他们要时才构建。
"小的、有针对性的编辑,不需要重组"不是你的决定,无论多小。报告证据;分诊人决定。
"每token价格众所周知"你没有从transcript计算出的数字都是编造的。引用或删除。