plan

構造化された計画

別のセッションが判断を再検討せずに実行し、検証できる計画を作成します。実行中の状況に応じて実装方法を選べる余地を残しつつ、成果と依存関係を明確に指定し、方針の逸脱を防ぎます。

ユーザーの指示は、このスキルのガイドラインより優先されます。計画を立てても、承認要件が追加されることはありません。実行がすでに許可されている場合は、計画が整ったら続行します。ユーザーが計画のみを求めている場合は、実装を開始せずに計画を提示します。

不確実性に応じて計画の規模を決める

作業の形態	計画の深さ
明確で元に戻せる変更で、直接確認できるもの	簡潔な頭の中またはインラインの計画を立てて実行します
複数の依存する動作があり、既知のパターンがあるもの	タスク、インターフェース、受け入れ確認項目を記録します
アーキテクチャや移行に不確実性があるもの	決定的な未知事項を解消し、代表的な垂直スライスを計画します
エージェント、セッション、環境をまたぐ作業	担当、状態、依存関係、再開手順を保持します

ファイル数はリスクの適切な目安ではありません。1行の認可変更でも、多数のファイルにわたる機械的な名前変更より多くの分析が必要になることがあります。考えられるすべての編集を予測するのではなく、不確実な点や取り消せない部分を明らかにするのに十分な計画を立てます。

実際の開始時点を確認する

リポジトリの状態、関連する差分、対象のコードパスを調べます。既存の実装パターンと、スクリプト、フック、CIに記載された実際の検証コマンドを特定します。設定されている場合は、インストール済みの Sibyl スキルを通じて関連するプロジェクトの記憶を読み込みます。

実行を制約する事実を記録します。

• ユーザーまたはシステムに見える結果。
• 現在のベースラインと、調査対象のリビジョンまたは環境。
• 影響を受けるインターフェース、担当範囲、互換性要件。
• 提案する作業を無効にしかねない不確実性。
• 明示された制約、対象外の事項、ユーザーによる訂正。

引き継いだ計画は仮説として扱います。実行前に、重要な主張を現在のツリーで再確認します。検証済みの事実、確認待ちの仮定、古くなった前提を区別します。前提が誤っていた場合は、計画そのものを更新します。切り離されたコメントを残すだけでは、実行者が古い指示に従い続けることになります。

役立つスライスを選ぶ

新しい仕組みに分解する前に、要求を満たせる既存の機能がないか確認します。簡素化する場合も、要求された結果を維持します。難しいプロダクト上の目標を、都合のよい配管処理のデモに置き換えてはいけません。

不確実な境界を早期に証明できる場合は、垂直スライスを優先します。つまり、実際の入力が変更後のロジックを通り、必要とするコンシューマーに届くことを計画します。移行は互換性とデプロイ順序を考慮して計画します。ソースファイルの順序が、安全なロールアウトの順序を決めるわけではありません。

実装とその動作検証は、同じ担当タスクに含めます。タイトルに「および」が含まれていても、タスクを分割すべき根拠にはなりません。独立してレビュー可能な成果、異なる担当者、または実際の依存関係の境界がある場合に、タスクを分けます。テスト基盤の前提作業は別タスクにしても構いませんが、機能テストを後回しの孤立した作業にしてはいけません。

各タスクに実行可能な契約を設ける

タスクに必要なフィールドだけを使用します。

フィールド	内容
成果	提供する動作または成果物
スコープ	対象となる既知のファイル／モジュールと、許可される範囲拡大のルール
依存関係	必要な入力またはインターフェースと、それらの提供元
検証	正確に実行できるチェックと、それによって確認できる動作
完了の証拠	期待される成果物、アサーション、観察結果、またはレポート
リスクと復旧	重要な場合の互換性、ロールバック、または未解決の外部依存関係

例：

### Task: Reject expired sessions at the request boundary

Outcome: An expired session receives the established unauthorized response.
Scope: The session validator and its request-level tests.
Depends on: The existing clock injection interface, confirmed in the repo.
Verify: [repository's exact focused test command].
Cases: Expired, valid, and boundary-time sessions preserve expected behavior.
Completion: Tests exercise the request path and report executed cases.

既知の場合は実際のファイルパスを優先し、調査が完了したかのように装わず、提案するパスにはその旨を明記します。コピーして実行できるコマンドにもアサーションが必要です。「レンダリングされる」だけでは、生成されたポリシーが意図したリソースと一致することの証明にはなりません。

依存関係とオーナーシップをマッピングする

独立した成果は並行して進めます。ファイルを分ければ衝突は避けやすくなりますが、独立していることの証明にはなりません。2つのモジュールがスキーマ、生成ファイル、テスト用データベース、ポート、出力ディレクトリを共有している可能性があります。こうした共有リソースとそのオーナーを明記します。

すべてのタスクを同期された波に無理にまとめず、依存関係が解決済みの作業を選びます。タスクが重要な統合チェックポイントを共有する場合は、波に分けると有効です。統合オーナーを指定し、ブランチやパッチの統合後に動作を検証します。委任によって有用な処理能力が得られ、現在の指示でも許可されている場合は、orchestrate を利用します。

計画に、抜けている利用側、互換性のないロールアウト状態、不要なスコープがないかを確認します。重要なアーキテクチャやポリシーについては、必要な場合または正当な理由がある場合に、独立したレビューを求めます。レビューの対象は未解決の判断事項に絞ります。新しい証拠や具体的な欠陥によって計画が改善される場合にのみ、追加のレビューを行います。意見の相違だけでは、際限なく修正を続ける理由になりません。

計画を再開可能にする

プロジェクトで正式に使用されているトラッカーまたは合意済みの成果物の保存場所を使います。Sibyl を使用している場合は、現在のタスクとメモのコマンドについて、インストール済みのスキルを使用します。計画全体をチャット、リポジトリのファイル、メモに重複して記載するのは避け、信頼できる計画を1つ選び、トラッカーからそこへリンクします。

作業が複数のセッションにまたがるというだけで、計画用ドキュメントを作成またはコミットしないでください。一時ファイルや計画資料については、リポジトリのルールに従います。ドキュメントが必要な場合は、後続のエージェントが実際にアクセスできる場所に配置し、チェックアウトに含まれない未追跡のコンテキストがある場合は、委任時のブリーフに含めます。

有用なチェックポイントには、現在のリビジョン、完了した成果とその証拠、現在のオーナーシップ、保留中の判断事項、具体的な次のステップを記録します。コンテキストの圧縮時に失われるおそれのあるユーザーからの修正内容を保持します。再開時はチェックポイントを読み直し、実際の状態を確認します。メモが示すのは過去の状態であり、現在の状態を保証するものではありません。

目標を見失わずに計画を見直す

実装で新たな制約が明らかになったら、影響を受けるタスクを変更し、成果、依存関係、リスクへの影響を説明します。修正内容は、編集した段落だけでなく、表や受け入れ基準にも反映します。却下した代替案は、その根拠が後の判断に役立つ場合に限って保持します。

統合の境界では、累積した差分を意図した成果と照らし合わせます。スコープが逸脱していても、テストに合格することはあります。レビューの強度は、タスク番号やそれ以前に合格したタスクの数ではなく、変化したリスクとカバレッジに合わせます。作業が後半に差しかかっていても、プロジェクトで必須とされる検証は実施します。

必要な証拠がそろった場合にのみ、作業を完了として記録します。外部の必須チェックを実施できない場合は、完了したローカルチェックとは別に報告し、具体的なブロッカーと次のアクションを明記します。ブロック状態を記録する際は、ホストのタスク状態に関するルールに従います。このスキルはそれらのルールを変更するものではありません。

エビデンスと限界

2026-09-04 に確認しました。Anthropic の 2026 年 3 月のハーネスに関するレポートでは、成果を重視した仕様と合意のうえで定める検証基準について説明する一方、評価を繰り返すことで実装の複雑さも増す可能性があると指摘しています。これはエンジニアリングの事例研究であり、すべてのプロジェクトにプランナー・ジェネレーター・エバリュエーターのパイプラインが必要だと証明するものではありません。

ここでの手順では、この違いを踏まえ、テスト可能な契約を維持しつつ、実行経路を適応させます。計画の変更は、計画の規模ではなく、作業の成果と修正コストを基準に評価します。

アンチパターン

アンチパターン	より良い方法
コードを読む前に編集箇所を正確に予測する	検証済みの境界と不確かな詳細を明示する
各機能をテストから切り離す	提供した動作に対して、1 人の担当者が責任を持つ
ファイル名だけを根拠に並列化する	共有インターフェースと実行時リソースを確認する
実装の承認後も承認を求める	既存のスコープ内で続行する
作業が遅れているためレビューを簡略化する	現在のリスクとエビデンスに応じてレビューする
競合する進捗管理台帳を複数維持する	関連する記録をひも付けた、信頼できる計画を 1 つ維持する
成功条件を満たした後も細分化を続ける	実行し、エビデンスによって作業が変わる場合に再計画する

このスキルに該当しないこと

• 些細な作業や、固定されたファイル数のしきい値に対する要件ではありません。
• 計画のみを求める依頼を実行する許可ではありません。
• 初期のアーキテクチャ、スケジュール、タスクリストが変更されないという保証ではありません。