Issue Creator
ワークフロー
code
1. 作業内容理解+規模判定 → 2. コード調査(規模に応じて) → 3. Issue内容整理 → 4. ユーザー確認 → 5. Issue作成 → 6. Working Documents生成(規模に応じて)
⚠️ このスキルではコード修正を行わない。調査とIssue作成とWorking生成のみ。
Phase 1: 作業内容理解 + 規模判定
タイプ判定
Issueタイプを判定: bug / feat / refactor / docs / style / perf / chore / test
不明点はユーザーに質問。
規模判定
タスクの規模を3段階で判定:
| 規模 | 基準 | 例 |
|---|---|---|
| 小 | 1-2ファイル変更、単純な修正 | typo修正、設定変更、1関数の修正 |
| 中 | 3-5ファイル変更、機能の追加・修正 | コンポーネント追加、既存機能の改善 |
| 大 | 6ファイル以上、新機能、複雑なリファクタ | 新ページ作成、アーキテクチャ変更 |
⚠️ 規模判定に迷ったら「中」として扱う。
Phase 2: コード調査（規模に応じて調整）
大規模タスク → 詳細調査
- •
find_symbol/search_for_patternで関連コード特定 - •
get_symbols_overviewで構造把握 - •
find_referencing_symbolsで影響範囲確認
⚠️ この調査結果はWorking Documents生成に流用されるため、しっかり行う。
中規模タスク → 標準調査
- •
search_for_patternで関連コード特定 - •
get_symbols_overviewで変更対象ファイルの構造把握
小規模タスク → 軽微調査 or 省略
- •対象ファイルが明確な場合は調査省略可
- •不明な場合のみ
search_for_patternで軽く確認
Phase 3: Issue本文作成
markdown
## 概要 [何をするか - 1-2文] ## 理由/背景 [なぜ必要か] ## 対象箇所 - `path/to/file.ts:行番号` - 関数/コンポーネント名 ## 作業内容 - [ ] タスク1 - [ ] タスク2 ## 影響範囲 - 関連コンポーネント・依存関係
⚠️ 小規模タスクでは「対象箇所」「影響範囲」は省略可。
Phase 4: ユーザー確認 🔹確認ポイント
Issue本文を提示し、以下を確認:
- •内容が正しいか
- •規模判定が妥当か
- •Working Documents生成の有無（AIの判断を提示）
Phase 5: Issue作成
bash
cat > /tmp/issue_body.md <<'EOF' [Issue本文] EOF gh issue create --title "[type]: タイトル" --body-file /tmp/issue_body.md --label "ラベル" rm /tmp/issue_body.md
ラベル対応: bug→bug, feat→enhancement, refactor→refactor, docs→documentation, style→design, perf→performance, chore→chore, test→testing
Phase 6: Working Documents生成（AIが規模に応じて判断）
生成判断基準
| 規模 | Working生成 | 理由 |
|---|---|---|
| 大 | ✅ 必ず生成 | コンテキスト保持が必須 |
| 中 | ✅ 生成推奨 | /fix-issueでの作業効率化 |
| 小 | △ AIが判断 | 内容に応じて生成/スキップ |
小規模タスクでの判断基準
以下に該当する場合はスキップ可:
- •軽微なドキュメント修正（typo、リンク修正等）
- •単純な依存関係更新（
npm updateのみ） - •緊急のホットフィックス（即座に修正が必要）
- •1ファイルの軽微な修正
以下に該当する場合は生成する:
- •バグ修正（原因調査の記録が重要）
- •テスト追加（テスト計画が必要）
- •複数セッションにまたがる可能性がある作業
タスクタイプ別の生成内容
| タイプ | requirement.md | tasklist.md | design.md | testing.md |
|---|---|---|---|---|
| bug | ✅ | ✅ | ✅ | ✅ |
| feat | ✅ | ✅ | ✅ | ✅ |
| refactor | ✅ | ✅ | ✅ | △ 必要に応じて |
| test | △ 軽量 | ✅ | △ 軽量 | ✅ |
| docs | △ 軽量 | ✅ | - | - |
| style | △ 軽量 | ✅ | △ 軽量 | - |
| chore | - | ✅ | - | - |
ディレクトリ構成
code
docs/working/{YYYYMMDD}_{Issue番号}_{タイトル}/
├── requirement.md # 要件定義
├── tasklist.md # タスクリスト（必須）
├── design.md # 設計書
└── testing.md # テスト計画
生成ロジック
Phase 2 のコード調査結果を流用して以下を生成:
- •requirement.md: Issue本文から要件を構造化
- •tasklist.md: 作業内容をフェーズ別タスクに分解
- •design.md: 変更対象ファイル、実装方針、影響範囲
- •testing.md: テストケース、カバレッジ目標
Working Documents テンプレート
requirement.md（要件定義）
markdown
# 要件定義 **Issue**: #123 **作成日**: 2026-02-06 **ラベル**: enhancement ## ユーザーストーリー ユーザー「[セリフ形式]」 アプリ「[期待する動作]」 ## 要件一覧 ### 必須要件 - [ ] 要件1 ### オプション要件 - [ ] 要件2 ## 受け入れ基準 - [ ] 基準1
tasklist.md（タスクリスト）
markdown
# タスクリスト ## フェーズ1: [フェーズ名] - [ ] タスク1 - [ ] タスク2 ## フェーズ2: [フェーズ名] - [ ] タスク3 ## 依存関係 - フェーズ1 → フェーズ2（順次実行）
design.md（設計書）
markdown
# 設計書 ## 実装方針 ### 変更対象ファイル - `path/to/file.ts` - [変更内容] ### 新規作成ファイル - `path/to/new.ts` - [役割] ## 影響範囲 - [影響を受けるコンポーネント] ## 禁止事項チェック - ❌ 独自CSS生成しない - ❌ 設計方針を変更しない
testing.md（テスト計画）
markdown
# テスト計画 ## テスト戦略 ### ユニットテスト - `path/to/file.test.ts` - テストケース1 - テストケース2 ## カバレッジ目標 - 対象ディレクトリ: 80%以上
Phase 7: 完了
code
✅ Issue #124 を作成しました ✅ Working Documents を生成しました（or スキップしました） └── docs/working/20260206_124_タイトル/ 次のステップ: /fix-issue 124
詳細パターン
実際のIssue作成例は以下を参照:
- •issue-examples.md - バグ報告、機能追加、リファクタリング等の具体例