Dev Flow

Issue 作成から PR 作成まで自動実行する統合開発ワークフロー。

使い方

/shiiman-git:dev-flow              # 最新の計画書から実行（デフォルト）
/shiiman-git:dev-flow --plan       # plan mode で計画書を新規作成
/shiiman-git:dev-flow タスク詳細   # 計画書なしで直接実行（簡単なタスク用）
/shiiman-git:dev-flow --help

オプション

オプション	説明
--plan	plan mode で計画書を新規作成してから実行
--help	このコマンドのヘルプを表示

3つの実行モード

モード 1: 計画書実行モード（デフォルト）

/shiiman-git:dev-flow

既存の承認済み計画書から直接実行。

[既存計画書] → Issue作成 → ブランチ作成 → 実装 → ... → PR作成

モード 2: 計画書作成モード

/shiiman-git:dev-flow --plan

plan mode を使って計画書を作成・承認してから実行。

[ユーザー入力] → plan mode → 計画書作成 → 承認 → Issue作成 → ... → PR作成

モード 3: 直接実行モード

/shiiman-git:dev-flow 〇〇を追加する

計画書を作らず、タスク説明から直接実行。簡単なタスク向け。

[タスク説明] → Issue作成 → ブランチ作成 → 実装 → ... → PR作成

実行フロー

Issue作成 → ブランチ作成 → 実装 → 自己レビュー → [確認] → Issue更新 → コミット → プッシュ → PR作成

Claude への指示

--help が指定された場合: このファイルの内容を要約して表示し、終了。

---

モード判定

1. 先頭引数が --plan の場合 → モード 2（計画書作成モード）
2. 引数が1つ以上あり、--plan / --help 以外の文字列の場合 → モード 3（直接実行モード）
3. 引数なしの場合 → モード 1（計画書実行モード）

---

モード 1: 計画書実行モード（デフォルト）

重要: このモードでは plan mode を使用しません。

• EnterPlanMode ツールを使用しないでください
• 計画の承認を求めないでください
• 直接フローを実行してください

ステップ 0: 計画書の読み込み

.claude/plans/ ディレクトリから最新の計画ファイルを読み込みます。

ls -t ~/.claude/plans/*.md | head -1

計画書が見つからない場合:

## 計画書が見つかりません

計画書が見つかりませんでした。

### 代替手段
- `/shiiman-git:dev-flow --plan` で新しい計画を作成
- `/shiiman-git:dev-flow タスク説明` で直接実行

計画書が見つかったら、ステップ 1 から実行。

---

モード 2: 計画書作成モード（--plan）

EnterPlanMode ツールを使用して plan mode に入ります。

1. ユーザーに実装したい内容を確認
2. EnterPlanMode を実行して plan mode に入る
3. 計画書を作成（.claude/plans/ に保存される）
4. ユーザーが計画を承認したら、自動的に dev-flow の実行フェーズに進む

plan mode での計画書作成後、以下のステップを実行:

• ステップ 1: Issue 作成
• ステップ 2: ブランチ作成
• ステップ 3: 実装
• ステップ 4: セキュリティチェック＆自己レビュー
• ステップ 5: ユーザー確認
• ステップ 6: Issue チェックボックス完了更新
• ステップ 7: コミット
• ステップ 8: プッシュ
• ステップ 9: PR 作成
• ステップ 10: 完了報告

---

モード 3: 直接実行モード（タスク説明あり）

重要: このモードでは plan mode を使用しません。

• EnterPlanMode ツールを使用しないでください
• 計画書を作成しないでください
• タスク説明を Issue の内容として使用してください

タスク説明を確認し、直接ステップ 1 から実行。

---

共通ステップ（全モード共通）

ステップ 1: Issue 作成

gh issue create で Issue を作成:

gh repo view --json owner,name
gh issue create --title "{タイトル}" --body "{本文}" --label "{ラベル}"

Issue タイトル: タスク内容を簡潔に（50文字以内）

Issue ラベル:

• enhancement: 新機能
• bug: バグ修正
• documentation: ドキュメント
• improvement: リファクタリング

Issue 本文フォーマット:

## 概要

{タスクの目的・背景}

## タスク

- [ ] {サブタスク1}
- [ ] {サブタスク2}
- [ ] {サブタスク3}

## 完了条件

- {達成すべき条件1}
- {達成すべき条件2}

ステップ 2: ブランチ作成

git fetch origin main
git checkout main
git pull origin main
git checkout -b feature/{issue番号}

ブランチ名プレフィックス:

• enhancement → feature/{issue番号}
• bug → fix/{issue番号}
• documentation → docs/{issue番号}
• improvement → refactor/{issue番号}

ステップ 3: 実装

Issue の内容に基づいてコードを実装:

1. 必要なファイルを特定
2. コード変更を実施
3. 動作確認（可能な場合）
4. サブタスク完了時に Issue を更新（バックグラウンド）

サブタスク完了時の Issue 更新

各サブタスクの実装が完了したら、バックグラウンドエージェントを使用して Issue のチェックボックスを更新します。これにより、実装作業を中断せずに進捗を Issue に反映できます。

実行方法:

サブタスク完了時に、Task ツールを run_in_background: true で実行:

Task tool を使用:
  subagent_type: "general-purpose"
  run_in_background: true
  prompt: |
    Issue #{issue番号} のタスクチェックボックスを更新してください。
    完了したタスク: "{完了したサブタスク名}"

    手順:
    1. gh issue view {issue番号} --json body --jq '.body' で本文取得
    2. 該当タスクの "- [ ]" を "- [x]" に変更
       - 本文に改行やクォートが含まれる場合は適切にエスケープ
    3. gh issue edit {issue番号} --body "{更新後の本文}" で更新

    エラー時:
    - Issue が閉じられている場合はスキップ
    - 権限不足の場合は警告のみ出力
    - 更新失敗してもメイン処理には影響させない

更新ルール:

• - [ ] {サブタスク} → - [x] {サブタスク} に変更
• 原則としてサブタスク名の完全一致で該当タスクを特定する（やむを得ず部分一致を用いる場合は、前方一致などに限定し一意に特定できることを確認してから更新する）
• バックグラウンドで実行し、メイン実装をブロックしない

注意: Issue 更新の成否に関わらず、メインの実装作業は継続します。

ステップ 4: セキュリティチェック＆自己レビュー

セキュリティチェック:

git status

以下のパターンを検出したら警告:

• .env* - 環境変数
• *.pem, *.key - 秘密鍵
• credentials.json - 認証情報
• node_modules/, vendor/ - 依存パッケージ

自己レビュー:

git diff

以下の観点でチェック:

• コード品質・命名規則
• セキュリティ（OWASP Top 10）
• パフォーマンス（N+1、メモリリーク）

ステップ 5: ユーザー確認

重要: ここでユーザーに確認を求める。

## 変更内容の確認

以下の変更をコミットします:

{git diff --stat の出力}

### 変更ファイル一覧
{変更ファイルリスト}

### 自己レビュー結果
{レビューで確認した内容のサマリー}

### コミットメッセージ
{自動生成されたメッセージ}

この内容でコミット・プッシュ・PR作成を実行してよろしいですか？

ステップ 6: Issue チェックボックス完了更新

ユーザー確認後、コミット前に Issue の残りのチェックボックスを含め、全てを完了状態に更新します。

重要: これは同期実行で行い、結果を確認してからコミットに進みます。

手順:

1. Issue の現在の状態を取得:

   gh issue view {issue番号} --json body,state
   

2. Issue がオープン状態であることを確認。クローズ済みの場合はスキップ。

3. 本文内の未完了チェックボックスを完了状態に更新:

   • - [ ] {タスク} → - [x] {タスク} に全て置換
   • 実装例: sed や awk、gh api などで本文を取得し、- [ ] を - [x] に置換してから更新します（[] や \ などの記号はシェル上でエスケープが必要になる点や、複数行本文を扱う場合は一時ファイル経由で編集すると安全な点に注意してください）

4. Issue を更新:

   gh issue edit {issue番号} --body "{更新後の本文}"
   

5. 更新結果を報告:

   Issue #{issue番号} のチェックボックスを更新しました（{更新数}件）
   

エラー時の動作:

• Issue 更新に失敗しても、コミット処理は継続します
• エラーが発生した場合は警告メッセージを表示しますが、フローは停止しません

注意: この更新は、ステップ 3 のバックグラウンド更新で既に完了済みのチェックボックスも含め、全てを確実に完了状態にそろえるための最終確認として機能します（同じ Issue に対して複数回実行しても結果は変わりません）。

ステップ 7: コミット

git add .
git commit -m "{コミットメッセージ}"

コミットメッセージ形式:

1. まず .claude/settings.json の git.commitMessage 設定を確認
2. 設定がある場合はその形式に従う
3. 設定がない場合は以下のデフォルト形式を使用

デフォルト形式 (Conventional Commits・日本語):

プレフィックス	用途
feat:	新機能
fix:	バグ修正
docs:	ドキュメント
refactor:	リファクタリング
chore:	その他
test:	テスト
style:	スタイル修正
perf:	パフォーマンス改善

ルール:

• 日本語で記述
• 1行で簡潔に（50文字以内推奨）
• Issue 参照: 末尾に (#N) 形式で追加

例:

feat: ユーザー認証機能を追加 (#30)
fix: ログイン時のエラーを修正 (#31)
docs: READMEを更新

※ コミットメッセージ設定は /shiiman-git:commit-message --set で変更可能

ステップ 8: プッシュ

git push -u origin {ブランチ名}

ステップ 9: PR 作成

gh pr create --title "{PRタイトル}" --body "{PR本文}"

PR 本文

## 概要

{変更内容の説明}

## 変更内容

- {変更点1}
- {変更点2}

## 関連 Issue

Closes #{issue番号}

## テスト計画

- [ ] {テスト項目}

ステップ 10: 完了報告

## 開発フロー完了

### 作成された Issue
- #{issue番号}: {タイトル}

### 作成されたブランチ
- {ブランチ名}

### 作成された PR
- PR #{pr番号}: {タイトル}
- URL: {pr_url}

PR がマージされると Issue #{issue番号} は自動的にクローズされます。

重要な注意事項

• ✅ モード 2 のみ EnterPlanMode を使用
• ✅ モード 1, 3 では plan mode を使用しない
• ✅ コミット前に必ずユーザー確認を行う
• ✅ 機密ファイルをコミットしない
• ✅ .claude/settings.json のコミットメッセージ設定に従う（設定がなければ Conventional Commits）
• ✅ PR で Closes #N を使用して Issue を参照
• ❌ ユーザー確認なしでコミット・プッシュしない
• ❌ main ブランチに直接コミットしない