Ct AI Dlc

SIRIUS AI 駆動開発フロー (AI-DLC) 起点スキル

このスキルは SIRIUS リポジトリで AI 駆動開発フロー を開始/継続するためのもの。 ユーザーが /ct-ai-dlc と明示的に呼び出したときのみ起動する（disable-model-invocation: true 指定）。 普段の開発スタイルに影響を与えず、AI-DLC を選択したユーザー・タスクにだけ適用される。

思想

このフローは AWS が提唱する AI-DLC (AI-Driven Development Life Cycle) をベースにしている。 従来の「人間が書く → AI が補助」を反転させ、AI が能動的に計画・提案 → 人間が承認 → AI が実装 という主従逆転を行う。

このスキルは厳密にこのフローを進行させるためにある。自走で判断できる部分は決め打ちで進む。ユーザーが進行を中断したい場合は会話で介入できる前提なので、AskUserQuestion は「人間にしか判断できない場面」に限定して使う。

フロー全体図

Phase 1            Phase 2             Phase 3             Phase 4         Phase 5
Intent 起票   →    Inception     →    Construction   →    Review     →   Operations
（何を/なぜ）       （どう作る）         （実装）             （レビュー）    （リリース）
   ↓                  ↓                   ↓                   ↓               ↓
intent.md          plan.md             コード+PR          GitHub          検証レポート
   └─────────────────┴──── docs/ai-dlc/<date>-<topic-slug>/ ────┘

各 Phase の成果物は Markdown ファイルとして docs/ai-dlc/<date>-<topic-slug>/ に蓄積される。 Phase 間の情報引き継ぎは すべてファイル経由。これにより各 Phase が自己完結し、Phase 完了後にコンテキストをリセットしても次 Phase が再現可能になる。

Phase 4 (Review) は、GitHub の PR にレビュアーを割り当て、チームで使っている連絡手段でレビュー依頼を送る。 依頼の送り方はチームごとに異なるため、このスキルでは手順を固定していない。

引数の解釈

引数は 自由テキスト として受け取り、以下を文脈から推測する:

1. トピック — 何の機能・改善か。例: "Impact Frames", "ハイブリッドGI", "Smear Pass 改善"
2. 開始フェーズ — どの Phase から始めるか。明示キーワードがあれば採用、なければ既存状況から推定

フェーズキーワード（参考、網羅でなくてよい）

明示キーワードがなければ、既存フォルダの中身から判定する:

• フォルダなし → Phase 1 (新規 Intent)
• intent.md のみ → Phase 2 が次
• intent.md + plan.md → Phase 3 が次

引数解釈の動作例

外部情報源 URL が含まれる場合

引数や対話の中で チャットのスレッド / ドキュメントツールのページ / GitHub Issue / PR などの URL が渡された場合は、対応するツール（各サービスの MCP ツール、gh api 等）で内容を取得し、Intent の Description / Context の素材として利用する。

引き出す情報の典型例:

• 機能のトピック（フォルダ slug 推定の材料）
• 依頼の背景・経緯（Context の「背景となる依頼」に閉じる）
• 既存代替手段の有無・チーム内合意状況
• 利用想定（誰がどう使うか）

スケジュール情報がそこに書かれていても Intent には転記しない（Phase 1 reference の「Intent に書かないもの」参照）。スケジュールは GitHub Issue / PR description / カンバン側で管理する。

処理フロー（このスキルが実行する手順）

Step 1: 引数の解釈

引数からトピックとフェーズを推測する。複数候補や曖昧さがある場合のみ AskUserQuestion を使う。 単一候補や妥当な推測ができる場合は決め打ちで進む。ユーザーが意図と違えば会話で訂正する。

Step 2: 既存フォルダの検索

ls docs/ai-dlc/

トピックキーワードでフォルダ名をファジーマッチ。フォルダ名形式は <date>-<topic-slug>。

• 候補 0 件 → 新規 Phase 1 を開始（フォルダはこのスキルが作成する）
• 候補 1 件 → 採用、次ステップへ
• 候補 2 件以上 → AskUserQuestion で 1 つ選択

Step 3: フォルダの作成 / 検証

新規の場合:

• 日付プレフィックス: 今日の日付を YYYY-MM-DD で取得（date -u +%Y-%m-%d）
• トピック slug: 日本語入力を kebab-case 英数字に正規化（例: impactframe実装 → impactframe-impl、ハイブリッドGI → hybrid-gi）

  • 課題ベースで命名する: 実装手段ではなく解決したい課題で命名する。

    • ✅ outline-inner-bleed-suppression（課題 = アウトラインの内側にじみ抑制）
    • ❌ outline-stencil-mask（実装手段 = ステンシルマスク）

    理由: Intent は実装方針を固定しないドキュメントなので、フォルダ名も実装手段に寄せると Phase 2 で別案に切り替わった時に陳腐化する。

• 作成: mkdir -p docs/ai-dlc/<date>-<topic-slug>/

正規化に決定的な答えがない場合は、もっとも自然な候補を採用して進む。ユーザーが気に入らなければ会話で訂正する。

既存の場合:

• ls docs/ai-dlc/<date>-<topic-slug>/ で既存ファイル確認
• フェーズ整合性チェック（例: Phase 2 を開始しようとしているのに intent.md がなければエラー報告）

Step 4: フェーズの実行

該当フェーズの reference を読み込み、その手順に従って実行する:

reference の読み込みは「フェーズ実行直前」に行うこと。スキル起動時に全部読むとコンテキストが無駄に膨らむ。

Step 5: フェーズ完了時のメッセージ

フェーズが完了したら、生成したファイルのパスと 次フェーズの起動コマンド を提示する。 コンテキストリセット (/clear) を 軽く推奨 するが強制はしない。

✅ Phase 1 (Intent) 完了
   出力: docs/ai-dlc/2026-05-26-impactframe-impl/intent.md

次は Phase 2 (Inception) です。
コンテキストをリセットしてから実行すると、Markdown 引き継ぎの自己完結性が担保され
トークン消費も抑えられます（任意）。

   /clear
   /ct-ai-dlc impactframe実装をinceptionから

次フェーズの引数は コピペで動く形 にすること（トピック名 + フェーズ指定を含める）。

共通ルール

git 操作はユーザー許可制（MUST）

git add / commit / push、ブランチ作成、PR 作成（gh pr create）など、リポジトリの状態やリモートを変える操作は、ユーザーが明示的に許可した場合にのみ行う。許可がない間は、実装・コンパイル・テスト・ドキュメント編集・作業ツリー上の変更までに留める。

• 各 Phase は「git 操作の直前」で一旦立ち止まり、何を・どこにコミット / PR 化するかを提示してユーザーの承認を得る
• この方針は下記「Human in the Loop の方針」の 迷ったら進む および「自走で判断できる部分は決め打ちで進む」より 優先する（git 操作は自走の対象外）
• コミット先・ブランチ運用・PR 手順の詳細は CLAUDE.md およびユーザーグローバル ~/.claude/CLAUDE.md の git 運用規約に従う

触ってはいけないファイル

• .meta ファイル — Unity Editor が生成する。AI が生成した GUID は既存と衝突する可能性がある（PR #553 の教訓）
• サブモジュールポインタ — SiriusPackages / SiriusAssets の HEAD 変更は SIRIUS にコミットしない
• Packages/manifest.json の tarball swap 後の状態 — 一時改変のみ、コミットしない
• LocalPackages/*.tgz — 検証用、Git 管理外

コミット先の判断

実装対象がどのリポジトリに着地するかは references/sirius-repos.md を参照。 このスキルは Phase 3 (Construction) で実装に入る直前 にこの reference を読み込む。

品質ゲート（PR マージ前 — MUST）

PR をマージする前に、macOS（iOS ターゲット）と Windows（Android ターゲット）の両方で全 AverageTest（Assets/Tests/Runtime/AverageTest.cs の PlayMode ビジュアルリグレッション全ケース ＋ EditMode 全テスト）が成功していることを必須とする。AverageTest は実行 OS の期待ターゲット以外だとスキップされるため、両プラットフォームを別々に担保する（macOS→iOS / Windows→Android、WebGL は共通）。CI に Unity テストの自動ゲートが無いため、AI が手動で TestRunner を全件実行して担保する。閾値近傍で初回失敗するテストは、失敗テストのみを対象に初回 + リトライ 2 回 = 最大 3 試行まで実行し、1 回でも成功すれば PASS として扱う。3 試行連続で失敗したテストは「確定失敗」とし、それ以上リトライせず、FLIP Mean / 閾値 / 差分画像パスを添えて AskUserQuestion で人間の判断に引き渡す（flaky か実装起因かの最終判定は人間が行う。実装起因と判断された場合のみ修正して再度全件を成功させる）。具体手順・CLI タイムアウト時の判定方法は Phase 3 Step 4 を参照。

Markdown 引き継ぎ規約

• すべての中間成果物は docs/ai-dlc/<date>-<topic-slug>/ に置く
• ファイル名は artifact 名で固定: intent.md / plan.md
• 日付やトピックはフォルダ名に持たせる（ファイル名には持たせない）
• 次フェーズで読むファイルがすべて揃った状態でフェーズ完了とする

Human in the Loop の方針

AI-DLC の核は「重要な判断には人間確認を必須」だが、SIRIUS では 過度の確認はフローを停滞させる ため次のように運用する:

• ✅ AskUserQuestion を使う: 真に複数の妥当な選択肢がある場面、データ削除など不可逆な操作前
• ❌ 使わない: 自動推測で妥当な選択ができる場面、補完情報の確認（ユーザーは会話で介入できる）

迷ったら 進む ことを優先する。間違っていればユーザーが訂正する。

関連ドキュメント

• docs/ai-dlc/README.md — docs/ai-dlc/ 配下の運用ルール
• references/sirius-repos.md — リポジトリ役割マップ
• assets/intent-template.md — Intent 雛形
• assets/plan-template.md — Plan 雛形
• assets/pr-template.md — PR 本文雛形（Phase 3 Step 7・lean / 署名なし）