are-decisions-from-this-session-saved

このセッションでの決定事項は保存されていますか？

セッションの終わりに、ひとつ問いかけます。ここで切り上げた場合、このシステムの計画に関して失われるものはありますか？ 構築する対象についてセッションで決まったことは、誰かがどこかに書き留めるまではトランスクリプトにしか存在せず、次のセッションではトランスクリプトを読みません。このスキルはそうした決定事項を見つけ、それぞれに適した場所に記録されているかを確認し、抜けを埋めます。記録するか、人間が声に出して記録しないと決めるか、いずれかです。そして最後に、問いに率直に答えます。設計について再び決め直す必要は何もありません。セッションを終了できます——あるいは、まだそうでないなら、何を決める必要があるかを正確に示します。

対象はシステムであり、セッションではありません。 ここで作業をどう進めたか——どのスキルを呼び出したか、人間がどのように進めるよう求めたか、作業の途中で何を指摘されたか——は計画ではないため、対象外です。対象外の項目を参照してください。こうした情報を持ち出すと、本当に重要な2つの決定事項が、重要でない10項目に埋もれてしまいます。

情報源はセッションであり、トラッカーではありません。 ほかの計画スキルはすべてイシューから始めて、そこから掘り下げます。このスキルは、ここで決まったことから始め、それが何かに反映されたかを確認します。この会話にしか存在しない決定事項は、実際には決まらなかったも同然です。

人間の確認なしに記録したり、破棄したりすることはありません。 すべての項目は、人間が指定した場所に記録するか、人間がそう指示したために記録しないかのどちらかです。だからこそ、セッションの終わりに事前確認なしでこのスキルを呼び出しても安全です。スキルが提案し、人間がひとつずつ判断します。

対象となるもの

判定基準：この会話を見ていない人が、システムの計画や構築を異なる方法で進めるでしょうか？ そうであれば対象です。以下はすべて、この問いから導かれます。

• マップやチケットで未解決だった問いへの回答
• システムの構造、振る舞い、契約に関する選択——*「Xを試したが、Xは採用しない」*という決定も含みます
• 作業の途中で判明した制約や境界——「これはYより前には反映できない」
• スコープに関する判断——この取り組みに含める、または含めないと決めたこと

また、対象外となるもの： 仕様書にすでに書かれている内容の言い換え、差分を見れば明らかなこと、検討したものの未解決のままにした問いです。未解決の問いはこのスキルが扱う対象ではありませんが、破棄してはいけません。人間がチケットにするか、未解決のままにするかを判断できるよう、報告で提示してください。

対象外の項目

セッションの進め方。 それは決定事項のように思え、しばしば強く明言されますが、上記の判定基準には当てはまりません。このシステムの計画を立てる人が、そうした情報に左右されることはありません。

• どのスキルやツールをどの順番で使い、何を指示したか
• 人間がどのように進めるよう求めたか——一度にひとつの質問だけにする、サブエージェントを使わない、書き込む前に確認する
• 作業の進め方、表現、プロセスに関する指摘
• タスクを実行するために行った手順、およびこのリポジトリのチェックアウトの仕組みに関すること

セッションを越えて引き継ぐべき作業スタイルには、すでに適切な保存先があります。AGENTS.md、ルール、マップのNotes、ハーネス独自のメモリなどです。そこに記録するのは、人間が始める別の作業です。確認中に人間がそうした情報を持ち出した場合は、指定された場所に記録して続けてください。自分から持ち出したり、項目数を増やすためにリストへ加えたりしてはいけません。

プロセス

1. このセッションでシステムについて決まったことを洗い出す

覚えている内容だけでなく、セッションの最初から読み直してください。対象となるものの判定基準に照らして、候補を見つけるそばからひとつずつ確認してください。作業スタイルに関する項目が残ったリストを人間に渡すようでは、すでに失敗です。今度は人間が仕分けをしなければならないからです。基準を満たした候補だけを、自分の言葉で1行ずつ書き出し、それぞれの元になったやり取りも記してください。古いものから順に並べます。

すでに記録したと思う決定事項も含めてください。手順2で記録先と照合します。書き留めるつもりだった決定事項も、実際に書き留めた決定事項も、セッションの内部からは同じように見えるからです。

完了条件： 各項目がシステムの計画や構築の進め方を変える、番号付きのリストができていること。

2. すでに記録されているはずの場所をそれぞれ確認する

実際に確認してください。自分が書いた記憶だけを頼りにしないでください。

• 決定チケット — 解決コメントが記載されていて、クローズされていますか？
• マップ — Decisions so far、Not yet specified、Out of scope、Notes
• 決定が反映されているはずの仕様ファイル
• 作業中に行った判断の場合は、実装チケットまたは PR

候補ごとに、証拠となるリンクを添えて記録済み、このセッション中の後のやり取りで上書きされた内容がその場所に残っている場合は古い情報、それ以外は未記録と印を付けてください。

**完了条件：**すべての候補に、3 つの印のいずれかが付いていること。

3. 人間と一緒に、ギャップを一つずつ埋める

未記録または古い情報の候補について、それぞれ 1 つの AskUserQuestion で質問してください。質問には、あなたが理解している決定内容と、記録先の提案を含めます。選択肢を並べるのではなく、記録先を提案してください — 通常は決定の記録先で判断できます。この質問は、人間があなたの理解を修正したり、記録先を変更したり、その決定を取り消したりできるようにするためのものです。

すべての質問に、選択肢として**「忘れてください」**を含めてください。1 つの質問につき決定は 1 つだけにしてください。文章でまとめて質問すると、回答されないままの項目が紛れやすくなります。

**完了条件：**人間が、対象の候補について記録先を指定するか、忘れるよう指示していること。

4. 指示された場所に記録する

独自の形式を使わず、担当スキルの規約に従って記録してください — マップと決定チケットの形式は /wayfinder が担当し、仕様は /decisions-to-specs が担当します。担当スキルが分からない場合は確認してください。このスキルには、それらの形式の複製を意図的に置いていません。

/decisions-to-specs は人間のみが実行するため、仕様に関する決定はここでは確定しません。現時点での記録はトラッカー、つまり解決コメントとマップの行です。これはパイプラインが、後で仕様に引き継ぐために想定している形式そのものです。未完了の仕様作業はレポートに記載し、そのまま残してください。

**完了条件：**記録先に決定が示されていて、そのリンクを取得していること。

5. リストが空になるまで繰り返す

次の候補に進み、ステップ 3 に戻ってください。スイープを終えるのは、すべての項目が記録済み、または承認を得て忘れられたときです。リストが長くなったときでも、セッションのコンテキストが尽きそうなときでもありません。

リストが空になる前に作業する余裕がなくなった場合は、その旨を明確に伝え、未解決の項目を決定ごとに列挙してください。未完了だと報告されたスイープは後から再開できます。何も言わずに止めるのは、最初から実行しないよりも悪いことです。

**完了条件：**印の付いていない候補が残っていないこと。

6. 報告する

決定ごとに 1 行で、内容、記録先、リンクを記載し、忘れられた項目は最後にまとめてください。パイプラインに残っている作業で締めくくります。/decisions-to-specs を待っている決定、/specs-to-tickets を待っている仕様、人間がチケット化したい可能性のある質問を記載してください。

**完了条件：**インベントリのすべての項目がレポートに記載されていること。

7. 質問に答える

このスキルは、この問いに答えるためにあります。人間自身の言葉で、声に出して答えてください。

このセッションを今終了したら、システムの設計について何かをもう一度決める必要がありますか？

すべての項目が、記録先で確認済み — リンクがあり、実際に確認している — または人間の承認を得て忘れられている場合に限り、答えはいいえです。その場合は、曖昧さを残さず、はっきりと伝えてください。

いいえ。設計について、もう一度決める必要はありません。セッションを終了できます。

まだ「いいえ」と答えられない場合は、何を再度決める必要があるのか、名前を挙げて伝え、ステップ 3 に戻ってください。小さなギャップであっても、未回答の項目があれば答えははいです。

**完了条件：**人間に、明確な「はい」または「いいえ」を伝えます。「はい」の場合は、二度決めることになる項目の一覧も伝えてください。

回答には根拠が必要です

きれいに締めくくりたいという気持ちはありますが、ここは迎合すると実害が生じる唯一の箇所です。誤って「見落としはありません」と伝えるくらいなら、確認をしないほうがましです。人はそこで探すのをやめてしまいます。

• 「記録済み」とは、表面を確認して、決定内容が記載されていることを確かめたという意味です。 コメントを投稿して、反映されたと思い込んでいるだけではありません。
• 忘れられた項目は、否定の判断に含めません。 意図的に削除されたものであり、決定が失われたのではなく、そのまま維持されたということです。
• 作業スタイルによって、肯定の判断にはなりません。 もともと対象範囲に含まれていなかったため、失われることもありません。対象範囲に含まれないものを参照してください。
• 本当に否定なら、曖昧にしないでください。 「いいえ。ただし、こうするとよいかもしれません……」は、可能性があるように聞こえ、存在しない問題を探させてしまいます。追加の提案は、回答の前にあるステップ 6 の報告に記載してください。
• 肯定の場合も、ぼかさないでください。 決定が 1 つでも未記録なら、それは肯定です。どの決定なのかを伝えてください。

決定の記録場所

決定の内容…	記録場所
今回のセッションで対応するとしたチケットへの回答	そのチケットの解決コメント。チケットをクローズし、マップにも記載します
確定したが、どのチケットにも属さない	チケットを作成し、回答を記載してクローズします。マップにはクローズ済みチケットが索引されるため、チケットがなければ決定の索引先がありません
作業を取り組みに含める、または除外する	マップのスコープセクション。対象外にしたチケットがあれば、それもクローズします
何を構築するかを永続的に示す	現時点ではトラッカーに記録します。後で /decisions-to-specs が仕様に反映します
構築中に、実装について決定した	実装チケットまたはその PR。契約に変更を加えた場合は、仕様にも記録します
回答ではなく、質問だと判明した	このスキルで記録する対象ではありません。明確な質問ならチケットにし、そうでなければ曖昧なままにします

忘れるのはかまいません。黙って削除するのはだめです

人が「重要ではない」「別の決定に置き換わった」「行き詰まった」と判断して退けた決定は、失われてもかまいません。守るべきルールは、本人がそう言ったということだけです。忘れられた決定は、どこにも痕跡を残しません。今回のセッションの報告に記載され、それ以外の場所には残りません。意図的に削除したものを書き留めても、散らかりを別の場所に移すだけだからです。

このスキルが決してしないのは、対象範囲内の何かを残す価値がないと、本人に代わって判断することです。本当の決定をささいなことだと判断するのは、このスキルが防ごうとしている失敗です。一方、これはシステムに関係のないものまで持ち込む理由にはなりません。

フローの中での位置づけ

フローと並行して、システムに関する何かを決定したセッションの最後に使います。たとえば、/wayfinder のチケット、判断を伴った /implement の実行、方向性を変えた厳しい議論などです。skill-callable なので、締めくくりや引き継ぎのフローから連携できます。

/wayfinder は進行中に記録します。このスキルは記録されたことを確認し、チケット自体の解決時以外に行われたすべての決定を漏れなく補います。