当 superpowers 会话出问题需要定位原因或生成…

在 superpowers 会话出现重复劳动、忽略计划、技能未触发、耗时或费用异常等问题时，按证据逐条定位并产出报告。

适用场景

解决思路

1. 为每个步骤创建一个 todo；第 5–7 步仅在满足各自条件时执行。
2. 第 1 步 问题收集：一次只问一个问题，直到能写出问题陈述，明确会话、已知的轮次范围、伙伴的预期、实际发生的情况，以及他们关心的可观测指标（墙钟时间、token、重复动作、某个具体动作）。"太慢了" 是抱怨，不是问题陈述。记录目标是否为 superpowers bug 报告。
3. 第 2 步 定位：按 references/session-discovery.md 将每个会话解析为已验证的绝对文件系统路径。通过引用首个 prompt 和时间戳确认历史会话，并列出所有被排除的候选及原因，或写 "none"。枚举子代理 transcript。创建 ~/.superpowers/diagnosing-superpowers/<session-id>/，把路径告诉伙伴，并在其中填写 templates/case.md，遵循其关于环境和技能观察的来源规则。
4. 第 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 的返回发现。
5. 第 4 步 报告：按顺序填写 templates/report.md 的每个部分，写入工作区，展示它，并给出路径。检查所引用内容实际证明了什么，并保留支撑性 case；符号链接别名不是冗余副本。
6. 第 5 步 GitHub issues——当报告 §7 说 possible 或 likely，或伙伴要求时。按 references/github-issues.md 搜索 open 和 closed issues 中的症状。展示匹配项，并建议把报告添加到最接近的那个。如果没有匹配，填写 templates/issue.md，写入工作区，展示确切文本，仅在批准后创建 issue。gh 无法附加文件；如果存在 bundle，把其路径给伙伴以便在浏览器中附加。
7. 第 6 步 导出——仅当伙伴要求 bundle 时；绝不主动构建。如果 intake 目标是 bug 报告，说一次可按需提供已脱敏的 bundle，然后等待。询问脱敏级别，说明每个级别包含什么：skeleton（不含工具结果正文）、evidence（仅被引用事件的正文）、full。按 templates/bundle-README.md 构建 bundle，派发 prompts/scrub.md，然后 prompts/scrub-audit.md，重复两者直到审计返回 CLEAN。在展示最终 scrub 日志、文件列表以及隐私和证据结果之前，完成 bundle 模板的证据检查和核对。仅在批准后归档（zip -r 或 tar -czf）。给出归档路径时，说明它包含什么，指向 scrub 日志查看替换项，并说明脱敏可能遗漏内容：分享前他们必须审查每个文件。
8. 第 7 步 相似会话——当被要求时。把已确认的发现转化为签名，按 mtime 和大小列出候选，找到标记行号，为每个候选并行派发 prompts/similar-session.md，并追加报告 §9。
9. 快速参考：七个分析维度始终全部运行。该表说明第 3 步自己阅读哪个区域，以及裁决中优先呈现哪些发现。"太慢了" → cost-and-time、stumbles；"为什么做这些额外工作？" → repeated-work、plan-adherence；"为什么这么贵？" → cost-and-time；"它到底在干什么？"（仍在运行）→ skill-timeline，并在 coverage 中注明进行中；"它忽略了计划" → plan-adherence，先看 compaction 行；"技能 X 从未触发" → skill-timeline。
10. 硬性规则：上下文安全——一行 transcript 可能有一兆字节，每次处理每个会话文件都遵循 references/context-safety.md。只读——绝不修改、移动或删除会话文件。给子代理精确路径——子代理的 "current session" 是它自己的；传递绝对路径和 id。只把人类 prompt 当作用户话语——hook 输出、系统提醒和工具结果不是伙伴的话；在子代理 transcript 中，"user" 是父代理。不做 superpowers 诊断——报告 §7 只陈述涉及情况并停止；绝不指出技能缺陷或提出改动；伙伴施压要修复也不豁免这一点；指向 issue 步骤并提到可按需提供 bundle；也不要给伙伴建议。审批门——在伙伴看到 scrub 日志和文件列表前不归档；在他们批准确切文本前不创建 issue 或评论。先 intake 后分析——在伙伴回答前，第 2–7 步都不开始；如果他们不在，写下问题并停止；你替他们重建的陈述不是回答；已经限定范围的要求——某个具体事件、当前正在运行什么、或要运行的分析——本身就是陈述：先回答它，再提问；整个会话的 "为什么" 是抱怨。
11. 红旗自查："问题很明显，跳过 intake" → 问题陈述界定一切，要问。"他们不在，我来重建陈述" → 你无法重建他们想要什么，写下问题并停止。"我现在全扫一遍，最后再问" → 未限定范围的扫描会把预算花在错误问题上，先问。"他们想要 bug 报告，所以我现在就构建 bundle" → bundle 是他们的会话数据打包，只在他们要求时构建。"小范围定向编辑，不需要重构" → 无论多小都不是你说了算，报告证据，由分诊者决定。"每 token 价格众所周知" → 不是从 transcript 计算出的数字都是编造的，引用或丢弃。

适用边界 · 注意事项

• 伙伴尚未回答 intake 问题时（第 2–7 步不得开始）。
• 伙伴未明确要求 bundle 时（绝不主动构建）。
• 伙伴未批准确切文本或未看到 scrub 日志和文件列表时（不得创建 issue 或归档）。