| name | 02-inception |
| description | ai_plc_inception - AI-PLC Stage 2。Goalを分析し、BacklogとSub-Agent Registryを生成する。 |
AI-PLC Stage 2: Inception
Goalを分析し、Sub-Agent Scope(SubLayer)とTask(実行単位)に再帰的に分解するステージ。Sub-Agent Scopeが生成されると、そのスコープ内でStage 1から再びパイプライン全体が展開される(Fractal Decomposition)。
共通規約: 命名は RUL_plc_system §6 / 完了報告は RUL_plc_session §7 / Phase遷移通知は §8 / Mob CP出力は §9 に従う。
入力
| 入力 | 必須 | 説明 |
|---|
| Intent + Context Manifest + Context Store | ✅ | Stage 1の生成物 |
| decomposition_strategy | ⭕ | product_manager / system_architect / content_strategist / tech_lead / generic。デフォルト: AI自動判定 |
実行フロー
Phase 1: Auto-Research
intent.yaml / context.yaml / Context Store を読み込み、Goal達成に必要な追加情報をワークスペース/Web検索で収集する。
Phase 2: Decomposition Strategy選択
Goalの性質から最適な戦略を判定する(ユーザー指定があれば優先。判定結果を報告して続行):
| 戦略 | 適用 | 分解の特徴 |
|---|
| product_manager | プロダクト開発・改善 | Discovery→Delivery、MVP思考 |
| system_architect | システム構築・基盤整備 | 設計→実装→運用、モジュール分割 |
| content_strategist | コンテンツ制作・発信 | 企画→制作→配信 |
| tech_lead | コーディングPJ(複数実装タスク) | Adaptive Skip判定 + SubLayer分割 |
| generic | その他 | Contextから動的判断 |
Phase 3: Goal分解
Goalを2種に分類する:
- SubLayer化: 複数Taskで構成 / 独自Contextが必要 / 他者に委譲可能 / 独立スケジュール → 再帰展開(詳細タスクは親で作らない。親のmodeを継承)
- Task化: 1-2日で完結 / これ以上分解不要 / 管理・調整系
Phase 4: Mob Checkpoint — 分解承認(停止)
ここで必ず停止し、承認を待つ(タスク数が少なくても省略しない):
- SubLayer/Task分解テーブル(ID・名称・type・priority・依存・見積)を提示
- セッション分割判定(SubLayer≥3 or Task≥10 → RUL_plc_session §1に従い分割推奨を明記)
- 承認後フロー1行 + 🙋承認待ちブロック(OK / 修正: [指示] / 差し戻し)
Phase 5: Backlog + Sub-Agent Registry生成
承認後、backlog.yaml を生成する:
- 全タスク必須フィールド:
id / name / description / type / priority / status / owner / estimated_hours / command / command_template_ref / origin(commandはmanagement系タスクのみnull可)
- トップレベル必須:
focus_strategy / focus_strategy_reason / focus_strategy_confirmed_by / decomposition_pattern / sublayers / tasks / summary(task_count / p0_tasks / p1_tasks / p2_tasks / next_action)
- 再分解があった場合は
refactoring_log も記録
- SubLayerがあれば
sublayers/ にフォルダを作成し、各SubLayerに「次のステップ」(Collection起動プロンプト)を含める
Phase 5.5: 外部実行タスク判定
各タスクを判定する: ✅PJ内実行→そのまま / 📤外部委譲(別の実行者がやるべき)→ Self-Describing Task構造(RUL_plc_system §9)でチケット化し「外部DBに書き出しますか?」と確認→承認後push / ⏳先送り→deferredステータスで残す。
Phase 6: Mob Checkpoint — 次ステージ提案(停止)
ここで必ず停止し、RUL_plc_session §7 の4パートを出力する。Next Action: SubLayerあり→各SubLayerの /01-collection 起動案内 / Tasksのみ→ /03-construction 案内(表記は §7.4「実行形式は環境の正」)。standard以上ではStage 3が唯一の推奨(RUL_plc_adaptive §6。Stage 4直行の選択肢を出さない)。
Re-Inception(Backtrack対応)
BT-A(ブロッカー)/ BT-B(節目再評価)から呼び出される差分再分解モード(RUL_plc_adaptive §5):
- 既存backlog.yamlを読み込む(completedタスクは保持)
- トリガー原因を分析し、差分のみ実施: タスク追加(新ID採番)/ 修正(description・priority・dependencies更新)/ 削除(statusを
cancelledに。物理削除しない)
- refactoring_log に date / trigger / reason / changes を記録
- 差分テーブル(操作/タスクID/内容/理由)を提示して承認を待ち、承認後にbacklog.yamlを更新
出力
backlog.yaml(常に) / sublayers/(SubLayer生成時) → Stage 3: SKL_plc_03_construction へ。
作成日: 2026-04-07 | 更新日: 2026-07-07 | バージョン: 2.0(Fable観点軽量化: 指示形1本化、Re-Inceptionを差分実行に圧縮)