start-phase

name	start-phase
description	指定したフェーズの phase doc を読み、依存・必要な rule / skill・受け入れ基準を整理して着手準備を整える（準備のみで実装はしない）。 「フェーズ N に着手する」「Phase N を始めたい」「次のフェーズの準備をして」「start-phase N」 「このフェーズの前提と受け入れ基準を教えて」と言われたとき、新しい実装単位に取りかかる最初に使う。 worktree 作成〜実装〜検証〜PR〜マージ〜レトロまで端から端まで駆動したいときは implementation-workflow を使う （本 skill はそのワークフローの着手準備ステップに相当する単発用途で、駆動は implementation-workflow の責務）。 実装の入口を定型化し、依存漏れ・受け入れ基準の見落としを防ぐ。
allowed-tools	Read Glob Grep

start-phase — フェーズ着手の準備を整える

引数で受け取ったフェーズ識別子から該当 phase-*.md を特定し、依存 / 必要な rule・skill / 受け入れ基準 / 検証手順を抽出して提示する手順 skill。実装に飛び込む前に「何を満たせば完了か」「何に依存するか」を 明確にし、繰り返し正しく着手できるようにする。完了側は finish-phase が担う。

implementation-workflow との使い分け: 本 skill は単発の着手準備のみ（phase doc を読み前提と受け入れ基準を提示するところで止まる）。worktree 作成 → 実装 + 検証 → PR → 独立レビュー → マージ → レトロまで端から端まで駆動したいときは implementation-workflow を使う（本 skill はその Phase 1「計画 / 設計 Read」に委譲先として組み込まれる）。「準備だけ整えたい」なら本 skill、「実装ライフサイクル全体を回したい」なら implementation-workflow。

なぜこの skill があるか

phase doc を毎回通読して要点を拾うのは抜けが出やすく、特に依存フェーズが未マージだと手戻りになる。 着手前チェックを定型化し、依存の充足確認と受け入れ基準の事前把握を強制して空振りを防ぐ。

入力

• フェーズ識別子（引数）: 8 / phase-08 / 08-core-skills / Phase 8 のような表記を許容する。 01-mvp 側の MVP フェーズも対象（docs/roadmap/*/phase-*.md を横断検索する）。
• 曖昧で複数候補に当たる場合は候補を列挙してユーザーに確認する。

出力

• 対象 phase doc のパスとタイトル。
• 目的 / スコープの 1〜2 行要約。
• 依存（前提） とその充足状況（依存フェーズが main にマージ済みか・必要ファイルが実在するか）。
• このフェーズで参照・追従すべき rule / skill / ADR。
• 受け入れ基準（チェックリスト形式）と検証手順。
• 既知のリスク・備考。

手順

1. phase doc を特定する

docs/roadmap/**/phase-*.md を Glob で列挙し、引数の番号 / slug に一致するものを選ぶ。番号は 2 桁ゼロ詰め （phase-08-*.md）で並ぶので、8 → phase-08 に正規化して照合する。複数計画（00-harness-setup / 01-mvp）にまたがるため、一致が複数なら候補を提示して確認する。

2. doc を読み、要点を抽出する

特定した phase doc を Read し、共通テンプレート（目的 / 前提 / タスク / 受け入れ基準 / 検証手順 / リスク） の各節から要点を拾う。受け入れ基準と検証手順は省略せず整理する（着手後の自己照合の基準になる）。

3. 依存の充足を確認する

「前提（依存）」節に挙がるフェーズ / ファイルが実際に揃っているかを確認する:

• 依存フェーズが参照するファイル（例: pnpm verify・docs/roadmap/ 構造・adr-new skill）が実在するか を Glob / Read で確かめる。
• 未充足の依存があれば着手をブロックする要因として明示し、先に解消すべき旨を伝える。

4. 参照すべき rule / skill / ADR を集める

phase doc が明示的に参照する .claude/rules/* / .claude/skills/* / docs/adr/* を列挙し、着手前に 読むべきものを示す。doc 内の相対リンクを辿って dangling がないかも軽く確認する。

5. 着手サマリを提示する

上記を出力の形でまとめて提示する。これが実装中の自己照合チェックリストになる。実装そのものは 行わず、準備の提示までに留める（着手判断はユーザー / 実装エージェントに委ねる）。

Gotchas

• 依存の「実在」を確認する: doc の依存記述ではなく、その成果物が worktree に実在するかで充足を判定する。
• 受け入れ基準を削らない: 完了時に finish-phase がこの基準で照合する。要約しすぎて条件を落とさない。
• 実装まで踏み込まない: この skill は「準備」。コード変更やファイル生成は着手後の別作業。

関連

• 端から端まで駆動: implementation-workflow — 本 skill を Phase 1 着手準備として束ね、実装〜マージ〜レトロまで回す。
• 完了側: finish-phase — verify → 受け入れ基準照合 → 進捗更新。
• 検証ゲート: verify。
• フェーズ一覧 / 役割分担 / 受け入れ基準: docs/roadmap/completed/00-harness-setup/README.md（ハーネス計画）。