figure-it-out について
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 原則スキル）。
- 並行して進める作業を決めます。境界が明確な作業だけを並行化し、各作業者にはそれぞれ専用のワークツリーまたはブランチを割り当てます（separate-before-serializing-shared-state 原則スキル）。並行化しすぎないでください。
- 設計したフェーズの一覧を書き留めます。人がレビューするのはこの一覧です。
次に、設計を実行します。その手順を具体的な項目として、TODO リストのフェーズCの項目の後、フェーズDの前に追加します。それぞれをフェーズCのループ規律に従って実行し、フェーズDのログも各手順の完了に合わせて記録します。最後にまとめて記録してはいけません。
フェーズC：ループを回す
各単位は実験です。仮説を立て、最小限の変更を加え、実際の成果物を使って述語に照らして測定します。前進につながった場合は変更を維持し、そうでなければ元に戻します。 sequence-verifiable-units 原則スキルを適用し、最後にまとめてチェックするのではなく、次に進む前に各単位を検証します。
- 自己申告ではなく、成果物を調べて検証します。あまりにも簡単に合格した場合は、システムより先に観測方法を疑います。
- 委任した作業には判定者を付けます。作業者がゲートを悪用した場合は、リセットして契約を強化します。ゲート自体に問題がある場合は、迂回するのではなく、独立した変更でゲートを修正します。
- 判定結果は VERIFIED、NOT VERIFIED、または INCONCLUSIVE のいずれかです。INCONCLUSIVE は合格ではありません。否定的な結果を隠してはいけません。
フェーズD：監査の記録を残す
show-me-your-work スキルを使って、実行記録を残します。figure-it-out の作業は通常、レビュー担当者が PR で読めるように記録もコミットするだけの重要性があります。記録と差分があれば、人は作業に戻ったときに、その成果を信頼できます。
フェーズE：検証して引き渡す
テストハーネスだけでなく、実際のプロダクトを使い、フェーズAの述語に照らして全体を確認します。繰り返し発生する修正は、ゲート、lint ルール、チェック、またはスクリプトとして仕組みに組み込みます（encode-lessons-in-structure 原則スキル）。
返信： 設計したプレイブック、厳密さのレベルとその理由、判断の記録のパス、述語に照らして検証済みの事項、未解決の事項を示します。