diagnosing-superpowers

スーパーパワーの診断

概要

セッションで何が起きたのかを人間のパートナーと特定し、ディスク上のトランスクリプトを読み、根拠を添えて何が起きたのかを報告します。あなたは報告するのであり、スーパーパワーを診断するのではありません。バンドルや問題をトリアージする人が、スーパーパワーを変更するかどうかを判断します。

基本原則： すべての所見には path:line を引用します。引用がなければ、所見とは認めません。すべての数値はトランスクリプトまたは実行したコマンドから取得し、記憶から持ち出してはいけません。

ワークフロー

各ステップについて TODO を作成します。ステップ 5～7 は、記載された条件を満たす場合にのみ実行します。

1. 問題の聞き取り。 セッション、判明していればターンの範囲、パートナーの期待、実際に起きたこと、関心のある観測項目（実時間、トークン数、繰り返された操作、特定の操作）を記載した説明を書けるようになるまで、一度に 1 つずつ質問します。「時間がかかりすぎた」は不満であり、問題の説明ではありません。目的がスーパーパワーのバグ報告かどうかも記録します。
2. 場所の特定。 references/session-discovery.md を使って、各セッションを検証済みの絶対ファイルシステムパスに特定します。過去のセッションについては、最初のプロンプトとタイムスタンプを引用して確認し、却下したすべての候補とその理由、または「なし」を列挙します。サブエージェントのトランスクリプトもすべて列挙します。~/.superpowers/diagnosing-superpowers/<session-id>/ を作成し、パスをパートナーに伝え、環境とスキルの観察事項については記載元のルールに従って、そこに templates/case.md を記入します。
3. トリアージ。 報告された問題の周辺範囲を自分で読みます。その後、ディメンションごとにアナリストのサブエージェントを 1 つずつ並行して起動し、それぞれにケースファイルのパス、prompts/analyst-common.md、および prompts/ 内のディメンションファイル 1 つ（skill-timeline.md、plan-adherence.md、repeated-work.md、stumbles.md、quality-evidence.md、request-conflicts.md、cost-and-time.md）を渡します。トランスクリプトが長い場合は、ディメンションをターンの範囲ごとに分割します。path:line がない返却所見は破棄します。
4. 報告。 templates/report.md のすべてのセクションを順番に記入し、ワークスペースに保存して、内容を表示し、パスを伝えます。引用された内容が実際に何を証明しているかを確認し、裏付けとなるケース資料を保持します。シンボリックリンクの別名は重複コピーではありません。
5. GitHub の issue — 報告書 §7 が「可能性あり」または「可能性が高い」としている場合、またはパートナーから依頼された場合に実行します。references/github-issues.md に従って、症状に該当するオープンおよびクローズ済みの issue を検索します。一致するものを表示し、最も近い issue に報告書を追加することを提案します。一致するものがなければ、templates/issue.md を記入してワークスペースに保存し、正確なテキストを表示して、承認後にのみ issue を作成します。gh ではファイルを添付できません。バンドルがある場合は、ブラウザーで添付できるように、そのパスをパートナーに伝えます。
6. エクスポート — パートナーからバンドルを依頼された場合にのみ実行します。依頼されていないバンドルは作成しません。聞き取りの目的がバグ報告だった場合は、スクラブ済みバンドルを依頼に応じて提供できると 1 回だけ伝え、その後は待ちます。含まれる内容を明示して、マスキングのレベルを尋ねます：骨格（ツール結果の本文なし）、エビデンス（引用されたイベントの本文のみ）、完全版。templates/bundle-README.md に従ってバンドルを作成し、prompts/scrub.md、続いて prompts/scrub-audit.md を実行し、監査結果が CLEAN になるまで両方を繰り返します。最終的なスクラブログ、ファイル一覧、プライバシーとエビデンスの結果を表示する前に、バンドルテンプレートのエビデンス確認と照合作業を完了します。承認後にのみアーカイブ（zip -r または tar -czf）を作成します。アーカイブのパスとともに、内容を説明し、置換内容を確認できるスクラブログを示し、スクラブで見落としが生じる可能性があるため、共有前にすべてのファイルを確認する必要があると伝えます。
7. 類似セッション — 依頼された場合に実行します。確認済みの所見をシグネチャにまとめ、mtime とサイズで候補を列挙し、マーカーの行番号を見つけ、候補ごとに prompts/similar-session.md を並行して実行し、報告書 §9 に追加します。

クイックリファレンス

7 人の分析担当者は、常に全員が実行されます。この表では、ステップ 3 で自分で読む領域と、判定で最初に取り上げる所見を示します。

苦情	最初に読む項目、最初に取り上げる項目
「時間がかかりすぎた」	cost-and-time、stumbles
「なぜこんな余計な作業をしたのか？」	repeated-work、plan-adherence
「なぜこんなに高くつくのか？」	cost-and-time
「いったい何をしているんだ？」（まだ実行中）	skill-timeline；coverage に進行中と記載
「計画を無視した」	plan-adherence、まず圧縮の行
「スキル X が一度も実行されなかった」	skill-timeline

厳守事項

• コンテキストの安全性。 トランスクリプトの 1 行が 1 メガバイトになることがあります。すべてのセッションファイルについて、毎回 references/context-safety.md に従ってください。
• 読み取り専用。 セッションファイルを変更、移動、削除しないでください。
• サブエージェントには正確なパスを渡す。 サブエージェントにとっての「現在のセッション」は、そのサブエージェント自身のものです。絶対パスと ID を渡してください。
• 人間のプロンプトのみ。 フックの出力、システムリマインダー、ツールの結果はパートナーの発言ではありません。サブエージェントのトランスクリプトでは、「user」は親エージェントを指します。
• Superpowers の診断はしない。 §7 では関与の状況を報告し、そこで止めてください。スキルの欠陥を指摘したり、変更を提案したりしてはいけません。パートナーから修正を求められても、このルールの例外にはなりません。該当する手順を示し、要望があればバンドルを用意できると伝えてください。パートナーへの助言もしてはいけません。
• 承認ゲート。 パートナーがスクラブログとファイル一覧を確認する前に、アーカイブしてはいけません。正確な文面の承認を得る前に、課題やコメントを作成してはいけません。また、要約がプレースホルダーのままのものも作成してはいけません。
• 分析の前に聞き取りを行う。 パートナーが回答するまで、ステップ 2～7 の作業を開始してはいけません。不在の場合は質問を書き出して、そこで止めてください。パートナーのために再構成した発言は、回答とはみなされません。すでに対象が絞られた依頼――特定のイベント、現在実行中の処理、または実行する分析のいずれか――は、それ自体が依頼内容です。その場合は対応したうえで、質問してください。セッション全体についての「なぜ」は苦情です。

危険信号

考え	実際
「問題は明らかだから、聞き取りは省略しよう」	問題の説明によって調査範囲が決まります。まず尋ねてください。
「相手が不在だから、依頼内容をこちらで再構成しよう」	相手が何を望んでいたかは再構成できません。質問を書き出して、そこで止めてください。
「今すぐすべてを調べて、最後に尋ねよう」	対象を絞らずに調査すると、相手の予算を誤った問いに使うことになります。まず尋ねてください。
「バグ報告を求められているから、今すぐバンドルを作ろう」	バンドルはパートナーのセッションデータをまとめたものです。求められた場合にのみ作成してください。
「小規模で対象を絞った編集だから、構成変更は必要ない」	どれほど小規模でも、判断するのはあなたではありません。根拠を報告し、トリアージ担当者に判断を委ねてください。
「トークンあたりの価格はよく知られている」	トランスクリプトから自分で計算していない数値は、捏造です。出典を示すか、記載しないでください。