aif-plan

計画 - 実装計画

機能またはタスクの実装計画を作成します。モードは 3 つあります。

• Fast – Git ブランチを作成せずに簡易計画を作成し、設定された Fast 計画パス（デフォルト：.ai-factory/PLAN.md）に保存します
• Full — より詳細な計画を作成し、希望を確認して、設定された Full 計画ディレクトリに保存します。Git が有効で、ブランチの作成が許可されている場合は、任意で Git ブランチ／ワークツリーを作成します
• Ultra — 設定された Full 計画ディレクトリに、複数ファイルから成る包括的な計画一式を作成します。index.md はマニフェスト／進捗台帳となり、実装フェーズごとに詳細な仕様を記載した Markdown ファイルを作成します。後続の実行を小型モデルに任せるため、より高性能なモデルで計画を立てる場合に使用します。

Ultra のレイアウト、詳細な要件、整合性チェック、および利用側の動作については、 一式を作成または変更する前に references/ULTRA-FORMAT.md を読んでください。

ワークフロー

ステップ 0（事前）：ハンドオフモードの検出

ハンドオフモード、タスク ID、ブランチの契約を特定します。各値は個別に解決してください。これにより、HANDOFF_MODE と HANDOFF_TASK_ID だけを渡す従来の呼び出し元も、正しくハンドオフモードに入れます。

• HANDOFF_MODE：明示的なプロンプト値があればそれを使用し、なければ環境変数の値を使用し、それもなければ空文字列
• HANDOFF_TASK_ID：明示的なプロンプト値があればそれを使用し、なければ環境変数の値を使用し、それもなければ空文字列
• HANDOFF_BRANCH_PREPARED：明示的なプロンプト値があればそれを使用し、なければ環境変数の値を使用し、それもなければ 0
• HANDOFF_BRANCH_NAME：明示的なプロンプト値があればそれを使用し、なければ環境変数の値を使用し、それもなければ空文字列

プロンプトで明示的に渡されていない値に限り、Bash ツールを使用します。

Bash: printenv HANDOFF_MODE || true
Bash: printenv HANDOFF_TASK_ID || true
Bash: printenv HANDOFF_BRANCH_PREPARED || true
Bash: printenv HANDOFF_BRANCH_NAME || true

次に HANDOFF_MODE を確認します。

HANDOFF_MODE が 1 の場合（自律型ハンドオフエージェント）

ハンドオフコーディネーターが、ステータス遷移と DB 書き込みをすでに直接管理しています。MCP ツール（handoff_sync_status、handoff_push_plan）は呼び出さないでください。代わりに、次のようにします。

• 対話形式の質問は禁止： AskUserQuestion は使用しないでください。適切なデフォルト値（詳細ログを有効、テストを実行、ドキュメントを作成、ロードマップとの関連付けは省略）を使用します。
• モードのデフォルト： 明示的なモード → 有効な workflow.plan_mode → fast の順に解決します。非対話型のハンドオフモードでは、ask のデフォルト値は fast にフォールバックします。このモードでは、モードについて質問しないでください。このフォールバックを適用する前に、ステップ 0 で設定を解決します。
• 計画の注釈（必須）： HANDOFF_TASK_ID が空でない場合、計画エントリーポイントの最初の行に `` を挿入しなければなりません（Ultra では index.md、それ以外では計画ファイル）。タイトルより前に挿入してください。この注釈により、計画がハンドオフタスクに関連付けられ、双方向同期が可能になります。HANDOFF_TASK_ID が設定されているのにこの注釈を省略するのは不具合です。完了前に必ず確認してください。

Handoff におけるブランチの所有権（重要）

Handoff はエージェントコードレベルでブランチの作成を管理します。Handoff がブランチを準備している場合、スキルでブランチを作成または切り替えてはなりません。次のルールを適用してください。

HANDOFF_BRANCH_PREPARED が 1 の場合：

• git checkout、git pull、または git checkout -b を実行してはなりません。
• 後続のすべての動作で --parallel を無効として扱ってください。
• ワークツリーを作成してはなりません。
• プロンプト／環境変数から HANDOFF_BRANCH_NAME を読み取ってください。
• 完全一致を厳密に検証してください：

  Bash: git rev-parse --abbrev-ref HEAD
  

  出力は HANDOFF_BRANCH_NAME と完全に一致する必要があります。一部一致、プレフィックス一致、または「ブランチ名に / が含まれている」という推測に基づく判定を受け入れてはなりません。
• 現在のブランチが HANDOFF_BRANCH_NAME と一致しない場合は、処理を中止してください。計画の要約にブロッカーとして次の内容を報告します：

  Branch drift: expected <HANDOFF_BRANCH_NAME>, actual <current>. ブランチの切り替えや作成によって不一致を「修正」してはなりません。Handoff はこれを BranchIsolationError／blocked_external に分類します。

• 完全版／超詳細版の計画識別子のベースには、HANDOFF_BRANCH_NAME（/ を - に置換）を使用してください。完全版では <configured plans dir>/<stem>.md に書き込み、超詳細版では <configured plans dir>/<stem>/index.md に書き込みます。Step 1.2 のスラッグ生成はスキップしてください。

HANDOFF_MODE が 1 で、HANDOFF_BRANCH_PREPARED が未設定または 0 の場合：

• 準備済みブランチの契約を採用していない旧バージョンの Handoff クライアント向けのフォールバックパスです。
• git.create_branches の設定に従って、通常どおり Step 1.4 のブランチ作成を実行してください。

HANDOFF_MODE が 1 ではない場合（Claude Code の手動セッション）

既存の計画を推敲する場合、計画のエントリーポイントの1行目にある `` アノテーション（存在する場合）から Handoff タスク ID を抽出してください。新しい計画を作成する場合で、アノテーションのコンテキストがなければ、リンクされた Handoff タスクがないため、すべての MCP 同期をスキップしてください。

計画のアノテーションにタスク ID が見つかった場合は、MCP ツールを介して Handoff と同期します。

• 開始時： { taskId: <extracted-id>, newStatus: "planning", sourceTimestamp: "<current UTC time in ISO 8601 format>", direction: "aif_to_handoff", paused: true } を指定して handoff_sync_status を呼び出します。
• 完了時： { taskId: <extracted-id>, planContent: <full plan text> } を指定して handoff_push_plan を呼び出します。超詳細版の場合は、バンドルを index.md に続けてすべての Phase Index ファイルを順番に並べ、それぞれの前に `` を付けてシリアライズします。その後、{ taskId: <extracted-id>, newStatus: "plan_ready", sourceTimestamp: "<current UTC time in ISO 8601 format>", direction: "aif_to_handoff", paused: true } を指定して handoff_sync_status を呼び出します。

重要： done を除き、handoff_sync_status を呼び出すたびに必ず paused: true を渡してください。これにより、手動で作業している間に Handoff の自律エージェントがタスクを取得するのを防ぎます。paused: false を渡すのは done の場合のみです。

計画のエントリーポイントを書き直す際は、1行目の `` アノテーションを保持してください。

Step 0：プロジェクトコンテキストを読み込む

最初に： .ai-factory/config.yaml が存在する場合は読み取り、次の設定を解決します。

• コマンドのデフォルト: workflow.plan_mode（デフォルトは ask、指定可能な値: ask、fast、full、ultra）。値が存在しない場合は ask を使用します。無効な値や型の場合は WARN [config] invalid workflow.plan_mode; falling back to ask を出力し、ask を使用します。
• パス: paths.description、paths.architecture、paths.roadmap、paths.research、paths.rules_file、paths.plan、paths.plans、paths.patches、paths.evolutions、paths.specs、paths.rules、および paths.archive
  • オプトインの ultra リサーチバンドル用に research_bundles_dir = <parent directory of paths.research>/research/ を導出します。追加の設定キーは不要です。
• 言語: language.ui は AskUserQuestion のプロンプト用、language.artifacts は生成されるプランファイル用、language.technical_terms はプラン成果物内の人間が読める技術用語用です
• Git: git.enabled、git.base_branch、git.create_branches、および git.branch_prefix
• ワークフロー: workflow.plan_id_format — full/ultra プラン識別子の形式を制御します。指定可能な値: slug（デフォルト）、timestamp、uuid、sequential。有効なのは slug と sequential のみです。timestamp と uuid は予約済みであり、現在は slug と同様に動作します（INFO ログ付き）。sequential の値は、full プランを <NNNN>_<plan_file_stem>.md として、ultra バンドルを <NNNN>_<plan_file_stem>/index.md として書き込みます（正規の stem とアルゴリズムについてはステップ 1.2 を参照）。未知の値は slug として扱い、WARN [aif-plan] unknown workflow.plan_id_format=<value>; falling back to slug を出力します。

config.yaml が存在しない場合は、デフォルトを使用します:

• パス: すべての成果物に対して .ai-factory/
• ui_language: en
• artifact_language: en
• technical_terms_policy: keep
• Git: enabled: true、base_branch: main、create_branches: true、branch_prefix: feature/
• ワークフロー: plan_id_format: slug

解決された言語値:

• ui_language = language.ui || "en"
• artifact_language = language.artifacts || language.ui || "en"
• technical_terms_policy = language.technical_terms || "keep"

technical_terms_policy が keep、translate、mixed のいずれでもない場合は、keep として扱います。english などのレガシーな値も keep と同様に動作します。

すべての AskUserQuestion プロンプト、進捗更新、サマリー、次のステップのガイダンスは、ui_language で記述しなければなりません（MUST）。

paths.plan または paths.plans の下に生成されるプラン成果物は、artifact_language で記述しなければなりません（MUST）。 ultra の場合、これは index.md およびリンクされたすべてのフェーズファイルに適用されます。

テンプレートと例は構造を定義するものであり、固定された英語の出力ではありません。artifact_language が en でない場合は、保存する前に、人間が読める見出し、ラベル、タスクの文面、ロードマップの根拠、リサーチの要約、設定の説明、依存関係の注記を翻訳してください。markdown 構造、チェックボックス構文、タスク ID、ブランチ名、コミットメッセージ、コマンド、ファイルパス、設定キー、パッケージ名、API 名、WARN/INFO ラベル、生のエラー、および正確な ultra マーカー `` は変更せずに保持してください。## Research Context、Source:、Active Summary、Updated:、SHA256: は、下流のリサーチドリフトチェックが互換性トークンとして解析するため、正確に保持してください。## Requirements Reconciliation は、下流のワークフローチェックが互換性トークンとして解析するため、正確に保持してください。その他の人間が読める用語には technical_terms_policy を適用してください。

例外: ## Original Request のセクション見出しと本文は、固定された生ソース構造であり、翻訳、要約、正規化、書き換えを行ってはなりません。

THEN: .ai-factory/DESCRIPTION.md（設定のパスを使用）が存在する場合は、以下を理解するために読み取ります:

• 技術スタック（言語、フレームワーク、データベース、ORM）
• プロジェクトアーキテクチャ
• コーディング規約
• 非機能要件

ALSO: 解決されたアーキテクチャ成果物が存在する場合は（paths.architecture、デフォルト: .ai-factory/ARCHITECTURE.md）、以下を理解するために読み取ります:

• 選択されたアーキテクチャパターン
• フォルダ構造の規約
• レイヤー/モジュールの境界
• 依存関係のルール

以下の場合にこのコンテキストを使用します:

• コードベースの調査（どのパターンを探すべきかを把握する）
• タスク説明の作成（正しい技術を使用する）
• ファイル構造の計画（プロジェクトの慣習に従う）
• ファイル構造とタスク構成を計画する際は、解決されたアーキテクチャ成果物のアーキテクチャガイドラインに従う

さらに: 存在する場合は、解決されたルール階層を読み取ります：

1. paths.rules_file — プロジェクト全体の原則
2. rules.base — プロジェクトの基本慣習
3. 要求された作業に関連する名前付きの rules.<area> エントリ

明示的なルールは権威ある要件として扱います。より具体的なエリアルールは 基本ルールを上書きし、基本ルールはプロジェクト全体の原則を上書きします。

.ai-factory/skill-context/aif-plan/SKILL.md を読み取る — ファイルが存在する場合は必須です。

このファイルには、/aif-evolve によってパッチ、コードベースの慣習、 技術スタック分析から蓄積されたプロジェクト固有のルールが含まれています。これらのルールは現在のプロジェクトに合わせて調整されています。

skill-context ルールの適用方法:

• このスキルの一般指示に対する プロジェクトレベルのオーバーライド として扱います
• skill-context ルールがこの SKILL.md に書かれた一般ルールと競合する場合、 skill-context ルールが優先されます（より具体的なコンテキストが優先される — ネストされた CLAUDE.md ファイルと同じ原則です）
• 競合がない場合は、両方を適用します：SKILL.md の一般ルール + skill-context のプロジェクトルール
• skill-context ルールがこのスキルのデフォルトと矛盾しているように見えても無視しないでください — これらはプロジェクトの経験がデフォルトでは不十分であると証明したために存在しています
• 重要: skill-context ルールはこのスキルのすべての出力に適用されます — これには PLAN.md テンプレート、ultra バンドル、タスク形式が含まれます。TASK-FORMAT.md と ULTRA-FORMAT.md のテンプレートは 基本構造 です。skill-context ルールが 「タスクに X を含めなければならない」または「計画にセクション Y が必要」と述べている場合は、それに応じて テンプレートを拡張しなければなりません。skill-context ルールに違反する計画を生成することはバグです。

強制: 出力成果物を生成した後、すべての skill-context ルールに対して検証します。 いずれかのルールに違反している場合は、ユーザーに提示する前に出力を修正します。

任意（推奨）: 存在する場合は、解決されたロードマップ成果物（paths.roadmap、デフォルト: .ai-factory/ROADMAP.md）を読み取ります：

• 該当する場合、この計画を特定のマイルストーンにリンクするために使用します
• これにより、/aif-implement のマイルストーン完了と /aif-verify のロードマップゲートにおける曖昧さが軽減されます

任意（推奨）: 関連する研究ソースを最大 1 つ解決します：

• レガシーソースは、設定されている paths.research ファイルです。
• Ultra ソースは research_bundles_dir/<english-slug>/RESEARCH.md です。ただし、兄弟ファイルの INDEX.md に `` がちょうど 1 回含まれ、かつ ## Artifact Index からその RESEARCH.md にリンクされている場合に限ります。任意のディレクトリをリサーチバンドルとして扱わないでください。
• ユーザーがトピックまたは依頼を提示した場合のソースの優先順位は、明示的に指定されたバンドル／ファイル、次に明確にトピックが一致する Status: active のバンドル 1 つ、次に関連するレガシーファイルです。明示的なソースとは、依頼またはフォローアップで名前が指定された具体的な RESEARCH.md またはバンドルパスです。これはユーザーのコンテンツであり、コマンドトークンとして取り除かれるものではありません。
• トピックの一致は、まず完全一致する英語スラッグ、次に正規化した Topic: の一致、次に Purpose／Active Summary との一意な意味上の一致で判断します。新しさで選ばないでください。単一の候補が明確でない場合や、複数のソースによって対象範囲が変わる場合は、統合したり推測したりせず、ユーザーに確認してください。明示的に指定された paused または superseded のバンドルを使用する場合は、使用前に警告してください。
• まず Ultra の INDEX.md を読み、次にリンク先の RESEARCH.md を読んでください。C4／ADR／依存関係の成果物は、この計画に必要な根拠を得る場合にのみ読みます。これらは独立した要件ソースではありません。重要な結論は、すでに Active Summary に反映されている必要があります。
• 選択したファイルを selected_research_path として保存してください。その ## Active Summary (input for /aif-plan) を追加の要件ソースとして扱ってください。
• 制約や決定事項をタスクと計画設定に引き継いでください。
• 生のメモよりもサマリーを優先してください。より詳しい根拠が必要な場合に限り、## Sessions とリンクされた任意の成果物を参照してください。
• 説明がない場合のフォールバックは、トピックベースの優先順位に対する意図的な後方互換性の例外です。利用可能であれば、設定された paths.research の Active Summary のトピックを使用してください。そうでない場合は、Status: active の Ultra バンドルを 1 つ使用します。有効なバンドルが複数ある場合は、推測せずユーザーに選択を求めてください。
• リサーチ内容がこの計画に影響したかどうかを記録してください。Active Summary がデフォルトの説明を提供する場合、またはリサーチ成果物の制約、決定事項、目標、未解決の質問、セッションで得られた根拠が計画の対象範囲、タスク、設定、トレードオフに影響する場合に限り、research_influenced_plan = true と設定してください。リサーチ成果物が存在していても、古い、またはユーザーの依頼したタスクと無関係な場合は、research_influenced_plan = false のままにし、計画要件には適用せず、## Research Context を追加しないでください。
• リサーチ内容が計画に影響する場合、生成される計画には、正規形式の Source: `<selected_research_path>` (Active Summary, Updated: <timestamp>, SHA256: <digest>) メタデータを含む ## Research Context を必ず記載してください。計画側にコピーされるこのリサーチ情報を省略すると不具合になります。後続のスキルは、埋め込まれた Research Context を権威ある要件として扱い、元のリサーチファイルは差分確認にのみ使用するためです。
• ハッシュ計算の前に、コピーした Active Summary を正規化してください。Source: 行の後に ## Research Context の下へ貼り付けるテキストのみを含め、HTML コメントブロックを削除し、行の順序と先頭の空白を保持し、すべての行末の空白を削除し、LF 改行を使用して、末尾を改行 1 つだけで終わらせてください。一時ファイルやリポジトリ成果物を書き込まずにダイジェストを計算します。正規化したテキストを stdin／インラインのシェル入力から shasum -a 256 に渡してください。shasum を利用できない場合は、同じ正規化テキストを sha256sum に渡してください。出力の最初のフィールドを SHA256: の値として使用してください。

Step 0.1: Git の状態を解決する

git init を自動実行しないでください。

まず設定から現在の Git モードを解決します。

• git.enabled: true → Git を考慮したワークフローが使用できます
• git.enabled: false → Git を使用しないワークフローのみ
• git.base_branch → 差分／マージの案内で対象とするブランチ（デフォルト：検出されたブランチ、または main）
• git.create_branches: true → full／ultra モードでブランチ／worktreeを作成できます
• git.create_branches: false → full／ultra モードでもプランの成果物は作成しますが、現在のブランチ／リポジトリの状態を維持します

git.enabled = false の場合：

• ブランチ／worktree に関するすべてのコマンドをスキップします
• full プランは paths.plans/<slug>.md に、ultra バンドルは paths.plans/<slug>/index.md に保存します
• --parallel、--list、--cleanup は使用できないものとして扱います

git.enabled = true でも、リポジトリが実際には Git ワークツリー内にない場合：

• リポジトリが初期化されるまで、Git を考慮した操作は使用できないことをユーザーに警告します
• 上記と同じ Git を使用しない動作にフォールバックします

Step 0.2: 引数を解析してモードを選択する

$ARGUMENTS からフラグとモードを抽出します。

--parallel  → Enable parallel worktree mode (full/ultra only; requires `git.enabled=true` and `git.create_branches=true`)
--list      → Show all active worktrees, then STOP (git-only)
--cleanup <branch> → Remove worktree and optionally delete branch, then STOP (git-only)
fast        → Fast mode (first word)
full        → Full mode (first word)
ultra       → Ultra mode (first word)

解析ルール：

• $ARGUMENTS から、コマンド位置にある認識済みのコマンドトークンのみを除去します。
  • fast、full、ultra は、先頭のモードトークンとして使われている場合に限ります
  • 認識済みの制御フラグ --parallel、--list、および --cleanup <branch>
  • ユーザーの実際のリクエスト文中にある一致する語は除去しません
• 残りのテキストを説明として扱います
• 設定済みのデフォルト値は個別に解決します。$ARGUMENTS の先頭に付加したり、original_user_request に含めたりしないでください。
• 残りのテキストが空でない場合は、original_user_request として保持します。コマンド解析によって生じた外側の空白のみをトリミングし、内部の空白、改行、表現、大文字・小文字、句読点はそのまま維持します。これはユーザーの元の計画リクエストであり、後でプランのエントリーポイントに必ず保存する必要があります。
• --list と --cleanup はただちに実行して停止します（Step 1 以降には進みません）。
• git.enabled = false の場合は、Git コマンドを試す代わりに、簡潔な説明を添えて --parallel、--list、--cleanup を拒否します
• git.create_branches = false のときに --parallel が指定されている場合は、並列モードにはブランチ作成が必要なため、簡潔な説明を添えて拒否します

--list がある場合は、--list Subcommand に進みます。 --cleanup がある場合は、--cleanup Subcommand に進みます。

モードの選択（1 回だけ解決し、説明とは独立させます）：

• 明示的な先頭の fast、full、ultra トークンがあれば、設定より優先します。
• それ以外の場合、workflow.plan_mode: fast|full|ultra がそのモードを選択します。この場合、モード選択の質問はしません。full／ultra の優先設定に関する質問と Git の制限は引き続き適用されます。
• それ以外（ask、設定なし、または無効な設定）の場合、非対話型の Handoff モードでは fast を使用し、対話型セッションでは以下の質問で full と fast のどちらかを尋ねます。
• ultra は明示的なオプトインのみです。先頭の ultra トークン、または workflow.plan_mode: ultra によって選択します。タスクの複雑さから推測して選択してはいけません。
• 選択したモードを resolved_mode として保存します。以下の説明の解決時に、モードの選択をやり直したり、resolved_mode を変更したりしてはいけません。
• 設定されたモードにかかわらず、--list と --cleanup は早期リターンの動作を維持します。

明示的なモードが指定されておらず、設定された優先設定が ask に解決され、セッションが対話型の場合に限り、次の質問をします。

AskUserQuestion: Which planning mode?

Options:
1. Full (Recommended) — richer plan, asks preferences, optional branch/worktree flow when git settings allow it
2. Fast – quick plan, no branch, saves to the resolved fast plan path

説明が空の場合：

• 設定された paths.research ファイルが存在し、その Active Summary の Topic: が空でない場合、デフォルトの説明としてそのトピックを使用します（ユーザーからの追加情報は不要です）。これを selected_research_path に設定し、original_user_request は空のままにします。
• それ以外の場合、マークされたアクティブな ultra バンドルがちょうど 1 つ存在し、リンク先の RESEARCH.md の Topic: が空でない場合は、そのトピックとファイルを使用します。マークされたアクティブなバンドルが複数存在する場合は、トピック／ソースを選択するようユーザーに尋ねます。
• リサーチから説明を取得した場合は、選択された Active Summary のトピックに触れて、設定された ultra を含む resolved_mode で続行します。モードについて再度質問したり、説明を求めたりしません。
• 明示的なユーザーリクエストなしに、選択した RESEARCH.md から作成されたプランには、Original Request セクションを含めてはいけません。
• それ以外の場合は、簡潔な機能の説明をユーザーに尋ねます。ユーザーの回答は original_user_request として一字一句そのまま保持し、後でプランのエントリーポイントに保存します。

Original request の規約：

• ユーザーが明示的にプラン作成をリクエストした場合（例：/aif-plan ТУТ ЗАПРОС НА ПЛАН、/aif-plan full ТУТ ЗАПРОС НА ПЛАН、/aif-plan ultra ТУТ ЗАПРОС НА ПЛАН、または説明を求めるプロンプトへの回答）、生成されるプランのエントリーポイントには ## Original Request を含める必要があります。
• ## Original Request には、認識されたコマンドトークンのみを削除し、前後の空白のみを取り除いた、ユーザーが入力したリクエストのテキストをそのまま記載します。artifact_language が異なる場合でも、表現を書き換えたり、要約、翻訳、正規化したりしてはいけません。
• ユーザーがリクエストを入力せず、選択した RESEARCH.md のみから説明を取得した場合は、## Original Request を省略します。この場合、確定したソースは ## Research Context です。
• ユーザーがリクエストを入力し、選択したリサーチもプランに影響した場合は、## Original Request と ## Research Context の両方を含めます。

コマンドの形式ごとの具体的な解析例と期待される動作については、references/EXAMPLES.md（引数の解析）を参照してください。

---

Full and Ultra Modes

Step 1: 説明と事前調査の解析

説明から、以下を抽出します。

• 追加される中核機能
• 主要なドメイン用語
• 種別（機能、機能強化、修正、リファクタリング）

Task ツールを subagent_type: Explore とともに使用して、コードベースの関連部分を把握します。 これはサブエージェントとして実行されるため、メインのコンテキストを整理した状態に保てます。

解析した説明に基づいて、Explore エージェントを 1～2 個、並行して起動します。

Task(subagent_type: Explore, model: sonnet, prompt:
  "In [project root], find files and modules related to [feature domain keywords].
   Report: key directories, relevant files, existing patterns, integration points.
   Thoroughness: quick. Be concise — return a structured summary, not file contents.")

ルール：

• Full：最大 1～2 個のエージェント。「quick」レベルで調査します。これは事前調査であり、詳細な分析ではありません。
• Ultra：可能であれば、焦点を絞ったエージェントを 2～3 個使用します。アーキテクチャ、既存のパターン、統合と副作用、テスト／運用の各領域を調査します。この事前調査は、ULTRA-FORMAT.md が求める、より深い根拠の収集に役立ちます。
• 詳細な調査は後の Step 3 で行います。
• .ai-factory/DESCRIPTION.md にすでに十分なコンテキストが記載されている場合、このステップは省略できます。

Step 1.2: Full／Ultra プラン識別子の生成

このステップでは、異なる 2 つの値を生成します。

• branch_name — Git ブランチ名（git.enabled = true かつ git.create_branches = true の場合のみ）
• plan_file_stem — <configured plans dir>/ 配下で使用する、プレフィックスなしの正規プラン名
• plan_identifier — plan_file_stem に任意の NNNN_ プレフィックスを付けたもの。Full プランのファイル名の幹、または Ultra ディレクトリ名になります。

これらは固定された順序で導出されます。これにより、ここで生成する値と、/aif-implement／/aif-improve／/aif-verify／/aif-rules-check のブランチベースの処理で、Full プランのファイルまたは Ultra のエントリーポイントが常に一致します。

1.2.a — 正規の plan_file_stem を解決する

最初に一致したケースを選びます。

1. HANDOFF_BRANCH_PREPARED = 1 → / をすべて - に置き換えた HANDOFF_BRANCH_NAME を plan_file_stem に設定します。スラッグの生成は完全に省略します。ここでは branch_name を作成しません（ブランチはすでに Handoff が所有しています）。
2. git.enabled = true AND git.create_branches = true → 説明文のスラッグを生成し、branch_name = <git.branch_prefix><slug> とします（デフォルトのプレフィックス：feature/）。/ をすべて - に置き換えた branch_name を plan_file_stem に設定します（例：feature-user-authentication）。
3. それ以外の場合（git.enabled = false OR git.create_branches = false）→ plan_file_stem = <description slug> とします。branch_name は作成しません。

スラッグのルール（ケース 2 と 3）：

• 小文字、ハイフン区切り、最大 50 文字
• ハイフン以外の特殊文字は使用しません
• 説明的でありながら簡潔にします

ブランチの例（ケース 2）：

• feature/user-authentication
• fix/cart-total-calculation
• refactor/api-error-handling
• chore/upgrade-dependencies

不変条件： ブランチベースのコンシューマースキルは、/ を置き換えた現在のブランチ名を検索用のステムとして計算します。上記のケース 1 と 2 はすでにこの形式に一致します。ケース 3 ではブランチがないため、コンシューマーは <configured plans dir>/ 内にある単独の full/ultra プラン成果物にフォールバックします（aif-implement の Step 0.2 を参照）。これらのルールに従わない plan_file_stem を生成すると、検出に失敗します。

1.2.b — workflow.plan_id_format のプレフィックスを適用する

デフォルトではプレフィックスなしです。plan_identifier = plan_file_stem とします。full は <configured plans dir>/<plan_identifier>.md に書き込み、ultra は <configured plans dir>/<plan_identifier>/index.md に書き込みます。

形式ごとの処理：

• slug（デフォルト）→ プレフィックスなし。
• timestamp / uuid → 予約済みの値であり、現時点では slug として扱います。 INFO [aif-plan] workflow.plan_id_format=<value> is reserved and behaves like slug; numbering is not applied を出力します。ステムの形式を独自に作成してはいけません。ブランチベースのコンシューマーは、sequential 以外のプレフィックスを検出できません。
• 不明な値 → Step 0 ですでに処理済みです。WARN [aif-plan] unknown workflow.plan_id_format=<value>; falling back to slug を出力します。ここでは slug として扱います。
• sequential → 1.2.c のアルゴリズムを plan_file_stem に適用して、 plan_identifier を生成します。

HANDOFF_BRANCH_PREPARED = 1 の場合、sequential は強制的に無効化されます。この場合はプレフィックスのない plan_file_stem をそのまま使用し、INFO [aif-plan] sequential numbering disabled under HANDOFF_BRANCH_PREPARED=1 を出力します。

1.2.c — 連番付与アルゴリズム

plan_file_stem の先頭に4桁の数値プレフィックスを付けて、 plan_identifier を生成します。<configured plans dir> 内の既存の番号付きフルプランファイルと、 index.md に完全一致する ultra マーカーが含まれる番号付きディレクトリから プレフィックスを計算します。ブランチ名がある場合はそのまま維持されるため、 既存の git ツール、CI、PR の規約に影響しません。

1. Find existing numbered plans in <configured plans dir>:
     Glob A: <configured plans dir>/[0-9][0-9][0-9][0-9]_*.md
     Glob B: <configured plans dir>/[0-9][0-9][0-9][0-9]_*/index.md
2. Every Glob A match is a numbered full-plan candidate.
   For every Glob B match, Read index.md and keep it only when it contains the
   exact marker . Ignore numbered directories whose
   index.md lacks the marker; they are not plans and cannot consume an ID.
3. Parse the leading 4 digits from each retained full-plan filename or marked
   ultra directory
   basename into an integer. Deduplicate equal prefixes.
   Filter out entries whose relevant basename does not match
   ^[0-9]{4}_.+(\.md)?$.
4. If any matches exist:
     max_existing = max(prefixes)
     If max_existing >= 9999:
       ABORT with error:
         "sequential cap reached: a plan numbered 9999 already exists in <configured plans dir>."
         "Switch workflow.plan_id_format back to slug, or move the 9999-numbered file out of the directory (note: doing so will free 9999 for the next plan to reuse)."
     next = max_existing + 1
   Else:
     next = 1
5. prefix = zero-padded 4-digit string of next   (e.g. 1 → "0001", 42 → "0042")
6. Set plan_identifier = <prefix>_<plan_file_stem>
7. Final artifact:
     full  → <configured plans dir>/<plan_identifier>.md
     ultra → <configured plans dir>/<plan_identifier>/index.md

実装上の注意：

• Glob で候補を列挙し、Read ですべての番号付き ultra 候補のマーカーを検証します。 ls をシェルから実行してはいけません。aif-plan の frontmatter では Bash(ls *) が許可されていないため、ls を使う方法は本番環境で失敗します。
• 4桁の [0-9][0-9][0-9][0-9] glob は、契約上厳密です。この形式では 0001～9999 のみをサポートします。ステップ4のエラーでこの制約を適用します。
• --parallel のスコープ（要約 — ソースワークツリーを基準とします）：
  • プレフィックスを計算する場所： ソースワークツリーの <configured plans dir>（/aif-plan を実行したリポジトリ）。つまり、ステップ1.2.cのここです。
  • 計算するタイミング： ステップ1.4で任意の cd <WORKTREE> を実行する前です。
  • プラン成果物を書き込む場所： ターゲットワークツリー内の同じ相対パスにあるフルファイルまたは ultra ディレクトリです。これにより、プレフィックスと保存先ディレクトリの整合性が保たれます。
  • してはいけないこと： cd <WORKTREE> の後、ターゲットワークツリーの plans dir からプレフィックスを再計算してはいけません。通常、ターゲットディレクトリは空であり、実行のたびに 0001 が再割り当てされ、マージ時にワークツリー間の連番に関する契約が破られます。

ルール：

• 番号は、<configured plans dir> 内の既存のフルプランファイルと、マーカー付き ultra ディレクトリから決定されます。マーカーのない番号付きディレクトリは無視されます。番号付きプランをディレクトリ外に削除または移動すると、次回の実行時にその番号が再利用可能になります。安定した相互参照が必要な場合は、プランを所定の場所に維持してください。
• アーカイブ済みのプランは連番の対象外です。 /aif-archive によって paths.archive/plans/ に移動されたプランは <configured plans dir> 内にないため、カウントされません。最大番号のプランをアーカイブすると、その番号は再利用可能になります。
• 連番には上限があります。9999 が上限であり、コンシューマー側の glob（こちらも4桁）が契約から外れないよう、アルゴリズムは 10000_… を書き込まずにエラーを返します。
• プレフィックスが付くのはフルプランのファイル名または ultra ディレクトリ名のみです。git ブランチがある場合も、番号なしの <branch_prefix><slug> のままです。
• この設定は、fast プラン（paths.plan が単一ファイル）と fix プラン（paths.fix_plan が単一ファイル）では無視されます。

ログ：INFO [aif-plan] resolved plan artifact: <path> (mode=<mode>, format=<value>)。

ステップ1.3：設定について確認する

重要：続行する前に必ずユーザーに確認してください。

AskUserQuestion: Before we start, a few questions:

1. Should I write tests for this feature?
   a. Yes, write tests
   b. No, skip tests

2. Logging level for implementation:
   a. Verbose (recommended) - detailed DEBUG logs for development
   b. Standard - INFO level, key events only
   c. Minimal - only WARN/ERROR

3. Documentation policy after implementation?
   a. Yes — mandatory docs checkpoint at completion (recommended)
   b. No — warn-only (`WARN [docs]`), no mandatory checkpoint

4. Roadmap milestone linkage (only if the resolved roadmap artifact exists):
   a. Link this plan to a milestone
   b. Skip — no linkage (allowed; `/aif-verify --strict` should report WARN, not fail, for missing linkage alone)

5. Any specific requirements or constraints?

詳細なログ出力をデフォルトにしてください。 AI が生成したコードでは、詳細なログ出力が大いに役立ちます。その理由は次のとおりです。

• 微妙なバグはよく発生し、ログがないと追跡が困難です
• ユーザーは後からいつでもログを削除できます
• 開発中にログが不足すると、デバッグに時間がかかります

すべての設定を保存してください。プランのエントリーポイントで使用し、/aif-implement に渡します。

ドキュメントポリシーの動作：

• Docs: yes → /aif-implement は必須のドキュメント確認ポイントを表示し、ドキュメントの変更を /aif-docs に振り分ける必要があります
• Docs: no（または未設定）→ /aif-implement は WARN [docs] を出力し、必須のドキュメント確認ポイントを設けずに続行します

解決済みのロードマップ成果物が存在し、ユーザーがマイルストーンとの関連付けを選択した場合：

• 解決済みのロードマップ成果物を読み込み、候補となるマイルストーンを列挙します（未チェック項目を優先してください）
• ユーザーにマイルストーンを1つ選択するか、任意の項目を入力するよう求めます
• 選択したマイルストーン名と、プランのエントリーポイントに含める理由を1文で保存します

Step 1.4: オプションのブランチ／ワークツリー設定

HANDOFF_BRANCH_PREPARED = 1 の場合（Handoff がブランチを管理します）：

• このステップ全体をスキップします。ブランチの検証は Step 0 ですでに完了しています。
• 計画アーティファクトのパスでは、HANDOFF_BRANCH_NAME（スラッシュを - に置換）を名前の先頭部分として使用します。
• git checkout、git pull、git checkout -b、git worktree add は実行しないでください。
• --parallel は無効として扱います。ワークツリーを作成せず、/aif-implement も自動で呼び出さないでください。

git.enabled = false または git.create_branches = false の場合：

• ブランチ／ワークツリーの作成をすべてスキップします
• paths.plans 配下に生成された完全なファイルまたは ultra ディレクトリを使用して続行します

--parallel フラグが設定されている場合 → ワークツリーを作成します：

連番のプレフィックスはすでに確定しています。 このステップの前に、 Step 1.2.c でソースワークツリーの <configured plans dir> を基に NNNN_ プレフィックスを計算しました。 cd <WORKTREE> の後に再計算しないでください。ターゲットワークツリーの plans dir は 通常は空なので、0001 が再割り当てされ、マージ時の番号付けの 契約が破られます。

ワークツリーの作成

DIRNAME=$(basename "$(pwd)")
git branch <branch-name> <configured-base-branch>
git worktree add ../${DIRNAME}-<branch-name-with-hyphens> <branch-name>

ディレクトリ名に使うブランチ名に変換します：/ を - に置き換えます。

例：

Project dir: my-project
Branch: feature/user-auth
Worktree: ../my-project-feature-user-auth

ワークツリーで AI コンテキスト全体を利用できるよう、コンテキストファイルをコピーします：

• 解決済みの DESCRIPTION、ARCHITECTURE、RESEARCH、plan、patch、evolution の各パスについて、ワークツリー内に親ディレクトリを作成します。
• 解決済みの DESCRIPTION、ARCHITECTURE、RESEARCH の各アーティファクトを、ワークツリー内の同じ設定相対パスにコピーします。
• .ai-factory/skill-context/ をそのままワークツリーにコピーします。
• 解決済みの paths.patches ディレクトリから最新の patch ファイルを 10 個だけ、ワークツリー内の同じ設定相対パスにコピーします。
• 切り詰めた patch セットだけをコピーした場合は、patch-cursor.json をコピーしないでください。このカーソルは patch 履歴全体がある場合にのみ有効です。
• エージェント設定（例：.claude/）と、存在する場合は未追跡の CLAUDE.md をコピーします。

changes ディレクトリを作成して切り替えます：

cd "${WORKTREE}"

確認を表示します：

Parallel worktree created!

  Branch:    <branch-name>
  Directory: <worktree-path>

To manage worktrees later:
  /aif-plan --list
  /aif-plan --cleanup <branch-name>

Step 2 に進みます。

--parallel を指定していない場合 → 通常どおりブランチを作成します：

git checkout <configured-base-branch>
git pull origin <configured-base-branch>
git checkout -b <branch-name>

ブランチがすでに存在する場合は、ユーザーに確認します：

• 既存のブランチに切り替えますか？
• 別の名前で作成しますか？

---

Ultra モードの詳細要件

Ultra は、上記のフルモードの設定とオプションのブランチ／ワークツリー設定を使用したうえで、 より厳格な計画ゲートを適用します：

1. references/ULTRA-FORMAT.md を最後まで読みます。
2. 実装者が推測せずに済むよう、横断的な判断をすべて確定します。該当する場合は、ファイルの配置、公開インターフェイス、データ／制御フロー、互換性、移行、障害時の動作、可観測性、テスト、ドキュメント、ロールアウトを含みます。
3. 作業を依存関係の順にフェーズへ分割します。フェーズは一貫した実装のチェックポイントとし、単なるカテゴリ見出しにしてはいけません。
4. フェーズごとに Markdown ファイルを 1 つ作成します。すべてのタスクセクションで、ULTRA-FORMAT.md の必須詳細要件を満たす必要があります。
5. フェーズの内容が安定した後、最後に index.md を作成します。これにより、Phase Index、タスクリンク、依存関係、コミットグループをフェーズファイルと完全に一致させます。
6. 計画を提示する前に、ULTRA-FORMAT.md に記載されたバンドル整合性チェックを実行します。リンク切れ、タスク ID の欠落／重複、対応するフェーズがないファイル、依存関係の不整合を修正します。

Ultra では、重要な実装上の判断を小規模なモデルに先送りしてはいけません。 安全に判断するための根拠が不十分な場合は、index.md にブロッキングとなる未解決の質問を記録し、曖昧な指示で問題を隠すのではなく、実装準備ができていない計画として停止します。

---

Fast モード

Step 1: 設定について質問する

質問項目を減らします：

AskUserQuestion: Before we start:

1. Should I include tests in the plan?
   a. Yes, include tests
   b. No, skip tests

2. Any specific requirements or constraints?

3. Roadmap milestone linkage (only if the resolved roadmap artifact exists):
   a. Link this plan to a milestone
   b. Skip — no linkage (allowed; `/aif-verify --strict` should report WARN, not fail, for missing linkage alone)

計画ファイル： 常に解決済みの paths.plan ファイルを使用します（デフォルト：.ai-factory/PLAN.md）。

---

共通ステップ（すべてのモード）

Step 2: 要件を分析する

説明から、以下を特定します：

• 実装するコア機能
• 変更が必要なコンポーネント／ファイル
• タスク間の依存関係
• 対応すべきエッジケース

要件が曖昧な場合は、明確化のために質問します：

I need a few clarifications before creating the plan:
1. [Specific question about scope]
2. [Question about approach]

要件の照合ゲート

既存の要件が適用される作業では、実装の調査に入る前に要件を照合します。

1. プロジェクトで明示的に別の定めがない限り、ロードマップ項目とタスク概要は、詳細な動作契約ではなく、スコープの目安として扱います。
2. ユーザーまたはプロジェクトのコンテキストで定められた情報源の優先順位に従います。優先順位が定められていない場合は、矛盾する情報源のどちらかを黙って選ばないでください。
3. 各重要な動作ルールについて、出典のパス／セクションを記録します。複数の情報源が重複する場合、それらが一致しているのか、一方が他方を補足しているのか、または矛盾しているのかを明記します。未解決の矛盾によって実装が変わる場合：
   • 手動モード → ユーザーに確認して、停止します。
   • HANDOFF_MODE=1 → プロンプトを表示しません。ERROR [requirement-conflict] を出力し、handoff_outcome: blocked_external を返して、公開も plan_ready の通知も行わずに停止します。
4. 計画の作成中に要件のソースを編集しないでください。古くなった、または矛盾する成果物を報告し、その所有者のコマンドまたはユーザーに対応を依頼します。

動作が2つ以上の独立したセレクター、状態、モード、または入力形式に依存する場合は、タスクを作成する前に、サポートされる組み合わせを列挙します。要件で許可されている組み合わせのみを対象とし、推測上の直積は対象にしません。重要な組み合わせごとに、次の内容を指定します。

• 受け付ける入力と検証内容。
• 永続化される状態。
• 返される出力または次の遷移。
• 副作用と不変条件。
• 検証シナリオを1つ。テストが有効な場合はテストとし、そうでない場合は、テストタスクを追加せずに、実行可能な手動検証手順を提示します。

リポジトリのデータ、設定、フィクスチャ、スキーマ、またはコンテンツが実際の契約を定めている場合、合成フィクスチャのみで検証するのではなく、既存の代表的な成果物を少なくとも1つ、エンドツーエンドの検証経路に含めます。

複数の権威ある情報源が作業を実質的に制約している場合、矛盾が解決された場合、独立した動作の軸が存在する場合、または代表的な実成果物が必要な場合は、計画のエントリーポイントに正確な ## Requirements Reconciliation セクションを追加します。内容は簡潔にまとめ、定められた権威、出典を明記した判断、該当する組み合わせの表、検証の証拠を記載します。これらの条件がいずれも当てはまらない単純な作業では、このセクションを省略します。

Step 3: コードベースを調査する

計画を立てる前に、並行調査を通じて既存のコードを把握します。

**subagent_type: Explore を指定して Task ツールを使い、コードベースを並行して調査します。**これにより、メインのコンテキストを整理したまま、調査を迅速に進められます。

それぞれ異なる観点に焦点を当てた Explore エージェントを2～3個、同時に起動します。

Agent 1 — Architecture & affected modules:
Task(subagent_type: Explore, model: sonnet, prompt:
  "Find files and modules related to [feature domain]. Map the directory structure,
   key entry points, and how modules interact. Thoroughness: medium.")

Agent 2 — Existing patterns & conventions:
Task(subagent_type: Explore, model: sonnet, prompt:
  "Find examples of similar functionality already implemented in the project.
   Show patterns for [relevant patterns: API endpoints, services, models, etc.].
   Thoroughness: medium.")

Agent 3 — Dependencies & integration points (if needed):
Task(subagent_type: Explore, model: sonnet, prompt:
  "Find all files that import/use [module/service]. Identify integration points
   and potential side effects of changes. Thoroughness: medium.")

Step 1で full/ultra モードによるコードベースの調査が完了している場合は、その結果を出発点として使用します。Explore エージェントには、より詳しい理解が必要な領域を調査させます。

ultra モードでは、各フェーズの計画にコードレベルの根拠が示されるまで調査を続けます。

• 関連する既存のパスとシンボル
• 呼び出し元／利用側と副作用
• 正確な統合ポイントと設定ポイント
• 既存のテスト、フィクスチャ、コマンド、ログ記録、マイグレーション、ドキュメントのパターン

フェーズの計画にソースファイル全体を貼り付けないでください。実装手順を明確に定めるために必要な根拠のみを示します。

エージェントからの応答を受け取ったら、次の内容をまとめます。

• 作成／変更が必要なファイル
• 従うべきパターン（既存コードから）
• コンポーネント間の依存関係
• 潜在的なリスクやエッジケース

代替手段： Task ツールが利用できない場合は、Glob／Grep／Read を直接使用します。

ステップ 4：タスク計画を作成する

TaskCreate を使って、明確で実行可能な項目をタスクとして作成します。

タスクのガイドライン：

• 各タスクは、1 回の集中した作業セッションで完了できるものにします
• タスクは依存関係に沿った順序にします（Y の前に X を行うなど）
• 変更を加えるファイルパスを含めます
• 曖昧な表現を避け、実装する内容を具体的に記載します
• ultra では、TaskCreate の説明を簡潔にしつつ、対応するフェーズのファイルリンクを含めます。バンドルは、コンテキストのリセット後も参照できる詳細な情報源として維持します

TaskUpdate を使って blockedBy の関係を設定します。

• タスク 2 がタスク 1 の出力に依存する場合、タスク 2 はタスク 1 によってブロックされるように設定します
• 依存関係の連鎖が論理的になるようにします

ステップ 5：計画アーティファクトを保存する

計画アーティファクトのパスを決定します： 値はステップ 1.2 ですでに解決されています。

• Fast モード → 解決済みの paths.plan。
• Full モード → <configured plans dir>/<plan_identifier>.md。
• Ultra モード → <configured plans dir>/<plan_identifier>/index.md と、同じディレクトリ内の phase-NN-<slug>.md ファイル。
• slug、予約済みの timestamp / uuid、または Handoff で準備されたブランチの場合、plan_identifier = plan_file_stem。
• 有効な sequential の場合、plan_identifier = <NNNN>_<plan_file_stem>。

plan_file_stem は、ステップ 1.2.a で決定した正規のステム（Handoff ブランチ / git ブランチ / 説明の slug の順）を必ず使用します。ブランチベースのコンシューマーは検索時に同じステムを再現するため、作成側も別のステムを使用してはいけません。

プレフィックスなしの full/ultra の保存先（デフォルト／予約済み slug の動作、または Handoff で準備されたブランチ）に書き込む前に、同じステムを持つ兄弟表現（<plan_identifier>.md と <plan_identifier>/index.md）がないか確認します。どちらかがすでに存在する場合、2 つ目の有効な表現を黙って作成したり、既存のものを上書きしたりしてはいけません。既存の計画を修正するか、別の識別子を選ぶか、明示的に置き換えるかをユーザーに確認します。

保存する前に、ディレクトリが存在することを確認します：

mkdir -p <configured plans dir>

ultra の場合は、ファイルを書き込む前に、解決済みのバンドルディレクトリも作成します。

Full/fast の計画ファイル、または ultra の index.md に含める内容：

• ultra の場合のみ、機械可読な正確なマーカーを index.md の冒頭近くに 1 回だけ記載します（最初の行に Handoff 注釈がある場合は、その直後）。このマーカーを翻訳、書き換え、または省略してはいけません。コンシューマーは Mode のようなローカライズされた人間向けラベルではなく、このマーカーを使ってバンドルを識別します。
• 機能名を含むタイトル
• ブランチと作成日
• Original Request セクション（ユーザーが計画リクエストを明示的に指定した場合は必須。計画が RESEARCH.md のみをもとに作成された場合は省略）
• Settings セクション（Testing、Logging、Docs）
• Roadmap Linkage セクション（任意。解決済みのロードマップアーティファクトが存在する場合のみ）
• Research Context セクション（任意。調査内容がこの計画に影響した場合のみ）
• Requirements Reconciliation セクション（条件付き。ステップ 2 のゲートで必要とされた場合）
• フェーズごとにまとめた Tasks セクション。ultra では、タスクのチェックボックスを記載するのはこのセクションのみです
• タスクが 5 件以上の場合は Commit Plan セクション

original_user_request が空でない場合：

• ## Settings の前に ## Original Request を記載します
• 認識済みのコマンドトークンのみを削除し、前後の空白のみをトリミングしたうえで、ユーザーが提供したリクエストのテキストを正確に保持します
• 保存するリクエストは翻訳しません。これは生成されたアーティファクトの文章ではなく、生の入力テキストです

解決済みのロードマップアーティファクトが存在する場合：

• ユーザーがマイルストーンへの関連付けを指定した場合、## Roadmap Linkage に Milestone: "..." と Rationale: ... を記載します
• ユーザーが関連付けを省略した場合、## Roadmap Linkage に Milestone: "none" と Rationale: "Skipped by user" を記載します

調査内容がこの計画に影響した場合：

• ## Research Contextを含める場合は、Active Summaryのみをコピーしてください（Sessions全体は貼り付けないでください）。
• Source: `<selected_research_path>` (Active Summary, Updated: <research Updated timestamp>, SHA256: <sha256 of copied Active Summary>)を含めてください。これにより、/aif-implement、/aif-verify、/aif-improveおよび関連するコンシューマーが、正確なコミット済みリサーチのリビジョンを把握できます。
• Step 0の説明どおりに正規化したコピー済みActive Summaryからハッシュを計算してください。HTMLコメントブロックを削除し、行の順序と先頭の空白を保持し、各行末の空白を削除し、改行コードをLFにし、末尾を改行1つだけにしてください。正規化したテキストは、標準入力またはインラインのシェル入力を介してshasum -a 256またはsha256sumに渡してください。決して一時ファイルを使わず、最初の出力フィールドをコピーしてください。
• コピーしたResearch Contextは、プランが所有する正式な要件コピーとして扱ってください。選択したRESEARCH.mdが後から変更されても、明示的なドリフト警告とユーザーが要求したリベース／改良なしに、これらの要件を上書きしてはいけません。
• 簡潔にまとめ、1画面で読める要件の概要にしてください。

リサーチが存在してもこのプランに影響していない場合は、## Research Contextを含めないでください。トピックAの既存のRESEARCH.mdがあり、無関係なトピックBについて明示的な/aif-planの依頼があった場合、トピックBのプランはリサーチと関連付けないでください。

fast/fullにはreferences/TASK-FORMAT.mdの正規テンプレートを使用してください。 ultraにはreferences/ULTRA-FORMAT.mdを使用し、完了前にすべてのPhase Indexリンク、タスクのマッピング、依存関係、フェーズファイルを検証してください。

正規テンプレートで定義されているのは、必須セクションとその順序のみです。ファイルを書き込む前に、人が読むプランの内容をすべてartifact_languageで作成し、Step 0の説明に従ってtechnical_terms_policyを適用し、安定トークンを保持してください。

コミット計画のルール：

• タスクが5件以上 → 3～5タスクごとにコミットチェックポイントを追加します。
• タスクが5件未満 → 最後に1回だけコミットし、コミット計画は不要です。
• 論理的に関連するタスクを1つのコミットにまとめます。
• Conventional Commitsに従い、意味のあるコミットメッセージを提案してください。

Step 6：次のステップ

Full/ultraモード＋並列（--parallel）： /aif-implementを自動的に実行してください。並列実行の目的は、分離されたworktreeで最初から最後まで自律的に実行することです。HANDOFF_BRANCH_PREPARED = 1の場合は、--parallelが無効になったものとして扱い、/aif-implementを自動実行しないでください。

/aif-implement

CONTEXT FROM /aif-plan:
- Plan artifact: <resolved plan file or ultra directory>      # see Step 1.2 / Step 5
- Testing: yes/no
- Logging: verbose/standard/minimal
- Docs: yes/no  # yes => mandatory docs checkpoint, no => warn-only

通常のFull/ultraモード： プラン作成後に停止してください。ユーザーがプランを確認し、実装するタイミングを決定します。

以下の次ステップ用テンプレートで定義されているのは、構成のみです。ユーザー向けの応答に含まれる、人が読むテキストはすべてui_languageで作成してください。コマンド名、設定済みパス、タスク数、TaskListへの参照は変更しないでください。

Plan created with [N] tasks.
Plan artifact: <resolved plan file or ultra directory>

To start implementation, run:
/aif-implement

To view tasks:
/tasks (or use TaskList)

Fastモード： プラン作成後に停止してください。

Plan created with [N] tasks.
Plan file: <resolved fast plan path>

To start implementation, run:
/aif-implement

To view tasks:
/tasks (or use TaskList)

コンテキストの整理

必要に応じて、コンテキストの空き容量を増やすようユーザーに提案してください：/clear（完全にリセット）または/compact（履歴を圧縮）。

---

--listサブコマンド

--listが渡された場合は、アクティブなworktreeとそれぞれの機能のステータスをすべて表示してください。その後、停止してください。

git worktree list

各worktreeのパスについて：

1. 解決済みのプランディレクトリがそのworktree内に存在するか（<worktree>/<resolved paths.plans>。既定値：<worktree>/.ai-factory/plans/）、また、ルート直下の*.mdプランまたは内容に``を含む直下の子ディレクトリの*/index.mdエントリーポイントがあるか確認してください。
2. 名前と、タスクがあるため完了したように見えるか、まだ進行中かを表示してください。

出力形式：

Active worktrees:

  /path/to/my-project          (<configured-base-branch>)        <- you are here
  /path/to/my-project-feature-user-auth  (feature/user-auth)  -> Plan: feature-user-auth.md
  /path/to/my-project-feature-billing    (feature/billing)    -> Ultra: feature-billing/index.md
  /path/to/my-project-fix-cart-bug       (fix/cart-bug)        -> No plan yet

workflow.plan_id_format = sequentialの場合、表示されるファイル名またはディレクトリ名には数値プレフィックスが含まれます。例：Plan: 0042_feature-user-auth.mdまたはUltra: 0042_feature-user-auth/index.md。worktreeのブランチステムについて、両方の形式を対象に最も番号の大きいものを選択してください。

--cleanup サブコマンド

--cleanup <branch> が渡された場合、ワークツリーを削除し、必要に応じてブランチも削除します。その後、停止します。

DIRNAME=$(basename "$(pwd)")
BRANCH_DIR=$(echo "<branch>" | tr '/' '-')
WORKTREE="../${DIRNAME}-${BRANCH_DIR}"

git worktree remove "${WORKTREE}"
git branch -d <branch>  # -d (not -D) will fail if unmerged, which is safe

ブランチが未マージのため git branch -d が失敗した場合：

Branch <branch> has unmerged changes.
To force-delete: git branch -D <branch>
To merge first: git checkout <configured-base-branch> && git merge <branch>

ワークツリーのパスが存在しない場合は、git worktree list を確認して正しいパスを提示します。

---

タスクの説明に関する要件

すべての TaskCreate 項目には、必ず以下を含めてください。

• 明確な成果物と期待される動作
• 変更・作成するファイルパス
• ログ要件（ログの内容、出力先、レベル）
• 該当する場合は依存関係に関する注記
• Requirements Reconciliation Gate が適用される場合は、要件の出典アンカーと該当する動作の組み合わせ

ログの指示なしにタスクを作成してはいけません。

references/TASK-FORMAT.md にある標準的な例を使用してください。

• TaskCreate の例
• ログ要件チェックリスト

重要なルール

1. ユーザーが不要と言ったテストは作成しない — テストタスクをこっそり追加しないでください
2. レポートは作成しない — 最後に要約・レポートのタスクを作成しないでください
3. 実行可能なタスクにする — 各タスクに明確な成果物を設定してください
4. 適切な粒度にする — 大きすぎて圧倒されるものや、小さすぎてノイズになるものは避けてください
5. 依存関係を考慮する — 順番に実行できるようタスクを並べてください
6. ファイルパスを含める — 実装担当者が作業場所を把握できるようにしてください
7. 大規模な計画にはコミットのチェックポイントを設ける — タスクが5件以上の場合、3～5件ごとにチェックポイントを設けたコミット計画が必要です
8. 計画成果物の保存先 — Fast：paths.plan。Full： paths.plans/<plan_identifier>.md。Ultra： paths.plans/<plan_identifier>/index.md とフェーズファイル。 plan_identifier には、正規の引き継ぎ／ブランチ／スラッグの語幹と、Step 1.2 の任意の連番プレフィックスを使用します。timestamp と uuid は slug にフォールバックします。
9. 所有範囲の境界 — このコマンドが所有するのは計画成果物のみです（解決済みの Fast 計画パス、および paths.plans 配下の Full／Ultra 成果物）。それぞれの成果物には所有者コマンド（/aif-roadmap、/aif-rules、/aif-explore）を使用してください。
10. ロードマップとの紐付け（利用可能な場合） — 解決済みのロードマップ成果物が存在する場合は、計画に ## Roadmap Linkage セクションを含めるか、スキップしたことを明記してください。
11. 計画の前に要件を調整する — 解決されていない動作要件を、ロードマップの要約、優先度の低いソース、または内部的に一貫した実装で覆してはいけません。

計画ファイルの取り扱い

Fast モード（paths.plan、デフォルト：.ai-factory/PLAN.md）

• すばやい作業のための一時的な計画
• 完了後、/aif-implement が削除を提案することがあります

Full モード（paths.plans/<plan_identifier>.md — デフォルト）

• 機能提供のための長期的な計画
• 標準の plan_file_stem は Step 1.2.a で決定されます。引き継ぎブランチ名（スラッシュを置換）→ git ブランチ名（スラッシュを置換）→ 説明のスラッグの順です
• workflow.plan_id_format = sequential の場合、ファイル名は paths.plans/<NNNN>_<plan_file_stem>.md になります。プレフィックスには、ディレクトリ内に存在する最も大きい番号の次の4桁の番号を使用し、上限は 9999 です。番号は現在存在するファイルから算出されます。番号付きの計画をディレクトリ外に削除または移動すると、次回の実行時にその番号を再利用できます。引き継ぎブランチの契約では、プレフィックスは強制的に無効になります（Step 1.2.b–c を参照）。
• timestamp と uuid は予約値です。どちらも現時点では slug と同じ動作をします（プレフィックスは適用されません）

Ultra モード（paths.plans/<plan_identifier>/index.md）

• 高精度な委任のための長期的な計画バンドル
• Full モードと同じ標準の語幹、ブランチ／ワークツリーの動作、任意の連番プレフィックスを使用します。プレフィックスはディレクトリ名に付与されます
• index.md はマニフェスト兼進捗情報のソースです。直下のフェーズファイルは実装仕様です
• 利用側は references/ULTRA-FORMAT.md に従ってバンドルを読み取る必要があります。ローカルの単一ファイルの計画にまとめてはいけません

具体的なエンドツーエンドのフロー（fast/full/ultra/parallel/interactive）については、references/EXAMPLES.md（フローのシナリオ）を参照してください。