Create plan

Create Plan Skill

GitHub Issue の Description を元に、コードベースを調査した上で実装プランを新規作成する。プランは Issue コメントとして投稿する。

このスキルはプランの新規作成のみを行う。 既存プランの更新は /update-plan スキルを使用すること。

前提条件

• gh CLI が認証済みであること

手順

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 の「コードベース調査ガイド」セクションに従い、以下を行う:

1. モジュール構成の把握: project-context.md に記載された方法でプロジェクトの構成を理解する
2. 既存パターンの調査: 同様の機能がどのように実装されているかを確認し、拡張ポイントを特定する
3. 影響範囲の特定: 変更が影響するモジュール、インターフェース、テストを特定する
4. テスト構成の確認: 既存のテスト構成を確認し、新規テストの配置先を把握する

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 の更新箇所も具体的に特定すること