bright-room Create Plan Skill
GitHub Issue の Description を元に、コードベースを調査した上で実装プランを新規作成する。プランは Issue コメントとして投稿する。
このスキルはプランの新規作成のみを行う。 既存プランの更新は /update-plan スキルを使用すること。
前提条件
ghCLI が認証済みであること
手順
1. Issue の取得
引数に Issue 番号を指定する（必須）。
gh issue view <issue-number> で Issue のタイトル、本文、ラベルを取得し、要件を正確に理解する。
2. 既存プランコメントの確認
Issue のコメント一覧を取得し、既にプランコメントが投稿されているかを確認する。
gh api 'repos/{owner}/{repo}/issues/<issue-number>/comments' --jq '.[] | select(.body | contains("<!-- claude:plan -->"))'
既存プランが見つかった場合: プランは既に作成済みであることをユーザーに報告し、更新が必要であれば /update-plan の使用を案内して終了する。
3. コードベースの調査
Issue の要件に基づいて、関連するコードを徹底的に調査する。
.claude/skills/references/project-context.md の「コードベース調査ガイド」セクションに従い、以下を行う:
- モジュール構成の把握: project-context.md に記載された方法でプロジェクトの構成を理解する
- 既存パターンの調査: 同様の機能がどのように実装されているかを確認し、拡張ポイントを特定する
- 影響範囲の特定: 変更が影響するモジュール、インターフェース、テストを特定する
- テスト構成の確認: 既存のテスト構成を確認し、新規テストの配置先を把握する
4. 実装プランの作成
以下の観点で実装プランを設計する:
- 実現可能性: 要件が現在のアーキテクチャで実現可能かを検証する
- 設計判断: 複数のアプローチがある場合は、各アプローチのトレードオフを分析する
- 段階的な実装: 変更を論理的なステップに分割し、各ステップの依存関係を明確にする
- テスト戦略: 各変更に対するテスト方針を策定する
5. 実装プランの投稿
実装プランを Issue コメントとして POST する。
gh api 'repos/{owner}/{repo}/issues/<issue-number>/comments' \
--method POST \
--field body='<プラン本文>'
API エラー時のフォールバック
コメントの投稿が失敗した場合は、ローカルファイルにフォールバック出力する。
- 出力先:
.claude/outputs/plans/PLAN-<Issue番号>-<Issueタイトルをケバブケースに変換>.md - ユーザーに API エラーが発生した旨と、手動で Issue にコメントをコピーするよう案内する
実装プランのフォーマット
以下のフォーマットに従って Markdown を生成する。プロジェクト固有のセクション（影響範囲テーブル、ファイル構成例、テスト戦略テーブル、ドキュメント更新対象）は .claude/skills/references/project-context.md の「プランテンプレート補足」セクションを参照して適切な形式にすること。
<!-- claude:plan -->
## 実装プラン
> 📋 Issue: #<issue-number>
> 📅 作成日: YYYY-MM-DD
### 概要
<!-- Issue の要件を簡潔に要約し、実装方針の全体像を述べる -->
### 設計判断 *(省略可: 複数のアプローチがある場合のみ記載)*
| アプローチ | メリット | デメリット |
|-----------|---------|-----------|
| A: <方式名> | <メリット> | <デメリット> |
| B: <方式名> | <メリット> | <デメリット> |
**採用案**: <選択したアプローチとその理由>
### 影響範囲
<!-- project-context.md の「影響範囲テーブル」に従って記述する -->
### ファイル構成
<!-- project-context.md の「ファイル構成の記述例」に従って記述する -->
<!-- 新規追加は (new)、変更は (modify) で表記する -->
### 実装ステップ
<!-- 実装を Phase（論理的なまとまり）と Step（具体的な作業単位）に分割する -->
#### Phase 1: <フェーズのタイトル>
<!-- フェーズの目的・ゴールを簡潔に述べる -->
##### Step 1: <ステップのタイトル>
**対象**: `path/to/file`
<!-- 具体的な変更内容を記述する。必要に応じてコード例を含める -->
##### Step 2: <ステップのタイトル>
<!-- 同様のフォーマットで記述 -->
#### Phase 2: <フェーズのタイトル>
##### Step 1: <ステップのタイトル>
<!-- 同様のフォーマットで記述 -->
### ドキュメント更新
<!-- project-context.md の「ドキュメント更新対象」を参照し、該当するものを記載する -->
| ドキュメント | 更新内容 |
|-------------|---------|
| `README.md` | <更新内容の概要> |
### テスト戦略
<!-- project-context.md の「テスト戦略テーブル」に従って記述する -->
### 確認事項 *(省略可: 確認すべき事項がなければセクションごと省略)*
- [ ] <確認事項1>
- [ ] <確認事項2>
### 今後の展望 *(省略可: スコープ外の関連拡張がなければセクションごと省略)*
- **<拡張テーマ>**: <概要と期待される効果>
- **<拡張テーマ>**: <概要と期待される効果>
---
🤖 *Generated by Claude Code*
注意事項
- Issue の要件を正確に理解し、過不足のないプランを作成すること
- 推測ではなく、実際にコードを読んで確認した事実に基づいてプランを作成すること
- 実装ステップは具体的に記述し、各ステップで変更するファイルパスを明示すること
- 既存のアーキテクチャパターンや命名規則に従った設計にすること
- 不明点や判断が必要な事項は「確認事項」セクションに明記すること
- 変更のない「設計判断」「確認事項」「今後の展望」セクションは省略してよい
- 「今後の展望」は Issue のスコープ外の関連拡張を記載する。コードベース調査中に見つけた改善機会や、自然な次のステップとなる機能拡張を挙げること
- 実装に伴うドキュメント更新を必ず「ドキュメント更新」セクションに記載すること。新機能・設定変更・アーキテクチャ変更がある場合、
CLAUDE.mdや.claude/rules/*.mdの更新箇所も具体的に特定すること