Issue Creator

ワークフロー

1. 作業内容理解+規模判定 → 2. コード調査(規模に応じて) → 3. Issue内容整理 → 4. ユーザー確認 → 5. Issue作成 → 6. Working Documents生成(規模に応じて)

⚠️ このスキルではコード修正を行わない。調査とIssue作成とWorking生成のみ。

Phase 1: 作業内容理解 + 規模判定

タイプ判定

Issueタイプを判定: bug / feat / refactor / docs / style / perf / chore / test 不明点はユーザーに質問。

規模判定

タスクの規模を3段階で判定:

⚠️ 規模判定に迷ったら「中」として扱う。

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本文作成

## 概要
[何をするか - 1-2文]

## 理由/背景
[なぜ必要か]

## 対象箇所
- `path/to/file.ts:行番号` - 関数/コンポーネント名

## 作業内容
- [ ] タスク1
- [ ] タスク2

## 影響範囲
- 関連コンポーネント・依存関係

⚠️ 小規模タスクでは「対象箇所」「影響範囲」は省略可。

Phase 4: ユーザー確認 🔹確認ポイント

Issue本文を提示し、以下を確認:

• 内容が正しいか
• 規模判定が妥当か
• Working Documents生成の有無（AIの判断を提示）

Phase 5: Issue作成

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が規模に応じて判断）

生成判断基準

小規模タスクでの判断基準

以下に該当する場合はスキップ可:

• 軽微なドキュメント修正（typo、リンク修正等）
• 単純な依存関係更新（npm updateのみ）
• 緊急のホットフィックス（即座に修正が必要）
• 1ファイルの軽微な修正

以下に該当する場合は生成する:

• バグ修正（原因調査の記録が重要）
• テスト追加（テスト計画が必要）
• 複数セッションにまたがる可能性がある作業

タスクタイプ別の生成内容

ディレクトリ構成

docs/working/{YYYYMMDD}_{Issue番号}_{タイトル}/
├── requirement.md  # 要件定義
├── tasklist.md     # タスクリスト（必須）
├── design.md       # 設計書
└── testing.md      # テスト計画

生成ロジック

Phase 2 のコード調査結果を流用して以下を生成:

1. requirement.md: Issue本文から要件を構造化
2. tasklist.md: 作業内容をフェーズ別タスクに分解
3. design.md: 変更対象ファイル、実装方針、影響範囲
4. testing.md: テストケース、カバレッジ目標

Working Documents テンプレート

requirement.md（要件定義）

# 要件定義

**Issue**: #123
**作成日**: 2026-02-06
**ラベル**: enhancement

## ユーザーストーリー
ユーザー「[セリフ形式]」
アプリ「[期待する動作]」

## 要件一覧
### 必須要件
- [ ] 要件1

### オプション要件
- [ ] 要件2

## 受け入れ基準
- [ ] 基準1

tasklist.md（タスクリスト）

# タスクリスト

## フェーズ1: [フェーズ名]
- [ ] タスク1
- [ ] タスク2

## フェーズ2: [フェーズ名]
- [ ] タスク3

## 依存関係
- フェーズ1 → フェーズ2（順次実行）

design.md（設計書）

# 設計書

## 実装方針

### 変更対象ファイル
- `path/to/file.ts` - [変更内容]

### 新規作成ファイル
- `path/to/new.ts` - [役割]

## 影響範囲
- [影響を受けるコンポーネント]

## 禁止事項チェック
- ❌ 独自CSS生成しない
- ❌ 設計方針を変更しない

testing.md（テスト計画）

# テスト計画

## テスト戦略

### ユニットテスト
- `path/to/file.test.ts`
  - テストケース1
  - テストケース2

## カバレッジ目標
- 対象ディレクトリ: 80%以上

Phase 7: 完了

✅ Issue #124 を作成しました
✅ Working Documents を生成しました（or スキップしました）
   └── docs/working/20260206_124_タイトル/

次のステップ:
  /fix-issue 124

詳細パターン

実際のIssue作成例は以下を参照:

• issue-examples.md - バグ報告、機能追加、リファクタリング等の具体例