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