planning

垂直スライスでの計画

可能な限り、垂直スライス単位で計画します。 各スライスでは、実際のアクターが観察できる、エンドツーエンドの最小限の振る舞いを実現しながら、すべてのテストが通る既知の正常な状態にコードベースを保ちます。

水平的な作業が認められるのは、次の垂直スライスを明確に可能にし、それ自体も個別に検証できる場合、または、動作を維持しながら仕組み全体を一つ廃止する完了状態を目指す、明示的に選択された削減プログラムに属する場合に限られます。

Claude Code 環境で /plan と /continue が利用できる場合は、/plan で計画を作成し、独立した PR がマージされた後、または進行中のスタックを進めて同期する際に /continue を使用します。それ以外の場合は、計画の成果物を直接作成または更新し、進行中のハーネスまたはリポジトリのワークフローを通じて作業を再開します。

ストーリー分割との関係

story-splitting では、どのような小さなユーザー価値のストーリーがあるかを決めます。planning では、選択したストーリーを安全に実装する方法を決めます。

依頼がまだエピック、大規模なストーリー、機能のアイデア、ロードマップ項目、または顧客に提供できる結果が複数考えられるバックログ項目である場合は、このスキルを使う前に story-splitting を使ってください。子ストーリーまたは対象を絞った機能が選択されたら、このスキルを使って、各スライスの実装単位、受け入れ基準、エビデンスの確認方法、デリバリー形式を含む計画成果物をリポジトリ内に作成または更新します。

次の3つの単位を明確に区別してください。

単位	意味	デフォルトの関係
バックログストーリー	story-splitting で定めた、製品機能と受け入れ範囲	計画では選択した1つのストーリーを進める場合があります
実装スライス	前提条件が満たされた後、安全にマージおよびリリースできる最小の垂直的な増分、または明示的な縮小遷移／終端状態	デフォルトでは1つのPR
PR の境界	スライス全体を担う、または例外的に1つのスライス内の依存レイヤーを担うレビュー単位	独立して存在するか、意図的なスタックの中に存在します

順序は作業の順番、スタックはブランチの構成です。デフォルトでは、各スライスをトランクベースのPRにしてください。どの順番でもマージでき、作業の妨げや重複を生じさせない場合、または後続のブランチを前のブランチのマージ後に開始する場合は、スライスPRを独立させてください。1つのスライスに複数のレビュー用レイヤーが必要な場合、または先行するPRのマージ前に、後続のスライスを同じ進行中のベースラインから開始する場合は、stack-pull-requests を読み込んでください。ハードな依存関係があれば十分ですが、必須ではありません。意図的なフローの系譜を理由に、スタックにする場合もあります。推測に基づく後戻りだけでは理由になりません。

計画が、データベースのみ、APIのみ、UIのみのスライス、または「まず配線をすべて済ませる」スライスになり始めた場合は、いったん中断して story-splitting に戻ってください。ただし、その水平的な作業が、独立した検証を通じて次の垂直スライスを明確に可能にする場合、または明示的に選択された縮小プログラムを、名称が定められたメカニズム削除の終端状態へ進める場合は除きます。

選択されたストーリーに未解決のプロダクトまたはデザイン上の判断が残っている場合は、計画の前に、インストール済みであれば grill-me を使ってください。それ以外の場合は、推奨する回答とそのトレードオフを示しながら、一度に1つの焦点を絞った質問をしてください。受け入れ基準、失敗モード、役割、状態、リリース上の制約が不足している、または検証できない場合は、計画案の作成前または作成後に find-gaps を使ってください。

重要な汎用メカニズムや長期的に利用する新たな依存関係を導入するスライスを確定する前に、影響の度合いに応じて evaluate-existing-solutions の事前評価、デューデリジェンス、または全面的な比較を実施してください。選択が未解決だった場合は、意思決定者が受け入れた結果をリンクしてください。Planning は選択されたソリューションを順序立てるものであり、最初にもっともらしく見えたライブラリや独自のスケッチを、暗黙のうちに計画へ取り込むものではありません。

入力の状態	使用するもの	出力
あいまいな意思決定ツリー	インストール済みであれば grill-me、それ以外の場合は一度に1つの質問をするインタビュー	解決済みの判断、または明示された未解決の質問
結果が複数考えられる広範な要件	story-splitting	子ストーリー
不備のある既存ストーリー／計画／AC／モック	find-gaps	確認済みの成果物の更新
デリバリーの順序付けができる選択済みの子ストーリー	planning	デリバリー形式を伴う実装スライス
1つのスライスにレビュー用レイヤーが必要な可能性がある、または下位のPRのマージ前に後続スライスを開始できる場合	stack-pull-requests + planning	独立したPR、または明示的なハード依存／フローの系譜によるスタック

Plans ディレクトリ

リポジトリで定められた計画のワークフローと保存場所を使用します。リポジトリによっては、ドキュメント、イシュー、または別の指定されたシステムで計画を管理しています。管理場所が定められておらず、ファイルベースの計画が適切な場合は、プロジェクトのルートに説明的なファイル名（例：plans/gift-tracking.md）で plans/ を使用します。

そのワークフローを通じて、進行中の計画を確認します。フォールバックの構成では、ls plans/ を使用します。

複数の計画を並行して進められます。それぞれは独立しており、ファイル名が固有のため、ブランチやワークツリーをまたいで競合することはありません。

計画が完了したら： リポジトリのライフサイクルルールに従います。フォールバックの構成では、計画ファイルを削除し、空になったら plans/ も削除します。

レビューしやすい小規模な PR を優先する

基本的には、既知の範囲で最小の、動作が確認できる垂直スライスに分け、スライスごとに trunk-based の PR を 1 つ作成します。上位のスライスが下位のスライスに強く依存している、または意図的なフローの系譜があり、下位のマージ前に作業が並行して進むうえ、レビュー、リードタイム、修正の振り分けによるメリットが連鎖のコストに見合う場合は、スライスをまたぐスタックを使用します。1 つの固定されたスライス内で、依存関係のあるレビュー層を分ける必要がある場合は、スライス内のスタックを使用します。

これが重要な理由： 小さな PR はレビューしやすく、元に戻しやすく、内容も把握しやすくなります。何かが壊れたときに、原因が明らかです。PR のレビューが滞っても、無関係な作業が止まりません。常に main にできるだけ近い状態を保つことが目標です。

PR が大きすぎるのは、 レビュー担当者が内容を理解するために、互いに無関係な複数の概念を同時に把握しなければならない場合、または変更内容を 1〜3 文で明確に要約するのが難しい場合です。

例外もあります。適切に判断してください。まず、実質的な垂直スライスを定義し、次にそれぞれを独立させるか、スライスをまたぐ強い依存関係やフローのスタックを共有するか、1 つのスライス内でレビュー層を分ける必要があるかを決めます。

垂直スライスとは

垂直スライスとは、「1 つのレイヤーに触れるから小さい」というものではありません。実際の本番経路を通じて、観測可能な 1 つの動作を提供するから小さいのです。

各スライスでは、以下を必ず明示します。

• アクター：価値を受け取るのは誰か（ユーザー、管理者、API クライアント、スケジュール済みジョブ、サポート担当者）
• トリガー：何が動作を開始するか（クリック、リクエスト、イベント、コマンド、タイマー）
• 観測可能な結果：動作が発生したことを何で証明するか
• 本番経路：関与する実際のサーフェス、ユースケース、ドメインロジック、永続化、外部アダプター
• デプロイ可能な最小の価値：安全にリリースできる、最も小さく実用的なバージョン

適切なスライスは、多くの場合、薄くても一通り完成しています。

• フォームが有効なフィールドを 1 つ送信し、実際の API を経由して永続化する
• バックグラウンドジョブが 1 種類のイベントを処理し、期待される監査結果を出力する
• CLI コマンドが 1 種類の入力形式に対応し、安定した stdout/stderr を返す
• 読み取り専用画面が、本番のデータ読み込みを使用して実際の状態を 1 つ表示する

スライスの選び方

計画のスライスを書く前に、次の手順を行います。

1. 結果を明確にする — ユーザーまたはシステムから見える結果を 1 文で説明します。
2. 経路をたどる — 実際のエントリーポイント、ビジネス経路、状態の変化、出力、可観測性を列挙します。
3. 歩行骨格を選ぶ — 経路が機能することを証明できる、最も薄いエンドツーエンドのバージョンを選びます。
4. 一度に 1 つの動作または状態を追加する — バリデーション、権限、エラー状態、空の状態、再試行、アナリティクス、仕上げは後のスライスに回します。
5. 元に戻せるか確認する — 各スライスは、無関係な作業を元に戻さずに、簡単にリバートまたは無効化できる必要があります。

「どのファイルを変更する必要があるか」と考える前に、「リリースできる、最小の実際の動作は何か」と問いかけます。 答えに複数の顧客向けの結果、役割、ワークフローの分岐、または品質レベルが含まれる場合は、story-splitting を読み込み、計画を書く前に親項目を分割します。

水平作業の例外

データベース、API、UI、インフラの作業をすべて先に行う計画は避けてください。水平作業を独立したスライスにできるのは、該当する条件をすべて満たす場合に限ります。

• 次に実施する、実現を可能にする垂直スライスを明記しているか、最終的に仕組みを削除することを目的とした、明示的に選択された削減プログラムに属している
• コードベースをデプロイ可能な状態に保つ
• 観測可能な検証手段（テスト、コマンド出力、マイグレーションのドライラン、またはランタイムチェック）がある
• 垂直スライスの中で実施するより小規模である
• 未使用の抽象化や、先を見越した柔軟性を持ち込まない

有効な水平作業の例外には、依存関係のアップグレード、マイグレーション、テストハーネスのセットアップ、インフラの接続、機械的なリファクタリング、安全性の修正、および挙動を維持しながら完全な仕組みを一つ廃止することを最終状態とする、選択済みの reduce-system-complexity プログラムが含まれます。こうした例外はまれにし、明示してください。中間的な削減の移行では、独立して検証可能で、同じ計画に最終スライスと挙動／仕組みのゲートが明記されていれば、一時的にブリッジを追加してもかまいません。ブリッジを追加する場合は、担当者、削除条件、期限を限定した存続期間を記録してください。ブリッジがない場合は N/A と記録してください。

既知の良好なスライスの条件

各スライスは、必ず以下を満たす必要があります。

• すべてのテストに合格する
• 単独でデプロイ可能である
• 完了条件が明確である
• 原則として1つのPRに収まるか、承認済みの stack-pull-requests デリバリーマップがある
• 1文で説明できる
• 観測可能な挙動を実現するか、その実現を直接可能にする。または、明示的に選択された削減プログラムを、最終的な挙動／仕組みのゲートに向けて安全に進める

スライスは、計画と既知の良好な価値を提供する単位です。原則として、trunkに対する1つのレビュー用PRでもあります。複数スライスを積み重ねる場合、各PRは完全なスライスを1つ担当し、そのスライスは下から順にPRがマージされた時点で完了します。1つのスライス内で積み重ねる場合、依存するPRレイヤーはレビュー範囲を明確にするものであり、最上位のPRがマージされた時点でスライスが完了します。挙動を変更する各PR境界の中では、RED-GREEN-REFACTORの短いサイクルによって複数のコミットが生じることがあります。ミューテーションテストまたは代替のエビデンスは、各サイクルの後ではなく、その境界がPRとして準備できた時点で1回実行します。

スライスを1文で説明できない場合は、さらに細分化してください。

スライスのサイズを判断する目安

大きすぎる場合：

• 1回の作業セッションを超える
• 説明に「および」が複数含まれる
• テスト方法がわからない
• 関連のないフィクスチャ、モック、画面、エンドポイントを多数必要とする
• 成果を実証せずにレイヤーを構築する

適切なサイズの場合：

• 明確な挙動が1つある
• 主となるテストケースが1つあり、対象を絞ったエッジケースがある
• すぐに相手へ説明できる
• 完了したかどうかが明白である
• その挙動に必要な経路だけに変更が及ぶ
• 後続のスライスが実施されなくても、有用なチェックポイントが残る

TDD 統合

動作を変更する各スライスでは、迅速な RED-GREEN-REFACTOR の反復を行い、そのスライスが PR に向けて準備できた段階で、フェーズ終了時にミューテーションまたは代替エビデンスのゲートを 1 回実施します。 実装前に、tdd、testing、該当する refactoring のガイダンスを読み込んでください。手軽なテスト設計の指針として mutation-testing のミューテータールールを使用しますが、自動ハーネスの実行は PR の準備が整うまで保留します。動作を維持する真のリファクタリングや reduce-system-complexity スライスは、妥当な規模の合格済み維持エビデンスから開始し、同じフェーズ終了時のゲートを使用します。失敗する仕組み数テストや構造的ミュータントを決して捏造しないでください。このセクションはルーティング契約であり、これらのスキルに代わるものではありません。

どのスタックでも、親レビュー境界に対する各 PR でこの手順を適用してください。動作を最初に担当する PR にテストを追加し、各境界で PR の準備が整ったときにミューテーションまたは代替エビデンスのゲートを 1 回実施します。また、最上位の PR では、含まれるすべてのスライスの累積した受け入れ基準または削減ゲートを満たしていることを証明する必要があります。テストやエビデンスを上位の PR に先送りしないでください。

FOR EACH BEHAVIOR-CHANGING SLICE OR PR BOUNDARY:
    │
    ├─► LOAD: Required implementation skills
    │   - `tdd` for RED-GREEN-REFACTOR
    │   - `testing` for behavior-driven tests and factories
    │   - `refactoring` when restructuring is applicable; otherwise `N/A`
    │
    ├─► CONFIRM: Present acceptance criteria for this slice
    │   - Human must approve criteria before any code is written
    │   - Criteria must be specific and observable
    │   - Do NOT proceed until human confirms
    │
    ├─► RED: Write failing test FIRST
    │   - Test describes expected behavior
    │   - Test fails for the right reason
    │   - Run only the exact test/test name needed to prove RED
    │   - Test plan accounts for likely mutants from the `mutation-testing` skill's `resources/mutator-rules.md` resource
    │
    ├─► GREEN: Write MINIMUM code to pass
    │   - No extra features
    │   - No premature optimization
    │   - Just make the test pass
    │   - Follow the `tdd` skill's canonical watcher selection, lifecycle, cleanup, and live-proof policy
    │   - Prefer a proven repository-owned watcher; use diff-selected Vitest watch only under the canonical version/configuration proof
    │   - Use the affected one-shot when watch is unreliable; do not hand-pick GREEN test files
    │   - Keep watcher discovery live for new tests, or rerun the affected one-shot after creation; reject zero-test/`--passWithNoTests` results
    │   - In monorepos, run through the root project/task graph so shared-package consumers remain eligible
    │
    ├─► REFACTOR: Assess improvements
    │   - See `refactoring` skill
    │   - Only if it adds value
    │   - Focused and affected tests stay green; do not rerun the full suite after every edit
    │
    ├─► REPEAT: Continue RED-GREEN-REFACTOR as needed
    │   - Do not run the automated mutation harness after each increment, refactor, or commit
    │
    └─► STOP: Present the work and wait for commit approval
         - Show what was implemented and the ordinary verification
         - Human reviews and approves before commit

WHEN THE CURRENT REVIEW BOUNDARY IS OTHERWISE READY FOR ITS PR:
    ├─► LOAD: `mutation-testing`
    ├─► MUTATE OR ALTERNATE EVIDENCE: Run once for the focused boundary scope, or record explicit `N/A` plus proportionate alternate evidence
    ├─► KILL MUTANTS: Address valuable survivors and re-run focused/diff mutations within the same gate
    └─► COMPLETE: Finish the remaining PR checks and present the final report

純粋なリファクタリングでは、次の手順に置き換えます。維持するコンシューマー契約を確認する → 該当する合格済みベースラインを実行する → 合格状態を維持しながら再構成する → 維持する対象範囲を検証する → PR の準備が整った段階で、累積したスコープに対するミューテーションテストを 1 回実施するか、妥当な規模の代替エビデンスをレビューする。

削減への移行では、次の手順に置き換えます。削減プログラム／台帳と最終スライスをリンクする → 保持する契約を確認する → 該当するベースラインを実行する → 独立して検証可能な移行を行う → 動作ゲートに合格する → ブリッジの所有者／削除／存続期間の上限を記録する（該当するものがない場合は N/A） → mechanism gate: pending — no net-reduction claim の状態を維持する → PR の準備が整った段階で、ミューテーションまたは代替エビデンスのゲートを 1 回適用する。

最終的な削減では、次の手順に置き換えます。プログラム／台帳をリンクする（または承認済みの単一スライスの場合は N/A） → 該当するベースラインを実行する → 置き換えられた仕組みと期限切れのブリッジを削除する → 移行に関する義務を解消する → 動作ゲートと仕組みゲートの両方に合格する → PR の準備が整った段階で、ミューテーションまたは代替エビデンスのゲートを 1 回適用する。

テストされていない動作変更は禁止です。「テストは後で追加する」は認められません。

コミットの規律

ユーザーの承認なしにコミットしてはなりません。

実装の反復を完了したら、次の手順を行います。

1. 該当するテストが合格すること、および／または承認済みの維持エビデンスが引き続き有効であることを確認する

2. 静的解析が合格することを確認する

3. クラスごとのエビデンスを提示する。動作変更の場合は RED/GREEN、純粋なリファクタリングの場合は維持する契約、移行の場合は合格した動作ゲートと独立した検証および保留中の仕組みゲート／正味削減の主張なしの状態、最終的な削減の場合はリンクされたプログラム／台帳、解消済みの義務、両方の合格済みゲート、および廃止した仕組みを提示する

4. すべてのコミットでミューテーションレポートを要求してはなりません。現在の PR 境界の準備が整った段階で、フェーズ終了時のミューテーションゲートを 1 回実施し、最終レポート（またはレビュー済みの代替エビデンス記録と N/A の理由）を提示します。

5. 停止して、次のように確認します：「[説明] をコミットする準備ができました。承認しますか？」

明示的な承認を得た後にのみ、コミットに進んでください。

承認を待つ理由

• ユーザーが Git の履歴を管理できます
• コミット前にレビューできます
• 未完了の作業を誤ってコミットするのを防げます
• 議論の自然なチェックポイントになります

計画ファイルの構成

ファイルに保存する各計画は、次の構成に従います。

# Plan: [Feature Name]

**Branch**: feat/feature-name
**Status**: Active

## Goal

[One sentence describing the outcome]

## Acceptance Criteria

[For a behavior-change delivery plan, use behavior-driven criteria that describe observable business outcomes, not implementation details. Test at the lowest level that gives confidence: prefer unit tests for logic/domain behavior, browser tests for UI interaction, and end-to-end tests only for end-to-end flows.

For a reduction program, define the conserved observable contract, terminal same-scope mechanism delta, retirement of superseded machinery and expired bridges, passing behavior/mechanism gates, and mutation results or explicit mutation `N/A` with proportionate alternate evidence. Do not invent new product behavior or tests for mechanism shape.]

- [ ] Criterion 1
- [ ] Criterion 2
- [ ] Criterion 3

## Slices

Classify every slice as **behavior change**, **pure refactor**, **reduction transition**, or **terminal reduction**. Behavior-changing slices use RED-GREEN-REFACTOR increments and all classes use one end-of-phase mutation or alternate-evidence gate at PR readiness. Pure refactors start from passing preservation evidence. Every reduction transition and terminal reduction loads `reduce-system-complexity` and references the plan-level reduction program. A transition may add a bounded bridge but never claims net reduction: its mechanism gate remains explicitly pending until the terminal slice removes the old mechanism and expired bridges. Only the terminal reduction may claim net removal after both behavior and mechanism gates pass.
Read the repository's governing instructions and testing rules before writing slices.

## Reduction Program (include only when applicable)

**Ledger/report**: [Link to the `reduce-system-complexity` diagnosis and conservation ledger.]
**Conserved contract**: [Behavior and guarantees that every transition and the terminal state preserve.]
**Superseded mechanism**: [The complete mechanism the terminal slice will retire.]
**Terminal slice**: [Slice name/number that removes the old mechanism and expired bridges.]
**Owner and removal condition**: [For each temporary bridge: accountable owner, objective removal condition, and latest acceptable removal point; otherwise `N/A — no temporary bridge`.]
**Behavior gate**: [Required evidence and fidelity.]
**Mechanism gate**: [Like-for-like whole-mechanism accounting required at the terminal slice.]

### Slice 1: [One sentence observable behaviour]

**Value**: [Behavior change: actor and observable outcome. Pure refactor: preserved consumer surface and maintenance value. Reduction transition: why this independently verifiable increment is necessary to reach the terminal state. Terminal reduction: conserved contract plus the ownership/mechanism retired.]
**Path**: [Behavior change: entry point -> business path -> state/output -> observability. Pure refactor: preserved public surface. Either reduction class: affected trigger-to-outcome path, program/terminal link, and mechanism scope.]
**Class**: Behavior change / pure refactor / reduction transition / terminal reduction.
**Delivery**: [Independent PR against trunk (default); cross-slice stack member referencing the shared `#### Delivery Shape`; or an intra-slice `#### Delivery Shape` map.]
**Required implementation skills**: For changed behavior, load `tdd`, `testing`, and applicable refactoring guidance. For a pure refactor, load only applicable testing and refactoring skills. Every reduction transition and terminal reduction loads `reduce-system-complexity` plus applicable evidence skills. At each PR boundary's readiness, load `mutation-testing` for the focused scope where meaningful or record the alternate-evidence `N/A`. Add UI/domain/architecture skills only when relevant.
**Reduction program**: [For either reduction class: reference the plan-level program and terminal slice; otherwise `N/A`.]
**Transition/terminal evidence**: [Transition: `behavior gate: pass`, independent verification, bridge owner/removal/bounded-lifetime metadata when a bridge exists (`N/A` otherwise), and `mechanism gate: pending — no net-reduction claim`. Terminal: passing behavior gate, like-for-like mechanism gate, and removal of the superseded mechanism/expired bridges. Otherwise `N/A`.]
**Acceptance criteria**: [Behavior change: specific observable outcome. Pure refactor: conserved surface plus preservation evidence. Transition: passing behavior gate, independent verification, optional bridge metadata or `N/A`, and pending mechanism gate/no net claim. Terminal: both gates pass and superseded machinery/expired bridges are gone. **Present to the human and get confirmation before writing any code.**]
**RED or preservation baseline**: For behavior change, what failing behavior test will we write? For a pure refactor/reduction, which passing oracles and proportionate non-test evidence conserve the affected behavior and guarantees? Never assert implementation shape merely to create RED.
**GREEN or preservation change**: What minimum code makes the new behavior pass, or what smallest mechanism-only change preserves the baseline?
**REFACTOR**: Assess improvements (only if they add value).
**PRE-PR MUTATION or alternate evidence**: Once the current review boundary is otherwise PR-ready, run mutation testing once for its accumulated scope. Address valuable survivors and re-run focused/diff checks inside the same gate. Otherwise mark `N/A` and name reachability, configuration, contract, integration, or operational evidence; never invent structural mutants.
**PR-ready when**: All acceptance criteria owned by the current boundary and its end-of-phase mutation/alternate-evidence obligations are met. A transition's behavior gate and independent checks pass while its mechanism gate remains truthfully pending with no net claim; a terminal reduction passes both gates and removes old machinery/expired bridges. The human approves the commit.
**Slice complete when**: Its independent or cross-slice owning PR lands, or the top PR lands for an intra-slice stack.

### Slice 2: [One sentence observable behaviour]

Use the same adaptive fields as Slice 1. Classify the slice independently; do not inherit a behavior-change workflow when this slice only preserves behavior or removes mechanism.

## Pre-PR Quality Gate

Before each PR:
1. Implementation complete — confirm applicable refactoring/reduction assessment and ordinary verification are complete
2. Mutation or alternate evidence — run `mutation-testing` once for the accumulated PR scope where meaningful; address valuable survivors within the same gate, or review the explicit `N/A` rationale and proportionate evidence
3. Typecheck and lint pass
4. DDD glossary check — if the project uses DDD, verify all domain terms match the canonical glossary
5. Complete tests — stop watchers and run the repository-defined complete non-watch PR test gate; in a monorepo include every configured project and required integration/E2E suite, not only the affected development subset
6. Evidence freshness — apply the target repository's mutation-evidence rule after later fixes. Use this distribution's model (the `panel-review` skill's `references/pr-readiness.md`) only when the repository has no stricter invalidation policy, and keep project verification current after resulting fixes

For an intra-slice stack, nest the exact `#### Delivery Shape` and whole-stack gate under that slice. For a cross-slice stack, place one shared map before the first included slice and reference it from each included slice. Never stack an entire plan by default.

---
*Complete this plan using the repository's declared lifecycle. For the
fallback `plans/` layout, delete this file and remove the directory when
empty.*

計画の変更には承認が必要です

計画を変更する必要がある場合：

1. 何が、なぜ変更されたかを説明する
2. 更新後のスライスを提案する
3. 作業を続ける前に、承認を待つ

計画は不変ではありませんが、変更は明示し、承認を得る必要があります。

機能の完了

各スライスを担当する PR がすべてマージされたとき（またはスライス内の各スタックで最上位の PR がマージされたとき）：

1. 完了を確認する — 担当する PR がすべてマージ済みであること、受け入れ基準をすべて満たしていること、該当するテストおよびミューテーション／代替の証拠が合格していること、削減プログラムがある場合は、両方のゲートに合格し、古い仕組みや期限切れのブリッジがなくなった終端スライスに到達していることを確認します
2. 学びを反映する — 重要な知見が得られた場合、利用可能であれば Claude Code の learn または adr エージェントを使用します。利用できない場合は、プロジェクトのガイダンスには expectations スキルを、アーキテクチャ上の決定にはリポジトリで確立されている ADR の仕組みを使用します
3. 計画を終了する — リポジトリで定められたライフサイクルに従います。フォールバックの plans/ レイアウトを使用する場合は、ファイルを削除し、空になったディレクトリも削除します

アンチパターン

❌ 承認なしでコミットする

• コミットする前に、必ず明示的な「はい」を待ちます

❌ レイヤーケーキ型の計画

• 「データベースを構築し、次に API、次に UI」のような進め方は、学びを遅らせ、統合の不具合を見えにくくします

❌ 名前の付いたスライスがない基盤作業

• セットアップが必要な場合は、それによって可能になる垂直スライスと、セットアップの検証方法を明記します

❌ データベースのみ、API のみ、または UI のみのスライスを既定にする

• これらは通常、独立した価値のある動作ではなく、実装タスクです

❌ 配線作業をすべて先に行う

• 実際の経路を証明するウォーキングスケルトンを優先し、その後、動作ごとに範囲を広げます

❌ 提供方針を決めずに複数の PR にまたがるスライス

• 既定では、各スライスをトランクベースの 1 つの PR とします。スライス間のフロー／ハードスタックやスライス内のレビューレイヤーが実質的に役立つ場合は、stack-pull-requests を読み込み、正確なトポロジーを正当化し、各スライスのスコープと終端要件をすべて維持します

❌ テストより先に動作を変更する

• 動作変更では RED を先に行います。真の REFACTOR スライスでは、代わりに合格済みの動作維持の証拠を記録します

❌ 計画を黙って変更する

• 計画の変更にはすべて、議論と承認が必要です

❌ 機能の完了後も計画ファイルを残す

• リポジトリのドキュメントライフサイクルに従います。一時的な計画は完了後に削除し、長期的に維持する決定やガイダンスは、それらを管理する保守対象の成果物に移します

クイックリファレンス

START FEATURE
│
├─► Create or update the repository-owned plan (get approval)
│
│   FOR EACH IMPLEMENTATION SLICE:
│   │
│   ├─► DELIVERY: Independent trunk-based PR by default; otherwise reference an approved intra- or cross-slice stack map
│   ├─► BEHAVIOR CHANGE: LOAD → CONFIRM → RED → GREEN → REFACTOR → REPEAT WITHOUT MUTATION HARNESS
│   ├─► OR PURE REFACTOR/REDUCTION: PASSING BASELINE → REFACTOR/REDUCE → VERIFY GATES
│   ├─► **PRESENT WORK, WAIT FOR COMMIT APPROVAL**
│   ├─► PRE-PR: Run mutation once for each current review boundary (or alternate evidence), handle survivors within the gate
│   └─► Verify focused and top-level criteria; create one PR or the planned stack
│
END FEATURE
│
├─► Verify all owning PRs landed and all criteria met
├─► Merge learnings if significant (installed learn/ADR workflow, or `expectations` plus the repository's ADR mechanism)
└─► Close the plan using the repository's declared lifecycle