figure-it-out

見極める

タスクに適合するプレイブックがない場合は、作成します。コードを書く前に仕上げるものは、ワークフローそのものです。タスクに応じて厳密さを調整し、科学的手法に従い、人が席を外した後でも監査できる判断の記録を残すフェーズの順序を定めます。厳密さは高めに設定してください。誤ったものを作るコストは、慎重に進めるコストを大きく上回ります。

すでにあるプレイブックを一から作り直さないでください。Bug fix、Perf、Feature、Visual parity、Eval、Multi-phase plan のいずれかに該当する、対象を絞った単一ユニットのタスクは、そちらに進めます。ただし、それらの大規模版や複数の領域にまたがる作業（多数の呼び出し箇所にまたがる移行や、意欲的な複数部分からなる変更など）、あるいは人が席を外した後にレビューする作業は、単一ユニットなら Feature に該当するものであっても、ここで扱います。重要なのは、厳密さと監査の記録です。

開始

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

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

まず根拠を集め、その後で着手します。次のことを明確に説明できるまでは、作業を開始しないでください。

• 偽であることを検証できる完了条件（prove-it-works principle skill）。「うまく完了した」ことを確認可能にする必要があります。
• 定量化したスコープ：おおよそのユニット数と工数、根拠集めで明らかになった阻害要因。何時間も費やした後、失敗するコミットを50回積み上げた後ではなく、作業に多くの時間を費やす前に提示します。
• 厳密さのレベル。高めに設定してください。後戻りできない判断や影響範囲が大きい作業には、より高い厳密さを適用します。やり直し可能でリスクの低い段階には、それより低くします。厳密さとはゲートと成果物のことであり、「もっと努力する」ことではありません。

長時間の作業に着手する前に、枠組みとトレードオフを提示します。やり直し可能な作業は進めます（never-block-on-the-human principle skill）。ただし、数時間に及ぶ作業には、途中で1回確認ポイントを設けます。

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

作業を、個別に着手して完了できる原子的な単位に分解します。選択肢を最大限残せるよう、未知のリスクが最も高いものから順に進めます。機能より先に、足場と検証手段を整えます（foundational-thinking principle skill）。

• 作業を始める前に検証ハーネスを構築し、変更前の状態をベースラインとして記録します。これにより、検証で「旧値と新値」を比較できます。
• 後戻りできない設計判断には、architect スキル（arena を実行します）を使います。異なる視点を持ち、互いに隔離された、独自の意見を持つ候補と、異なるモデルファミリーを使う読み取り専用の判定役を用意します。形がすでに具体化されている機械的な作業には使いません。設計が確定した後にもう一度 arena を実行するのは、過剰な設計です（laziness-protocol principle skill）。
• 並列化する範囲を決めます。実際に分離できる作業の境界をまたぐ場合にのみ並列化し、各作業者にはそれぞれ専用の worktree またはブランチを割り当てます（separate-before-serializing-shared-state principle skill）。並列化しすぎないでください。
• 設計したフェーズの一覧を書き残します。人がレビューするのは、この一覧です。

次に、設計を実行に移します。フェーズ C の項目の後、フェーズ D の項目の前に、設計した各段階を具体的な項目として todo リストに追加します。各段階は、フェーズ C のループに関する規律に従って進めます。また、フェーズ D のログは作業全体が終わるまで保留せず、各段階が完了するたびに1行ずつ記録しながら、作業に組み込んでいきます。

フェーズ C：ループを回す

各ユニットを実験として扱います。仮説を立て、最小限の変更を加え、実際の成果物に対して完了条件を基準に測定し、前進したなら採用し、そうでなければ元に戻します。 sequence-verifiable-units principle skill を適用し、最後にまとめて検証するのではなく、各ユニットを検証してから次に進みます。

• 自己申告ではなく、成果物を確認して検証します。あまりにも簡単に合格した場合は、システムではなく観測方法に問題がないか疑ってください。空白のスクリーンショットでも、甘いゲートなら合格してしまいます。
• 作業を委任した場合は、判定役を組み合わせ、信頼する前に委任先の成果物を自分で監査します。作業者がゲートをすり抜けた場合は、リセットして契約を厳格化します。ゲート自体が誤っている場合は、回避策を探すのではなく、独立した変更としてゲートを修正します。
• 判定は VERIFIED、NOT VERIFIED、または INCONCLUSIVE とします。INCONCLUSIVE は合格ではありません。否定的な結果を隠さないでください。

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

show-me-your-work スキルを使って実行内容を記録します。意思決定と単位ごとに 1 行を記載した正規の TSV を 1 つ作成し、証拠はリンクで示します。figure-it-out の作業は通常、レビュー担当者が PR で証跡を確認できるよう、記録をコミットする価値があるほど意欲的なものです。信頼性を示す必要がある場合は、記録をコミットしてください。レビュー担当者が再実行できるよう、コミット済みスクリプトで生成した証拠を優先してください。記録と差分がそろうことで、人が後から作業を確認し、信頼できるようになります。

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

ハーネスだけでなく、実際の製品でフェーズ A の判定条件に照らして全体を確認します。繰り返し発生する修正は、ゲート、リンタールール、チェック、またはスクリプトとして組み込み、成果が気付かないうちに後退しないようにします（encode-lessons-in-structure 原則スキル）。

返信内容： 設計したプレイブック、厳密さのレベルとその理由、意思決定記録のパス、判定条件に照らして検証した内容、未解決の事項。