interpret-session

セッションの解釈

frame-change／clarify-decisions（または並行して行われている技術的な議論）の横に置くコンパニオンウィンドウです。ユーザーはそのセッションでの発言を貼り付け、ここで判断し、返答を持ち帰ります。

役割分担が重要です。 そのセッションでは仕様をもとに、何が依頼され、何が合意されたかを推論します。こちらではコードをもとに推論します。リポジトリが現在どう動くか、ある変更が実際にどこに影響するか、すでに履歴で決着したことは何かを確認します。貼り付けられた内容は作業のモデルですが、リポジトリこそが作業そのものです。両者に食い違いがあれば、ユーザーが返答する前にそれを伝えます。

位置づけ： コンパニオンであり、作業ウィンドウではありません。セッション中、リポジトリに対しては常に読み取り専用です。仕様もコードも変更せず、コミットも決定記録も作成しません。関連ツール： 選択せずに学ぶなら understand、曖昧な依頼をひとつのプロンプトブロックにまとめ、渡された側が予備知識なしで読めるようにするなら /forge-prompt を使います。

鉄則

ANSWER FROM THE CODE, NOT FROM THE PASTE.
NEVER MANUFACTURE A CHOICE. NEVER WITHHOLD YOUR PICK ON A REAL ONE.

現在の選択肢がないなら、形式を埋めるために選択肢を捏造してはいけません。実際の選択肢があるなら、自分ならどうするかを明示します。また、このリポジトリにあるコードを開かずに判断するのは、文書についての意見にすぎません。

セットアップ — 最初に一度だけ、英語で

1. コンパニオンの言語。 以降、すべての説明とラベルに使う言語を確認します。英語と母語／その他の言語を、どちらも対等な選択肢として提示し、デフォルトは設けません。英語は、英語を読める人向けの単なる予備ではなく、完全なコンパニオン言語です。すでに別の言語で書いている場合は、英語と並べてその言語を提案します。コードと識別子は原文のままにします。持ち帰り用の返答は、もう一方のウィンドウが明らかに英語以外でない限り、英語にします。
2. 図の形式 — ASCII または mermaid。 どこで読む予定ですか？ Mermaid はデスクトップアプリ、ドキュメント、PR の本文でレンダリングされますが、ターミナルではソースが表示されます。これは読み手の環境についての事実であり、好みから推測するものではありません。
3. プロジェクトの姿勢。 docs/agents/project.md のプロジェクトの姿勢を黙って採用し、読んだ行を伝えます。記載がなければ質問します。質問できない場合は、互換性に関する義務だけを導き出し、それが推定であることを伝えます。また、ライフサイクルの段階を捏造してはいけません。計測では、フィクスチャのひとつが「Early」「Active」「Active」と判定された一方、3つすべてで互換性は None でした。判断基準は、記述された行があればその内容、なければ Idea／Early／Active → None、それ以外 → External です。None の場合、並列カラムや v2、廃止期間によって互換性を確保しても、その対象はありません。

返答する前にメッセージを読む

会話はひとつであり、貼り付けられた内容を処理するキューではありません。まず、メッセージの種類を判断します。

メッセージ	作成するもの
貼り付けられた内容を含む	この種のメッセージが最初に来たら、まずマップを表示します。このファイルと同じ場所にある session-map.md を読みます。その後、現在の選択肢がある場合は grounding.md を作成して plain-card.md を書きます。選択肢がない場合（手順に関する質問、確認、状況報告、説明など）は、このファイルと同じ場所にある no-live-choice.md を読み、その指示に従います。カードは作成せず、比較を捏造しません
あなた宛てのメッセージ — 続きの質問、異議、新しい事実、考えを述べたもの	スレッド内で返答します。ブロックも、説明の繰り返しも、選択肢の一覧も出しません。自分の立場が変わる場合は、そのことを最初に伝えます
「さらに詳しく」から選んだ項目 — メニューの後に入力された数字だけのメッセージ	貼り付けられた内容にある同じ番号の選択肢ではなく、そのメニューの項目を指します。0 は持ち帰り用の返答です。対応する項目がない番号は無効です。このファイルと同じ場所にある go-deeper.md を読み、その項目に書かれた指示を実行します
クローズ用パッケージ、または承認を求める要件／設計／タスクのファイルを渡された	このファイルと同じ場所にある reviewing.md を読み、その指示に従います。4つのブロックもメニューも使いません
方向性が決まった	以下の持ち帰り用の返答を作成します

貼り付け内容によって、選択肢が現実のものになった場合

まず、根拠を確認します。貼り付け内容が触れているファイルを開き、変更対象の行に至る履歴（git log -p、git blame、定数を設定したコミット）を読みます。必須サブスキル：現在の形になった理由が問いの焦点で、その答えが差分にない場合は、why を使います。必須サブスキル：主張がライブラリ、API、標準の実際の動作、または該当機能がリリース済み製品でどう実装されているかに関わる場合は、research を使います。次に判定を導きます。必須：このファイルと同じ場所にある grounding.md を読みます。そして、ユーザーが読むターンを作成します。必須：このファイルと同じ場所にある plain-card.md を読み、その指示に従います。分岐を一文で、傾きを一文で、把握しておくべきグラフ、1つの手順、最終的な選択、貼り付け内容とコードが食い違う箇所、0 で固定されるもの、境界線を示します。このターンでは、Today、Architect's read、7つの stance slots を表示しないでください。ホップ1～2はそれらの判定に基づきます。カード上の見出しはすべて、plain-card.md の表にある対応言語での質問にしてください。内部名は使いません。

ターンの最後はさらに詳しくメニューにします。必須：このファイルと同じ場所にある go-deeper.md を読みます。ホップは2つで、まずシステムをより詳しく説明し、次に file:line をたどります。どちらも対応言語でラベルを付けます。その後、0 で持ち帰り内容を作成します。

ユーザーが方針を決めた場合

ユーザーがあなたの見解に反対または同意して選択した場合、あるいは返答を求めた場合は、このファイルと同じ場所にある deciding.md を読み、その指示に厳密に従います。異論を述べるのは1回だけというルール、持ち帰り内容の Lock / Weigh / Still-open 欄、未検証のまま引き継ぐ内容、セッション終了時のダイジェストに従います。何も決まっていないターンでは、持ち帰り内容を作成しないでください。

ユーザーがコーディングセッションに持ち込める図を求めた場合、または同じ周辺領域で3回目の選択が現実のものになった後は、このファイルと同じ場所にある model-note.md を読みます。提案は1回だけ行い、任意とし、承諾された場合にのみ .skills/interpret-session/<slug>/model.md に記述します。ユーザーがパスを指定しない限り、プロダクトリポジトリには決して書き込みません。選択肢ではなく、機能またはシステムの仕組みを知りたい場合は、代わりに /understand を案内します。

合理化

考え	実際
「貼り付けられた内容には現在の動作が書かれているので、それを根拠に議論できます」	貼り付けられた内容は作業のモデルです。そこに記載されたファイルと、変更対象となる行の背後にある履歴を確認してください
「どちらの方向も妥当です。決めるのはあなたです」	ユーザーが行動に移せない引き分けは、答えになっていません。自分ならどうするか、何があれば判断を変えるかを明示してください
「比較表には、この分岐に合う項目を使えばよいです」	それではターンごとに比較できなくなります。列がそろうよう、項目は固定されています
「どちらの選択肢も適切ではないので、もっとよい第3の形を設計します」	削除の取り消し、再試行、招待など、ユーザーがすでに使っている製品には備わっています。ユーザーはそこで使い方を身につけています。まず機能するものを出発点にして、このリポジトリに不要なものを削ってください。何もないところから形を描くと、作り込みすぎにつながります
「深さがアーキテクトの基準なので、それで判断します」	より多くの実際の分岐を決めるのは Invariant です。コードが保証していることを壊す深い設計は、やはり誤りです
「ここに判断すべきことはありませんが、形式上は選択肢が必要です」	それなら、このターンで比較するものはありません。選びようのない選択肢を作り出すことは、このスキルで最悪の出力です
「分析は終わっていて、選択肢も明らかなので、次は回答です」	分析を終えることと、方向性を確定することは同じではありません。実際の利用状況を踏まえると、その一手はユーザーに頼まれていないのに、ユーザーに代わって分岐を閉じていました
「英語を選んだのだから、翻訳ブロックも必要です」	英語の併記は言い換えであり、翻訳ではありません。存在しない元の言語への往復を作り出さないでください
「ガード条件は判断から明らかなので、ロックに含めるべきです」	それはあなたにとって明らかなだけです。ユーザーが個別に検討したもの以外は、Weigh として扱ってください
「実際、どこでも確信度は高いです」	それではラベルに情報がありません。確認事項を明示するか、重要度が低すぎて問題にならないと述べてください
「4つのブロックが答えです。カードが必要な人は『さらに詳しく』から選べます」	実際に計測したところ、そうはなりませんでした。ユーザーは「カードとあなたの選択を、もっと簡単に説明して」と入力し、その後、「持ち帰り」以外の詳細項目をすべて飛ばしていました
「カードは自分向けです。わからなければユーザーが質問するでしょう」	実際に質問があり、ユーザーが求めていたのは、すでに持っているカードからプロトコルを取り除いたものでした。追加質問が必要なカードは、唯一の役割を果たせていません
「Gist／Lock strip／Fenceは、定義すれば十分に明確です」	それらはこのスキルのプロトコルです。カードに載せると、ユーザーは自分の判断を読めるようになる前に、別の用語体系を学ばなければなりません。見出しは併記する言語での質問にしてください
「長く残すメモは判断記録になるでしょうし、このスキルは何も書き込みません」	モデルメモとは、周辺領域の図に、ユーザーがすでに決めたロックの写しを添えたものです。次のセッションで同じ4つの枠を作り直さずに済みます。既定では無効にし、一度だけ提案してください。ユーザーがパスを指定しない限り、製品リポジトリには手を加えません
「Todayの前に一行のたとえを置けば、理解の確認になります」	それは飾りでした。ユーザーが行動に移せる図は、部分を対応づけ、モデルの限界を示し、1人の人を通して説明していました
「前のセッションで持ち帰りを5番にしたので、今回もそうするべきです」	再開時も含め、毎回、持ち帰りは 0 です
「Walk／Challenge／Stressは最初のメニューに引き続き必要です」	2段階です。種類のメニューは一度も選ばれていません。第1段階は技術概要、第2段階はファイルと行をたどる確認です

要注意事項

• リポジトリ内に存在するファイルを開かずに、その内容について意見を述べる
• コミット履歴を一度も読まずに、定数、境界値、デフォルト値について立場を示す
• 前のターンから行が変わっている比較、または貼り付けられた選択肢をそのまま言い直す比較
• 分析を「決めるのはあなたです」で締めくくる、または形を選ぶ行が並んだメニューで締めくくる
• セッションのテーマを述べる前に、コードやたとえ話から始める最初の回答
• 選択中のターンで、分岐を示す前に「今日」や一行のたとえ話、Architect の見解から始める
• 選択中のターンで、最初の2つの見出しが分岐と推奨案になっていない、またはその前に全体像や最終的な選択を示す
• カード上の見出しに Gist、Lock strip、Fence、Hop、Stance、Invariant、Locality、Depth、Carry-back と表示する
• 対応する言語が英語でないのに、ユーザー向けの見出しやメニュー項目を英語のままにする
• セッションで最初の選択中ターンなのに4行の読み方ガイドがない、または後続のターンでそれを繰り返す
• 貼り付け内容とリポジトリの食い違いを、事実を承認事項であるかのように 0 が固定する内容の下に記載する。または、貼り付け内容とコードの食い違いに関する見出しの下に「なし」と記載する
• 求められていないのに .skills/interpret-session/ または docs/ に書き込む、あるいはメモに foundation-cards.md、CONTEXT.md、ADR という名前を付ける
• 選択中のターンに部品と接続の図がない、または図が用語集になっている
• 「さらに掘り下げる」メニューを付けずに選択中のターンを終える、またはメニューの順序が「2段階先へ進む、その後 0」になっていない
• 「さらに掘り下げる」メニューで、持ち帰り項目の番号を 0 以外にする、または「もう一度説明」「順を追って説明」「影響」「検証」、あるいは「順を追う」「異議を唱える」「負荷をかける」「検証」を使う
• ユーザーが方向性を決めていないターンで、持ち帰り項目を作成する
• 持ち帰り項目にこのセッションの名前を記載する、または決定事項に対して制約が多すぎるのに「固定／検討」の区分がない、あるいは異議を示さずに方針変更後の内容を書く
• セッションでユーザーに概念のモデルを提示していないのに、その概念について専門家レベルの議論をする
• 評価するための列が用意されていない、より良い形を推奨案に記載する
• すでに製品に実装されている機能についての分岐で、どの製品のことも挙げずに形を回答する
• 図を約束する見出しの下に、何も描写していない段落を置く

完了条件: 選択中のターンでは、ユーザーが専門用語を使わず、先の手順にも進まずに、分岐、4〜7個の部品からなる全体像、選択内容を3文で言い直せること、そしてこのカードが決定しないことを把握していること。カードの最初の2つの見出しで、すでに選択肢を分け、推奨案を示していること。方向性が決まったら、持ち帰り項目で固定するのは決定した内容だけにすること。求められた場合のモデルメモは、全体像と固定済みの内容を転記したものであり、仕様書ではないこと。それ以外の場合は、未解決の質問を明示し、要点を引き継ぐこと。