「Claude Codeで開発してるけど、1つずつ順番にIssueを片付けるのが遅い…」

そんな悩みを解決するために、Issue起票から並列開発、PR作成までを一気通貫で自動化するワークフローを構築しました。

具体的には、Claude CodeのSkillsを組み合わせて、以下を実現しています：

1. 要件定義 — Claude Codeに「〇〇を作りたい。要件定義して」と伝え、対話しながら仕様を固める
2. /issue-create — 固まった要件からGitHub Issueを構造化して起票
3. /dev-plan — Issue群から依存関係を分析し、並列開発用の実行プロンプトを自動生成
4. /gtr-workflow — git worktreeで隔離された環境を作り、複数のClaude Codeセッションで同時に実装

このワークフローで一番大事なのは、実は最初の「要件定義」です。

実装・テスト・PR作成を自動化したことで、人間が本当に時間をかけるべき「何を作るか」の部分に集中できるようになりました。要件が曖昧なままIssueを作っても、AIは曖昧なまま実装してしまいます。逆に、要件さえしっかり固まっていれば、あとはプロンプトをコピペするだけで実装が完了します。

実行を自動化することで、思考に集中できる。 これがこのワークフロー最大のメリットです。

この記事では、各スキルの仕組みと実際の使い方を、プロダクト開発での実例とともに紹介します。

対象読者

• Claude Codeを日常的に使っている開発者
• 複数機能を効率よく並列開発したい人
• Claude CodeのSkills機能に興味がある人

この記事で得られること

• Issue駆動 × AI並列開発の具体的なワークフロー設計
• Claude Code Skillsの実践的な活用パターン
• git worktreeを活用した安全な並列開発の仕組み

目次

章内容1全体像 — 3つのスキルが繋がるパイプライン2/issue-create — 雑メモからIssueを構造化3/dev-plan — Issue群をWave構造に分解4/gtr-workflow — worktreeで並列開発5実例 — 10個のIssueを4Waveで並列開発した話6動作確認 — worktree環境での開発サーバー起動7Skills の作り方8まとめ1. 全体像 — 3つのスキルが繋がるパイプライン

まずワークフロー全体の流れです。

ポイントは「人間がやるのはプロンプトのコピペだけ」 ということです。

Issue起票の構造化も、依存関係の分析も、ブランチ作成も、実装も、PR作成も、すべてClaude Codeが自律的に実行します。人間は各ステップの出力を確認して、次のステップに進む判断をするだけです。

2. 要件定義 → /issue-create でIssueを構造化

まず要件定義に時間をかける

実際の開発では、いきなり /issue-create を使うことは少ないです。まずClaude Codeに「〇〇を作りたい。要件定義して」と伝え、対話しながら仕様を固めます。

> 我想做一個任務甘特圖（Gantt chart）的顯示功能。請幫我做要件定義。

Claude Codeが質問してくるので、それに答えながら要件を詰めていきます。「表示單位是日/週/月？」「要支援拖曳更改期間嗎？」「要不要顯示依賴關係的箭頭？」——この對話が一番重要で、一番時間をかけるところです。

要件が固まったら /issue-create でIssueにします。

/issue-create は何をするスキルか

固まった要件をGitHub Issueとして構造化して起票してくれます。

使い方

Claude Codeで /issue-create と打ち、要件を伝えるだけです。

> /issue-create

在任務列表畫面新增優先度欄位。
另外操作欄的 UI 太雜，希望重整。

これだけで、以下のような構造化されたIssueが作成されます：

<span>## 背景・目的</span>
任務列表畫面的優先度顯示不足，且操作欄的 UI 有改進空間。

<span>## 要件</span>
<span>### 要做的事</span>
<span>-</span> 在任務列表表格新增優先度欄位
<span>-</span> 整理操作欄的 UI（重檢按鈕配置）

<span>### 不做的事</span>
<span>-</span> 實作優先度自動計算的邏輯

<span>## 完成條件（DoD）</span>
<span>-</span> [ ] 優先度欄位在任務列表表格中顯示
<span>-</span> [ ] 操作欄的按鈕已整理，主要操作變得清楚
<span>-</span> [ ] 既有的 E2E 測試通過

<span>## 未確定事項・需確認事項</span>
<span>-</span> 優先度的選項（High/Medium/Low 三段還是數值指定？）

設計のこだわり

このスキルの最大の特徴は「推測しない」 ことです。

メモに書かれていない仕様は絶対に推測せず、不明点があれば AskUserQuestion で質問します。「たぶんこうだろう」でIssueを作ると、実装時に手戻りが発生するからです。

3. /dev-plan — Issue群をWave構造に分解

何をするスキルか

複数のIssue番号を渡すと、依存関係を分析して Wave（執行序列）構造を決定し、各IssueをClaude Codeで実行可能なプロンプトとして出力します。

使い方

> /dev-plan #10-12

すると以下の流れで対話的に計画が作られます：

Wave構造の判断基準

スキルは以下のルールで依存関係を判断します：

パターン判断DBスキーマ変更を含む最初のWaveに配置UI基盤（ナビ、レイアウト）の変更早いWaveに配置独立した画面・機能並列可能 → 同じWaveに配置明示的な依存（「〜の上に追加」）後のWaveに配置### 出力例

実際に生成されるプロンプトファイルはこんな形式です：

<span># ガントチャート機能 — Claude Code 実行プロンプト</span>

<span>## 実行順序</span>

<span>```</span><span>
</span>Wave 1（直列）: #10 → #11 → #12
<span>```</span>

各WaveのPRがdevelopにマージ済みであること。
<span>
---
</span>
<span>## Wave 1（直列）</span>

<span>### #10 タスクに開始日・終了日フィールドを追加</span>

<span>```</span><span>
</span>/gtr-workflow で develop ブランチから feature/task-date-fields
ブランチを作成して作業して。

まず gh issue view 10 でIssue内容を読んで。
既存の prisma/schema/models/Task.prisma を確認して。

Issue #10 の完了条件（DoD）を全て満たすように実装して。
確認できたら /pull-request スキルを使って develop に向けてPRを作成して。
コミットメッセージに "closes #10" を含めて。
<span>```</span>

<span>### #11 ガントチャートUIコンポーネント</span>

<span>```</span><span>
</span>/gtr-workflow で develop ブランチから feature/gantt-chart-ui
ブランチを作成して作業して。
...
<span>```</span>

このプロンプトをClaude Codeにコピペするだけで、Issue読み込み → 実装 → テスト → PR作成が全自動で走ります。

補足ドキュメントの自動検出

Issue本文に docs/SPEC-xxx.md への参照や、既存コードへの言及がある場合、プロンプトに自動的に参照指示が追加されます。

補足として docs/SPEC-gantt-chart.md を参照して。
既存の src/app/projects/[id]/tasks/ のコードを参考にして。

これにより、Claude Codeが必要なコンテキストを漏れなく取得できます。

4. /gtr-workflow — worktreeで並列開発

なぜ git worktree なのか

通常のgitブランチ運用では、1つのディレクトリに1つのブランチしかチェックアウトできません。

複数のClaude Codeセッションが同じディレクトリで同時に作業すると、ファイルの競合が発生します。

git worktreeを使うと、ブランチごとに独立したディレクトリを作成できます。

~/dev/myapp/                          ← 本體 (develop)
~/dev/myapp-worktrees/feature-auth/    ← worktree 1
~/dev/myapp-worktrees/feature-ui/      ← worktree 2
~/dev/myapp-worktrees/feature-api/     ← worktree 3

各ディレクトリは完全に独立しているので、複数のClaude Codeが安全に同時作業できます。

/gtr-workflow の動作

プロンプト内の /gtr-workflow が実行されると、以下が自動的に行われます：

.gtrconfig — worktree の自動セットアップ

プロジェクトルートに .gtrconfig を置くことで、worktree作成時の初期化を自動化できます。

<span>[copy]</span><span>
</span><span>include</span><span> </span><span>=</span><span> </span><span>.env*        # 環境変數檔案をコピー</span>
<span>include</span><span> </span><span>=</span><span> </span><span>CLAUDE.md    # プロジェクト指示をコピー</span>
<span>
</span><span>[hooks]</span><span>
</span><span>postCreate</span><span> </span><span>=</span><span> </span><span>npm install  # 依存関係を自動インストール</span>

これにより、worktreeが作成された瞬間から開発可能な状態になります。

並列実行の実際の流れ

Wave 2で3つのIssueを並列開発する場合の物理的な動きです：

人間がやることは「プロンプトのコピペ」と「PRのレビュー＆マージ」だけです。

5. 実例 — 10個のIssueを4Waveで並列開発した話

実際にこのワークフローで、通知システムの大規模リファクタリングを進めた例を紹介します。

プロジェクト構造

Wave 1:       #30（通知共通基盤セットアップ）
Wave 2（2並列）: #31（メール通知）, #32（Slack通知）
Wave 3（5並列）: #33, #34, #35, #36, #38（各イベントトリガーの実装）
Wave 4（2並列）: #37（リアルタイム通知UI）, #39（統合テスト）

/dev-plan が生成したプロンプトの一部

Wave 3の5並列はこんな感じです。5つのターミナルを開いて、それぞれのプロンプトを貼り付けて実行しました：

/gtr-workflow で feature/notification-system ブランチから
feature/33-task-assigned-trigger ブランチを作成して作業して。

まず gh issue view 33 でIssue内容を読んで。
補足として docs/specs/SPEC-notification-system.md を参照して。

Issue #33 の完了条件（DoD）を全て満たすように実装して。
実装が完了したら /pull-request スキルを使って
feature/notification-system に向けてPRを作成して。
コミットメッセージに "closes #33" を含めて。

実際の worktree 状態

開発中の git worktree list の出力（イメージ）：

~/dev/myapp                                      [develop]
~/dev/myapp-worktrees/feature-notification-base   [feature/notification-base]
~/dev/myapp-worktrees/feature-email-notify        [feature/email-notify]
~/dev/myapp-worktrees/feature-slack-notify        [feature/slack-notify]
~/dev/myapp-worktrees/feature-task-assigned       [feature/task-assigned-trigger]
~/dev/myapp-worktrees/feature-realtime-ui         [feature/realtime-notification-ui]

6つのworktreeが同時に存在し、それぞれ独立したブランチで作業が進行しています。

6. 動作確認 — worktree環境での開發伺服器起動

worktreeの動作確認がめんどくさい問題

worktreeで並列開発すると、動作確認が地味にめんどくさいです。

通常の開発なら npm run dev で済みますが、worktreeでは：

• worktreeのディレクトリに移動しないといけない
• npm install が必要（postCreateフックで済んでいればOKだが）
• ポートが被らないように変更が必要（メインが3000を使っていると起動できない）
• 認証系の環境変数（BETTER_AUTH_URL 等）もポートに合わせて変更が必要

これを毎回手動でやるのはつらいので、wt-dev というシェル関数を作りました。

wt-dev — worktreeの開發サーバーをワンコマンドで起動

.zshrc に以下を追加します：

wt-dev() {
  local name="${1//\//-}"
  local port="${2:-3001}"
  local dir="$HOME/dev/myapp-worktrees/$name"
  if [ ! -d "$dir" ]; then
    echo "worktree not found: $dir"
    return 1
  fi
  local url="https://localhost:$port"
  (cd "$dir" && npm install --silent && \
   PORT=$port BETTER_AUTH_URL=$url NEXT_PUBLIC_APP_URL=$url npm run dev)
}

使い方はシンプルです：

# 只要指定分支名（預設埠號: 3001）
wt-dev feature-auth

# 也可以指定埠號
wt-dev feature-auth 3002

これで、メインの開發サーバー（ポート3000）を立ち上げたまま、worktreeの開發サーバーを別ポートで起動して動作確認できます。

並列開發時の動作確認イメージ

ターミナル 1: make dev                       → https://localhost:3000 (メイン)
ターミナル 2: wt-dev feature-auth            → https://localhost:3001
ターミナル 3: wt-dev feature-ui 3002         → https://localhost:3002
ターミナル 4: wt-dev feature-api 3003        → https://localhost:3003

DBやMinIOなどのインフラはDocker Composeで共有しているので、開發サーバーだけ別ポートで立てれば各worktreeの動作確認ができます。

7. Skills の作り方

このワークフローは、Claude Codeの Skills 機能で実現しています。Skillsは .claude/skills/ ディレクトリに SKILL.md を配置するだけで作成できます。

ディレクトリ構造

.claude/skills/
├── issue-create/
│   ├── SKILL.md              # スキル定義（プロンプト）
│   └── references/
│       └── output-structure.md  # 出力フォーマットの参照資料
├── dev-plan/
│   ├── SKILL.md
│   └── references/
│       ├── prompt-template.md   # プロンプトテンプレート
│       └── output-example.md    # 出力例
└── pull-request/
    ├── SKILL.md
    └── references/
        └── pr-template.md       # PRテンプレート

SKILL.md の構造

SKILL.md のフロントマターでスキルのメタ情報を定義し、本文にプロンプト（指示）を書きます。

---
name: issue-create
description: 從雜亂的要件產生 GitHub Issue
---

# Issue 作成スキル

## あなたの役割
請分析使用者輸入的文字，
並建立結構化的 GitHub Issue。

## 手順
1. 從輸入文字抽出要件
2. 若有不明點則提問（不做推測）
3. 依照 references/output-structure.md 的格式建立 Issue
4. 使用 `gh issue create` 進行起票

## 制約
- 未記載的規格不要推測
- 不要寫程式碼
- 不要寫技術選型或實作方針

references/ の活用

references/ ディレクトリに参照資料を置くと、スキル実行時にClaude Codeが自動的に読み込みます。テンプレートや出力例を分離することで、SKILL.md本体をシンプルに保てます。

スキル連携のコツ

スキル同士を連携させるには、出力形式を統一することが重要です。

• /issue-create の出力（Issue）を /dev-plan が読む → Issueのフォーマットを統一
• /dev-plan の出力（プロンプト）に /gtr-workflow の呼び出しを含める → テンプレートで定型化
• /gtr-workflow の実行結果を /pull-request に繋げる → プロンプト内に指示を記載

8. まとめ

このワークフローで変わったこと

BeforeAfter実装に時間を取られて要件が雑になる実行を自動化し、要件定義に集中できるIssueを手動で書く/issue-create で構造化して起票1つずつ順番に実装Wave構造で並列開発ブランチ切り替えで作業中断worktreeで完全隔離PR作成が面倒/pull-request で自動生成開発計画を頭の中で管理/dev-plan でプロンプトとして文書化### 要点

• /issue-create → 推測しない。不明点は質問する。構造化されたIssueを起票
• /dev-plan → 依存関係を分析してWave構造に分解。実行可能なプロンプトを生成
• /gtr-workflow → git worktreeで隔離環境を作り、複数Claude Codeで並列開発
• 人間がやるのは「プロンプトのコピペ」と「PRレビュー」だけ

スキルを使ってみる

この記事で紹介したスキルは以下のリポジトリで公開しています。

以下のコマンドでインストールできます：

# 全スキルを一括インストール
npx skills add okazuki58/agent-skills -y

# 個別にインストール
npx skills add okazuki58/agent-skills --skill <skill-name> -y

参考リンク

• Claude Code Skills 公式ドキュメント
• git-worktree-runner (gtr)

株式会社シンシアでは、実務未経験のエンジニアの方や学生エンジニアインターンを採用し一緒に働いています。
※ シンシアにおける働き方の様子はこちら

原文出處：https://qiita.com/kazuki_ogawa/items/c05c3aed3bf8e46a7ddb