figure-it-out について
Figure it outは、既存の手順が合わない課題向けにワークフローを設計するスキルです。作業を検証可能な実験として進め、判断の記録を残します。
主な機能
- 01課題の設定と厳密さの評価
- 02作業のフェーズ分割
- 03実装前の検証準備
- 04実験として進める実行ループ
- 05判断記録と最終レビュー
活用シーン
- 01不慣れなエンジニアリング作業の計画
- 02複雑な変更の検証可能な単位への分割
- 03後から確認できる判断記録の作成
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/figure-it-outを入力して読み込まれたか確認します。
同梱ファイルagents/openai.yamlCREDITS.md
詳細
解決する
タスクに該当するプレイブックがない場合は、作成します。コードを書く前にまず成果物として用意するのは、タスクの規模に応じて厳密さを調整し、科学的手法に沿って進め、人間が作業を離れたあとでも監査できる判断の記録を残す、一連のフェーズからなるワークフローです。
太字で示した原則は principles スキルにあります。タスク一覧の最初の項目に principles を指定して Skill ツールを呼び出し、適用する原則のファイルをそれぞれ読みます。
開始
タスクリストを開きます（ハーネスのタスクツール、またはタスクリストがない場合は ~/.local/state/ox/checklists/<repo>-<branch>.md にあるチェックリストファイル）。最初の項目は principles インデックスを読むことにします。その後、以下のフェーズをTODOとして追加します。
フェーズ A：枠組みを定める
まず現状を把握し、それから着手します。次のことを明言できるまでは作業を開始しません。
- Prove It Works に沿った、反証可能な述語としての完了条件。
- 定量化したスコープ：概算の単位数と工数、および現状把握で明らかになった阻害要因。
- 厳密さのレベル。高めに設定します。一方通行の決定や影響範囲の大きな変更には、より多くの厳密さを適用します。取り消し可能で影響の小さい手順には、より少なく適用します。厳密さとはゲートと成果物であり、「もっと頑張る」ことではありません。
枠組みとそのトレードオフを、意思決定ログの最初の行として記録します（フェーズ D）。その後、作業を開始します。Never Block on the Human に沿って、取り消し可能な作業は待たずに進めます。
フェーズ B：ワークフローを設計する
独立して着手・完了できる最小単位に分解します。リスクの高い未知事項から順に進めます。Foundational Thinking に沿って、機能の前に足場と検証を整えます。
- Prove It Works に沿って、リポジトリの外で作業前に検証チェックを作成します。変更前の状態をベースラインとして記録し、「旧値と新値」を比較できるチェックにします。
- 一方通行の設計上の決定では、
architectを指定して Skill ツールを呼び出します（arenaが実行されます）。内容がすでに具体化している機械的な作業では省略します。Laziness Protocol にあるように、設計が固まったあとにもう一度 arena を行うのは過剰なエンジニアリングです。 - 並行化する作業を決めます。並行化するのは境界が明確な作業に限り、Separate Before Serializing Shared State に沿って、各作業者に専用の git worktree を割り当てます。まず準備をコミットしてから、作業者ごとに
git worktree add <path> -b <branch> <that commit>を実行します。複数の作業者を同時に使う場合は、swarmを指定して Skill ツールを呼び出します。並行化しすぎないようにします。 - 設計したフェーズの一覧を書き留めます。人間がレビューするのはこの一覧です。
その後、設計に沿って実行します。手順を具体的な項目としてタスクリストに追加し、フェーズ C とフェーズ D の項目の間に置きます。各手順はフェーズ C のループ規律に従って実行し、フェーズ D のログもその過程で記録します。全手順が終わるまで記録を先延ばしにせず、各手順が完了するたびに1行ずつ追加します。
フェーズ C：ループを回す
各単位を実験として扱います。仮説を立て、最小限の変更を行い、実際の成果物を述語に照らして測定します。前進につながった場合は維持し、そうでなければ元に戻します。Sequence Work into Verifiable Units を適用し、最後にまとめてチェックするのではなく、各単位を次の単位に進む前に検証します。
- 自己申告ではなく、成果物を確認して検証します。あまりにも簡単に合格した場合は、システムではなく観測方法を疑います。
- 委任した作業には判定者を付けます。作業者がゲートをかいくぐった場合は、リセットして契約を強化します。ゲート自体に誤りがあれば、回避するのではなく、ゲートを独立した変更として修正します。
- 判定は VERIFIED、NOT VERIFIED、または INCONCLUSIVE のいずれかです。INCONCLUSIVE は合格ではありません。否定的な結果を隠してはいけません。
フェーズ D：監査記録を残す
show-me-your-work スキルを使って作業の記録を残します（これを指定して Skill ツールを呼び出します）。figure-it-out の作業は通常、レビュー担当者が PR で読めるよう、記録もコミットするほど大掛かりです。記録と差分がそろっていれば、人間は後から作業を確認し、信頼できます。
フェーズ E：検証して引き渡す
実際の成果物全体をフェーズ A の判定基準に照らして確認します。ハーネスだけを確認するのではありません。繰り返し必要になる修正は、教訓を構造に組み込むに従って、ゲート、リントルール、チェック、またはスクリプトとして組み込みます。
**回答：**設計したプレイブック、厳密さのレベルとその理由、意思決定の記録へのパス、判定基準に照らして検証済みの内容、未解決の項目。