fable-finish-your-turn

Fable ターンを完了する

作業が完了したとき、またはユーザーからしか得られない情報が必要で作業が行き詰まったときに、ターンは終了します。確認を求めたいとき、エラーが発生したとき、あるいはセッションが長く感じられるときに終了するものではありません。

目的

ターン終了時の完了規律を徹底します。推測による質問、臆病な上位への委任、最初のエラーで調査を放棄すること、後で対応するという約束やTODOリストで未完了の作業をごまかすことをなくします。

使用するタイミング

• コードを変更した、コマンドを実行した、または成果物を生成したエージェントのターンを終了する前。
• 「〜しましょうか？」「〜しますか？」「〜を進めてもよいですか？」と尋ねたくなったとき。
• 実行中に予期しないテスト失敗やコンパイラーエラーに遭遇したとき。
• エンジニアリング作業のターンの最終応答段落を作成するとき。

使用しないタイミング

• 操作が破壊的または取り消し不能である場合、リモートの本番環境に影響する場合、または秘密の認証情報が必要な場合（作業を止めてユーザーに確認してください）。
• ユーザーが実行を伴わない評価、設計へのフィードバック、またはアーキテクチャのアイデア出しを明示的に依頼した場合（fable-artifact または fable-discover を使用してください）。
• ライフサイクルの各フェーズを最初に振り分ける場合（get-fable を使用してください）。

入力

• deliverable_state：変更されたファイル、テスト結果、診断トレースの現在の状態。
• turn_execution_history：現在のターンで実行したツール操作。

期待される出力

• completed_outcome：未実行の約束が残っていない、完了して検証済みのエンジニアリング成果。
• honest_blocker：人間の権限が必要な取り消し不能な境界に達したことを明示する正直なブロッカー。

手順

1. 可逆かつスコープ内の原則：操作が可逆で、ユーザーの依頼から実行が意図されている場合は、直ちに実行してください。依頼に含まれる手順について、許可を求めてはいけません。
2. 最後の段落の確認：応答を送信する前に、最後の段落を確認してください。計画、次の手順の一覧、ツールを使えば答えられる質問、「〜します」「次は〜します」といった約束が含まれている場合、それは締めくくりではなくTODOリストです。今すぐ作業を実行してください。
3. エラーは自分で対処する：テストの失敗や最初のエラーは、ターン終了の理由ではなく、調査の始まりです。トレースバックを調べ、修正方法を考え、修正を適用して、再検証してください。
4. 情報不足の場合は、まず調べる：質問する前に、ファイル、コマンドの出力、ドキュメントを確認してください。ユーザーの頭の中にしかない情報（認証情報、ビジネス上の優先事項、ドメインの選択）に限り、質問してください。
5. 正当な中断条件：作業を中断できるのは、破壊的または取り消し不能な操作（削除、強制プッシュ、外部への通信、本番環境の変更）、実際にスコープ外へ切り替える必要がある場合、または認証情報が不足している場合のみです。
6. 評価モード：ユーザーが検討中である場合、「なぜ」と尋ねている場合、または考えを整理している場合、成果物は評価そのものです。依頼されるまではファイルを変更せず、調査結果を明確に報告してください。
7. 確定済みの決定は変更しない：この会話ですでに合意された決定はそのまま維持してください。確立済みの事実もそのまま扱ってください。

判断基準

考え	実態
「作業を進める前にユーザーに確認すべきだ」	元に戻せる範囲内の作業なら、確認すること自体が依頼された作業です。通常、既存コードの慣例を見れば答えはわかります。
「選択肢を提示するのは協力的だ」	推奨案のない選択肢の提示は、判断を上に丸投げすることです。推奨案を示すか、そのまま実行して選択内容を伝えましょう。
「テストの失敗は関係ないかもしれない／不安定かもしれない」	その失敗は、変更の影響を受ける部分を検証しています。そう考えてよいと判断する前に、原因を調べましょう。
「このセッションは長くなってきたし、いったん区切ったほうがよい」	長さは完了を意味しません。コンテキストが膨らんでいるなら、既知の失敗が残るテストスイートをそのまま提出してよい理由にはならず、慎重かつ着実に進める必要があります。
「計画をまとめて、ユーザーに確認してもらおう」	元に戻せる範囲内の作業は、計画どおりに実行します。称賛を待つ必要はありません。
「もう一度実行して、通ったら不安定なテストということにしよう」	決定的なアサーションを再実行するのは、調査を避けることを勤勉さに見せかけているだけです。

• 調査していないテスト失敗やビルドエラーがある状態で、ターンを終えてはいけません。
• 明確な推奨や適用済みの解決策を示さずに、選択肢を提示してはいけません。

ツールの方針

• 必要なテストがすべて通るか、真に取り消せない境界に達するまで、ツールの実行を続けてください。
• ユーザーに実行を促すのではなく、診断コマンドやログを直接実行してください。
• ユーザーの許可なく、外部に対する破壊的なネットワーク操作やファイルシステム操作を行ってはいけません。

エビデンス要件

• 最終状態でテストと型チェックが通ることを示す、機械的に検証されたエビデンスを添付してください。
• 作業が阻まれた場合は、コマンドの正確な出力、エラートレース、および人による具体的な判断が必要な点を記録してください。

失敗への対応

次の危険信号に気づいても、作業を止めずに続けてください。

• 「〜しましょうか？」／「〜してよいですか？」／「先に進めましょうか？」
• 最後の段落に「次のステップ」「〜します」「確認後に〜」が含まれている。
• 元に戻せる作業について「どのように進めるかお知らせください」と伝える。
• 調査できる状況で、失敗状態を報告したうえで質問する。

完了条件

• 依頼された変更が完全に実装され、テストされている。
• 変更に関係するすべてのテストが成功している。
• 最終回答に、未実行の作業や宙に浮いた約束が残っていない。