figure-it-out

方針を見つける

タスクに合うプレイブックがない場合は、作成してください。コードを書く前に成果物として用意するのは、タスクの規模に応じて厳密さを調整し、科学的手法に沿って進め、担当者が離れた後でも人間が監査できる意思決定の記録を残す、一連のフェーズからなるワークフローです。

開始

最初の項目をpoteto-modeスキルのPrinciplesセクションを読むこととして、作業リストを開きます。その後、以下のフェーズを項目として追加します。

フェーズ A：枠組みを定める

まず根拠を集め、それから決定します。次のことを明確に述べられるまでは、実行を開始しないでください。

• 完了の定義を、反証可能な述語として示します（prove-it-works原則スキル）。
• 要求された各項目について、プロジェクトの設計とユーザーの目標に結び付けた簡潔な理由を添えて、「実施する」または「実施しない」と判断します。規模を見積もる前に判断してください。適合性の判断によって、明示された要件が取り消されることはありません。除外案と、承認されたスコープ変更は別々に記録します。
• 承認された項目のスコープを定量化します。実装、テスト、ドキュメント、生成ファイル、検証作業を含め、比較する選択肢は同じ基準で見積もります。除外事項と不確実性を挙げ、明らかになった根拠に基づく障害要因も記録します。
• 厳密さのレベルを、厳しめに設定します。一方通行の判断や影響範囲の大きい作業には、より高い厳密さを適用します。容易に取り消せる低リスクの手順には、それより低い厳密さを適用します。厳密さとはゲートと成果物であり、「もっと努力する」ことではありません。

実際のスコープと作業量を見積もりと照らして追跡します。選択した案が却下した案の比較可能な見積もりを上回った場合は、選択を再評価し、超過分を報告します。自律実行の許可がある場合は、既存のゲートでオペレーターの対応が必要とされない限り、その許可の範囲内で続行します。

長時間の作業に着手する前に、枠組みとトレードオフを提示します。取り消し可能な作業は進めます（never-block-on-the-human原則スキル）。ただし、数時間にわたる作業にはチェックポイントを1回設けます。

フェーズ B：ワークフローを設計する

独立して実施・統合できる単位に分解します。リスクが高く、不確実性の大きい項目から着手する順序にします。機能より先に、足場作りと検証を行います（foundational-thinking原則スキル）。

• 作業を始める前に検証ハーネスを構築し、変更前の状態をベースラインとして取得します。これにより、チェック結果が「旧値と新値の比較」として読み取れるようにします。
• 一方通行の設計判断にはarchitectスキルを使います（このスキルはarenaを実行します）。機械的な作業で、すでに具体的な形が決まっている場合は省略します。設計が確定した後に2回目のarenaを行うのは、過剰設計です（laziness-protocol原則スキル）。
• 並列化する作業を決めます。境界が明確な作業に限って並列化し、各作業者にはそれぞれ専用のworktreeまたはブランチを割り当てます（separate-before-serializing-shared-state原則スキル）。並列化しすぎないでください。
• 設計したフェーズのリストを書き出します。人間がレビューするのはこのリストです。

その後、設計に沿って実行します。手順を具体的な作業項目として、フェーズ Cとフェーズ Dの項目の間に作業リストへ追加します。それぞれをフェーズ Cのループ規律に従って実施し、手順が完了するたびに記録を1行追加して、フェーズ Dのログを作業と並行して更新します。最後にまとめて記録することはしません。

フェーズ C：ループを実行する

各ユニットは実験です。仮説を立て、最小限の変更を加え、実際の成果物に対して述語を基準に測定します。前進した場合は維持し、そうでなければ元に戻します。 principle-sequence-verifiable-units スキルを使用してください。確認を最後にまとめて行うのではなく、次のユニットを始める前に各ユニットを検証してください。

• 自己申告ではなく、成果物を調べて検証してください。あまりにも簡単に通る場合は、システムではなく観察方法を疑ってください。
• 委任した作業には判定役を付けてください。作業者がゲートをすり抜けた場合は、リセットして契約を強化してください。ゲート自体に問題がある場合は、迂回するのではなく、独立した変更としてゲートを修正してください。
• 回帰テストを新たに追加するたびに、そのテストが保護する動作と、修正前に該当する不具合で失敗し、修正後に通過することを示す証拠を報告してください。親リビジョン、安全な対象限定のミューテーション、または失敗するフィクスチャで、不具合を再現できます。ミューテーションは使い捨てのチェックアウト内にとどめてください。セットアップやコンパイルの失敗は、意図した動作が失敗した証拠にはなりません。複数のテストをカバーできる場合は、1回の実行を再利用してください。その他の新しいテストについては、独立したオラクルと、そのテストが排除する妥当な不具合を記載してください。失敗する実行が危険、または実行できない場合は、回帰の証明を主張するのではなく、その不足を記録してください。
• 判定は VERIFIED、NOT VERIFIED、または INCONCLUSIVE です。INCONCLUSIVE は合格ではありません。否定的な結果を隠さないでください。

フェーズ D：監査証跡を残す

実行内容を記録するには、show-me-your-work スキルを使用してください。証跡をローカルに残すかコミットするかは、そのスキルの判断に委ねてください。完了を裏付ける永続的な証拠をレビュー担当者が確認できるようにしてください。

フェーズ E：検証して引き渡す

ハーネスだけでなく、実際の製品に対して、フェーズ A の述語に基づいて全体を確認してください。繰り返し発生する修正は、ゲート、リンタールール、チェック、またはスクリプトとして組み込んでください（encode-lessons-in-structure 原則スキル）。

引き渡しの前に、未解決の重大な不具合や満たされていない要件を、既存のトラッカー項目またはチェックイン済みの既知の問題ファイルに関連付けてください。許可されている場合は、不足している記録を作成してください。既知の場合は、影響、証拠、現在の対応状況、担当者を記載してください。ブロッカーを登録しても、完了の述語を満たしたことにはなりません。登録できない、または許可されていない場合は、その不足と、記録を保持した場所を明示してください。

返信： 設計したプレイブック、厳密さのレベルとその理由、意思決定の証跡のパス、述語に照らして検証済みの内容、未解決の内容。