figure-it-out について
figure-it-out は、既存の手順がないタスクに向けた、エージェント用のワークフロー設計・実行スキルです。複雑または高リスクな作業で、検証可能な目標、段階的な実験、監査可能な記録を重視します。
主な機能
- 01タスクに応じた段階的ワークフロー設計
- 02反証可能な完了条件の定義
- 03リスクの高い未知事項を優先
- 04作業単位ごとの検証と記録
- 05監査可能な意思決定記録
- 06実際の成果物に基づく最終確認
活用シーン
- 01既存手順のない作業の計画
- 02複雑なエンジニアリング変更の分解と検証
- 03複数段階の作業における判断と結果の記録
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/figure-it-outを入力して読み込まれたか確認します。
詳細
解決策を見つける
タスクに当てはまるプレイブックがない場合は、設計します。コードを書く前に成果物として用意するのは、タスクに応じて厳密さを調整し、科学的手法に沿って実行し、人が作業から離れた後でも監査できる判断の記録を残す、一連のフェーズからなるワークフローです。
開始
最初の項目をpoteto-modeスキルの「Principles」セクションを読むことにしたtodoリストを作成します。その後、以下のフェーズをtodoに追加します。
フェーズ A：枠組みを定める
まず根拠を固めてから、取り組みを確定します。以下を明確に述べられるまでは、実行を開始しません。
- 反証可能な述語として定義した完了条件（prove-it-works原則のスキル）。
- 定量化したスコープ：おおよその単位と作業量に加え、根拠を集める中で判明したブロッカー。
- 高めに設定する厳密さのレベル。一方通行の決定や影響範囲の広い変更ほど厳密さを高めます。後戻りでき、リスクの低い手順では厳密さを抑えます。厳密さとはゲートと成果物のことであり、「もっと頑張る」ことではありません。
長時間の実行を確定する前に、枠組みとトレードオフを提示します。後戻りできる作業は進めます（never-block-on-the-human原則のスキル）。ただし、数時間に及ぶ実行では、途中で一度チェックポイントを設けます。
フェーズ B：ワークフローを設計する
作業を、個別に完了できる最小単位に分解します。最も不確実性の高いものから順に進めます。機能より先に、足場と検証を用意します（foundational-thinking原則のスキル）。
- 作業に着手する前に検証ハーネスを構築し、変更前の状態を基準値として記録します。これにより、チェックで「旧値と新値」を比較できます。
- 一方通行となる設計上の判断では、architectスキルを実行します（このスキルはarenaを実行します）。作業の形がすでに具体的な機械的作業では省略します。設計が固まった後に再度arenaを行うのは、過剰な設計です（laziness-protocol原則のスキル）。
- 並列化する作業を判断します。境界が明確な作業のみ並列化し、各ワーカーには個別のワークツリーまたはブランチを割り当てます（separate-before-serializing-shared-state原則のスキル）。過度な並列化は避けます。各サブエージェントの作業量は、poteto-modeスキルの「Subagents」セクションに従い、タスクに合わせて設定します。
- 設計したフェーズの一覧を書き出します。人が確認するのは、この一覧です。
その後、設計を実行します。フェーズ C とフェーズ D の項目の間に、設計した手順を具体的な項目としてtodoリストに追加します。各手順をフェーズ C のループの規律に従って実行し、フェーズ D のログもその都度織り込みます。全工程が終わるまで記録を先送りにせず、各手順が完了するたびに1行記録します。
フェーズ 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原則のスキル）。
返信： 設計したプレイブック、厳密さのレベルとその理由、判断記録のパス、述語に照らして検証済みの内容、未解決の項目。