figure-it-out について
figure-it-outは、適切なプレイブックがない場合に、監査可能なワークフローを設計して実行するエージェントスキルです。リスクに応じた厳密さ、段階的な検証、人が確認できる意思決定の記録を重視します。
主な機能
- 01タスクに合わせたワークフロー設計
- 02範囲と検証可能な完了条件の設定
- 03リスクの高い未知事項を優先
- 04作業単位ごとの検証
- 05監査可能な意思決定記録の維持
活用シーン
- 01既存のプレイブックがない作業の計画
- 02大きなタスクを検証可能な手順に分割
- 03完了後の判断と証拠の確認
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/figure-it-outを入力して読み込まれたか確認します。
同梱ファイルLICENSE
詳細
解決方法を見つける
タスクに合うプレイブックがない場合は、設計してください。コードを書く前に成果物として用意するのは、タスクに応じて厳密さを調整し、科学的手法に従い、人が席を離れた後でも監査できる判断の記録を残す、一連のフェーズからなるワークフローです。
開始
最初の項目に boring-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 原則のスキル）。並列化しすぎないでください。
- 設計したフェーズの一覧を書き残します。人がレビューするのはこの一覧です。
次に設計に沿って実行します。フェーズ C のエントリの後、フェーズ D の前に、設計した手順を具体的な項目として ToDo リストに追加します。各項目をフェーズ C のループ規律に従って実行し、手順が完了するたびにフェーズ D のログへ記録します。記録全体を最後まで保留しないでください。
フェーズ C：ループを実行する
各単位を実験として扱います。仮説を立て、最小限の変更を行い、実際の成果物で述語に照らして測定します。前進につながった変更は維持し、つながらなかった変更は元に戻します。 sequence-verifiable-units 原則のスキルを適用し、検証を最後にまとめて行うのではなく、次の単位に進む前に各単位を検証します。
- 自己申告ではなく、成果物を確認して検証します。簡単に合格しすぎる場合は、システムよりも先に観察方法を疑ってください。
- 作業を委任する場合は、判定役も付けます。作業者がゲートをすり抜けた場合は、リセットして契約を厳格化します。ゲート自体が誤っている場合は、迂回するのではなく、独立した変更としてゲートを修正します。
- 判定は VERIFIED、NOT VERIFIED、または INCONCLUSIVE です。INCONCLUSIVE は合格ではありません。否定的な結果を隠さないでください。
フェーズ D：監査記録を残す
show-me-your-work スキルを使って実行を記録します。figure-it-out の作業は通常、意欲的なものになるため、レビュー担当者が PR で読めるよう、記録もコミットするのが適切です。記録と差分があることで、人は後から作業を確認し、信頼できます。
フェーズ E：検証して引き渡す
ハーネスだけでなく、実際のプロダクト全体をフェーズ A の述語に照らして確認します。繰り返し発生する修正は、ゲート、リンタールール、チェック、またはスクリプトとして形式化します（encode-lessons-in-structure 原則のスキル）。
返信： 設計したプレイブック、厳密さのレベルとその理由、判断の記録のパス、述語に照らして検証済みの内容、未解決の内容。