figure-it-out

解決する

太字またはバッククォートで記されたスキル名、または /<name> として実行するスキルは、このスキルのディレクトリと同じ階層にある ../<name>/SKILL.md ファイルです。接頭辞なしで記された原則名は ../principle-<name>/SKILL.md です。ファイルを読み、その指示に従ってください。pstack のスキルはほとんどがユーザー専用のため、スキルツールでは読み込めません。

タスクに該当するプレイブックがない場合は、プレイブックを設計してください。コードを書く前に作成する成果物は、タスクの規模に応じて厳密さを調整し、科学的手法に従い、人間が作業を離れた後でも監査できる判断の記録を残す、一連のフェーズから成るワークフローそのものです。

開始

タスクリスト（ハーネスのタスクツール、またはタスクツールがない場合は ~/.local/state/pstack/checklists/<repo>-<branch>.md のチェックリストファイル）を開き、最初の項目として poteto-mode スキルの Principles セクションを読むようにします。その後、以下のフェーズを ToDo として追加します。

Phase A：枠組みを定める

まず状況を把握してから、着手します。実行を開始する前に、次のことを明言できる状態にしてください。

• 反証可能な述語として定義した完了条件（prove-it-works 原則スキル）。
• 定量化したスコープ：おおよその単位数と作業量、および状況把握で明らかになったブロッカー。
• 厳密さのレベル。高めに設定します。一方通行の決定や影響範囲の大きい作業には、より厳密さを適用します。取り消し可能でリスクの低い手順には、厳密さを抑えます。厳密さとはゲートと成果物であり、「もっと頑張る」ことではありません。

長時間の実行に着手する前に、枠組みとトレードオフを提示してください。取り消し可能な作業は進めます（never-block-on-the-human 原則）。ただし、数時間に及ぶ実行にはチェックポイントを設けます。

Phase B：ワークフローを設計する

独立して個別にリリースできる小さな単位に分解します。リスクの高い未知事項から順に取り組みます。機能の前に、足場作りと検証を行います（foundational-thinking 原則）。

• 作業に入る前に検証ハーネスを構築し、変更前の状態をベースラインとして記録します。これにより、検査で「旧値と新値」を比較できるようにします。
• 一方通行の設計判断では architect スキルを実行します（そのスキルは arena を実行します）。形がすでに具体化している機械的な作業では省略します。決着済みの設計に対して arena を再度実行するのは、過剰な設計です（laziness-protocol 原則）。
• どの作業を並行して進めるかを決めます。並行化は境界をまたがない場合に限り、各作業者には t3_thread_launch スレッドを使い、worktree の workspaceStrategy を指定して、それぞれ専用の worktree またはブランチを割り当てます（separate-before-serializing-shared-state 原則）。まずハーネスと準備作業をコミットし、そのコミットを baseRef として使います。並行化しすぎないようにします。各サブエージェントの推論レベルと速度（高速または標準）は、poteto-mode スキルの Subagents セクションに従ってタスクに応じて選びます。
• 設計したフェーズ一覧を書き残します。その一覧を人間がレビューします。

その後、設計に沿って実行します。設計した手順を、Phase C と Phase D の項目の間に具体的なタスクとして追加します。各手順は Phase C のループの規律に従って実行し、Phase D のログは最後にまとめて記録するのではなく、各手順が完了するたびに一行ずつ追記します。

Phase C：ループを実行する

各単位を実験として扱います。仮説を立て、変更を最小限にとどめ、実際の成果物を述語に照らして測定し、前進につながった場合は維持し、そうでなければ元に戻します。チェックを最後にまとめて行うのではなく、各単位を検証してから次に進むため、sequence-verifiable-units 原則スキルを適用します。

• 自己申告ではなく、成果物を調査して検証します。何かがあまりにも簡単に合格した場合は、システムより先に観測方法を疑います。
• 委任した作業には判定者を付けます。作業者がゲートをすり抜けた場合は、リセットして契約を強化します。ゲート自体が誤っている場合は、回避するのではなく、独立した変更としてゲートを修正します。
• 判定は VERIFIED、NOT VERIFIED、または INCONCLUSIVE です。INCONCLUSIVE は合格ではありません。否定的な結果を隠さないでください。

Phase D：監査証跡を残す

show-me-your-work スキルを使って実行記録を残します。figure-it-out の作業は通常、十分に大がかりなので、レビュー担当者が PR で読めるよう、記録をコミットします。記録と差分によって、人間が後から作業に戻り、安心して内容を信頼できます。

フェーズ E：検証して引き渡す

実際の製品で、ハーネスだけでなく全体をフェーズ A の述語に照らして確認します。繰り返し発生する修正は、ゲート、Lint ルール、チェック、またはスクリプトとして組み込みます（原則スキル encode-lessons-in-structure）。

返信： 設計したプレイブック、厳密さのレベルとその理由、判断の経緯を示すパス、述語に照らして検証済みの内容、未解決の事項。