figure-it-out について
既存のプレイブックが適合しない場合に、ワークフローを設計するスキルです。作業を検証可能な段階に分け、リスクの高い未知事項を優先し、完了まで監査可能な判断記録を残します。
主な機能
- 01反証可能な完了条件の定義
- 02範囲の設定と厳密さの調整
- 03独立したワークフロー段階の設計
- 04実際の成果物による各単位の検証
- 05監査可能な判断記録の維持
活用シーン
- 01対応する既存手順がない作業の計画
- 02大規模タスクを検証可能な単位に分割
- 03実装前に高リスクの未知事項を優先
- 04後日のレビューに向けた判断記録
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/figure-it-outを入力して読み込まれたか確認します。
詳細
見極める
タスクに該当するプレイブックがない場合は、作成してください。コードを書く前に用意する成果物は、ワークフローそのものです。タスクに応じて厳密さを調整し、科学的手法に沿って進め、人が作業から離れたあとでも監査できる判断の記録を残す、一連のフェーズを設計します。
開始
最初の項目に poteto-mode スキルの「Principles」セクションを読むことを含む、todo リストを作成します。その後、以下のフェーズを todo として追加します。
フェーズ A：枠組みを定める
まず根拠を固め、それから確約します。以下を明確に述べられるまで、実行を開始しないでください。
- 反証可能な述語として定義した完了条件（prove-it-works 原則スキル）。
- 定量化したスコープ：おおよその単位数と作業量に加え、根拠を固める過程で明らかになったブロッカー。
- 厳密さのレベル。高めに設定します。一方通行の決定や影響範囲の大きい変更には、より厳密な対応をします。取り消し可能でリスクの低い手順には、厳密さを抑えます。厳密さとはゲートと成果物であり、「もっと頑張る」ことではありません。
長時間の作業に着手する前に、枠組みとトレードオフを提示します。取り消し可能な作業は進めます（never-block-on-the-human 原則スキル）が、数時間に及ぶ作業ではチェックポイントを1回設けます。
フェーズ B：ワークフローを設計する
独立して実施・確定できる最小単位に分解します。リスクの高い未知事項から着手します。機能開発より先に、足場づくりと検証を行います（foundational-thinking 原則スキル）。
- 作業を始める前に検証ハーネスを構築し、変更前の状態をベースラインとして記録します。これにより、検証結果を「旧値と新値」の比較として読み取れるようにします。
- 一方通行の設計判断では、architect スキルを実行します（このスキルは arena を実行します）。形がすでに具体的な機械的作業では省略します。設計が固まった後にもう一度 arena を実施するのは、過剰設計です（laziness-protocol 原則スキル）。
- 何を並行して進めるかを決めます。並列化は作業の境界ごとに限り、各ワーカーには専用の worktree またはブランチを割り当てます（separate-before-serializing-shared-state 原則スキル）。並列化しすぎないでください。poteto-mode スキルの「Subagents」セクションに従い、各サブエージェントの推論レベルと、作業に適した速度（fast または standard）を選びます。
- 設計したフェーズの一覧を書き出します。人がレビューするのはこの一覧です。
その後、設計に沿って実行します。フェーズ C とフェーズ D の項目の間に、設計した手順を具体的な項目として todo リストに追加します。各手順はフェーズ C のループ規律に沿って実行し、フェーズ D のログは最後にまとめて残すのではなく、手順が完了するたびに1行ずつ記録しながら進めます。
フェーズ C：ループを回す
各単位を実験として扱います。仮説を立て、最小限の変更を加え、実際の成果物で述語に照らして測定します。前進が確認できたら採用し、前進しなければ元に戻します。確認を最後にまとめて行うのではなく、次の単位に進む前に各単位を検証する sequence-verifiable-units 原則スキルを適用します。
- 自己申告ではなく、成果物を調べて検証します。あまりにも簡単に通過した場合は、システムではなく観測方法を疑ってください。
- 委任した作業には判定者を付けます。ワーカーがゲートをすり抜けた場合は、リセットして契約を強化します。ゲート自体が誤っている場合は、回避策を講じず、独立した変更としてゲートを修正します。
- 判定は VERIFIED、NOT VERIFIED、または INCONCLUSIVE のいずれかです。INCONCLUSIVE は合格ではありません。否定的な結果を隠さないでください。
フェーズ D：監査記録を残す
show-me-your-work スキルを使って、作業の記録を残します。figure-it-out の作業はたいてい十分に大規模なため、レビュー担当者がプルリクエストで読めるよう、記録をコミットします。記録と差分がそろっていることで、人は作業に戻ったときにその成果を信頼できます。
フェーズ E：検証して引き継ぐ
ハーネスだけでなく、実際のプロダクト全体をフェーズ A の述語に照らして確認します。繰り返し発生する修正は、ゲート、lint ルール、チェック、またはスクリプトとして組み込みます（encode-lessons-in-structure 原則スキル）。
返信： 設計したプレイブック、厳密さのレベルとその理由、判断記録のパス、述語に照らして検証済みの内容、未解決の事項。