Cursor Skillsで構築する、GitHub issueの自動開発ワークフロー

はじめに

昨今、GitHub Issue の内容をもとに、ブランチ作成から実装、内部レビュー、PR 作成までを AIを用いて一連の流れとして進めたいといった場面が多くなってきました。

本稿では、Cursor の Skills を用いて、GitHub Issueのリンクを渡すだけで開発フローを起動できる仕組みを紹介します。

• どのような構成（Skills、Commands、Agents）で実現しているか
• ワークフローの全体像と各ステップの役割
• 実際の使い方の例
• 付録として、本ワークフローの定義ファイル全文（コピペで同等のワークフローを構築できます）

全体構成：Skills・Commands・Agents の三層

このワークフローは、役割の異なる3種類の部品を組み合わせて実現しています。

ワークフローの視覚的イメージ

なぜ Commands とサブエージェントを切り出すのか

Commands を個別に切り出す理由

各処理を Commands として独立させているのは、各処理を単体でも使えるようにするためです。

例えば、既にブランチを切って自身で実装が終わっているコードに対して、/run-review を呼び出してレビューのみを実行することも可能です。

コミットだけ実施したいときは /commit を利用する、PR 本文の下書きだけ欲しいときは /make-pr を単独で実行するなど、全体のワークフローと共に個別でも利用できるように便利にしています。

手順を Skills に全部書き込んでしまうと、再利用性が下がり、メンテナンスも Skill 1 ファイルに集中してしまいます。Commands に分割することで、手順の更新は該当 Commands だけ直せばよく、Skills は「呼び出し順序と確認ポイント」に専念できます。

各 Commands はチャットで /create-branch のようにスラッシュコマンドとしても個別に呼び出せるため、今回のAIに開発を全て任せるという用途に限らず利用できます。

サブエージェントを切り出す理由

コードレビューは code-reviewer というサブエージェントに任せています。独立させている理由は次の 2 点です。

1. レビュー専門の機能として独立させる レビュー用の観点（機能面・コード品質・セキュリティ）と、修正は行わず指摘のみ報告する、という役割をサブエージェント側に固定しています。実装を担当する親エージェントとレビューを担当する子エージェントを分けることで、「自分で書いたコードを自分で OK してしまう」という偏りを避けやすくなります。
2. モデルを固定する code-reviewer の frontmatter でレビュー用モデル（本環境では claude-opus-4-8）を指定しています。
   開発指示を行ったチャット上で別モデルが選ばれている状態でも、レビュー時のモデルを固定化できるため、レビューの品質にムラが出ることを回避できます。
   レビュー基準・品質の再現性を保つうえで、モデル固定は有効です。
   ※レビューに利用するモデルは、自身で調整してください。レビュー品質優先、速度優先、トークン（低予算）優先など、目的に応じて選択する必要があります。

ワークフローの流れ

dev-workflow Skills の全体像は次のとおりです。重要なステップの前後には 【確認】 を挟み、指示者の判断を経てから次に進みます。

実行フロー

Step 1: ブランチ作成
↓ 【確認】ブランチ名をユーザーに確認
Step 2: 実装
Step 3: コミット
Step 4: AIレビュー・レビュー結果対応
Step 5: PR作成
↓ 【確認】作成予定の PR の内容をユーザーに確認

Step 1: ブランチ作成

create-branch Commands に従い、gh issue view で Issue のタイトル・本文・ラベルを取得。ラベルに応じてプレフィックスを決めます。

• ラベル bug → bug/issue-<番号>
• ラベル feature → feature/issue-<番号>
• 上記以外 → ユーザーにプレフィックスを確認

ブランチ名を生成したら、作成前にユーザーへ確認します。

「ブランチ名は feature/issue-123 でよいですか？」

Step 2: 実装

Issue の受け入れ条件を満たすコードを書きます。既存のコーディング規約に従い、動作検証まで実行。実装方針が曖昧な場合は、解釈を提示してユーザーに確認してから進めます。

Step 3: コミット

commit Commands に従い、変更内容を確認してからステージ・コミットします。無関係な変更は含めず、意味のある単位で分けることが重要。

Step 4: AI レビュー

run-review Commands が code-reviewer サブエージェントを呼び出します。

1. デフォルトブランチ名を取得
2. git diff origin/<デフォルトブランチ>...HEAD で差分を取得
3. サブエージェントがレビュー（機能面・コード品質・セキュリティ）
4. 指摘があれば修正し、再度レビュー
5. 「LGTM」 が返るまで 2〜4 を繰り返す

レビュー完了後、指摘内容と修正概要をユーザーに報告。

Step 5: PR 作成

make-pr Commands に従い、リモートへプッシュしたうえで PR を作成。リポジトリ内の PR テンプレートがあれば優先的に利用し、なければ Commands 内のデフォルトテンプレートを使います。

PR のタイトルと本文を生成したら、gh pr createの実行前にユーザーへ確認。指摘があれば反映し、再度確認するループを回します。

各ファイルの役割（参照一覧）

各ファイルの全文は末尾の 付録: 定義ファイル全文 に掲載しています。内容は執筆時点の実ファイルと同一です。

使い方の例

例 1: Issue から PR まで一気通貫

チャットで Issue リンクと依頼文を送ります。

https://github.com/example-org/example-repo/issues/1
この Issue の作業を開始して

エージェントが dev-workflow Skills を読み込み、Step 1 から順に進めます。ブランチ名と PR 内容の確認で止まったら、内容を確認して承認または修正指示を返します。

例 2: レビューだけ実行したい

実装とコミットは済んでいる場合:

/run-review

run-review Commands が単体で実行され、code-reviewer による差分レビューが走ります。

例 3: ブランチ名だけ先に決めたい

/create-branch
Issue #42 用のブランチを作成して

ワークフロー全体を回さず、ブランチ作成 Commands だけを利用可能です。

指示者が介在するポイント

完全自動ではなく、次のタイミングで指示者の判断を挟む設計にしているのがポイントです。
これによって、勝手なPR作成などを防いでいます。

ブランチ名や PR 文案の自動生成は便利ですが、最終的な命名や説明文は開発者が確認する前提です。

もし実施しようとしているIssue の要件が大きすぎる場合は、Issue を分割してから Skills を起動する運用も合わせて検討してください。

まとめ

• Skills（dev-workflow）が Issue 起点の開発フロー全体をオーケストレーションし、Commands が各ステップの手順を、Agent（code-reviewer）がレビューを担当する三層構成です。
• Commands を切り出すことで、レビューや PR 作成などを単体でも再利用できます。
• サブエージェントを独立させ、レビュー専用・モデル固定にすることで、レビュー品質の再現性を保っています。
• 変更量を抑え、Issue を適切な粒度に分けて実行することが、AI レビューを含む自動開発フローを安定させるうえで重要です。

Issue リンクを渡すだけで「ブランチ → 実装 → コミット → レビュー → PR」まで進められる仕組みは、Cursor Skills の「状況に応じて引き出す手順書」という特性を活かした典型例です。

既存の Commands や Agent を組み合わせることで、チームの開発フローに合わせたカスタマイズも容易です。

構築手順（コピペで今回のワークフローを再現可能）

前提

• Cursor（Agent Skills 対応版）
• GitHub CLI（gh） がインストール済みで、gh auth login 済み
• 対象リポジトリを git clone 済み
• 実行するCursorで対象リポジトリフォルダーを開いていること

ディレクトリ構成

個人全体で使う場合はホーム配下、チーム共有する場合はプロジェクトのリポジトリ直下の .cursor/ 配下に置きます。以下は個人利用（~/.cursor/）の例です。

~/.cursor/
├── skills/
│   └── dev-workflow/
│       └── SKILL.md
│
├── commands/
│   ├── create-branch.md
│   ├── commit.md
│   ├── run-review.md
│   └── make-pr.md
└── agents/
    └── code-reviewer.md

手順

1. 上記ディレクトリを作成
2. 付録 の各コードブロックを、対応するパスにそのまま保存
3. code-reviewer.md の model を、利用可能なモデル名に必要に応じて変更
4. Cursor を再起動（Skills / Commands / Agents の再読み込み）
5. 対象リポジトリを Cursor で開き、Issue リンクと指示文を渡して動作確認

Commands ファイル名（例: create-branch.md）がそのままチャットの /create-branch コマンド名になります。

Skills は description に基づき自動選択されるほか、@dev-workflow で明示的に実行することも可能です。

付録: 定義ファイル全文

以下をそのままコピーして、各パスに保存してください。

※ご利用にあたっての注意点
下記に掲載するSkills、Comands、Agentsは、動作を保証するものではありません。
環境や生成AIのアップデートによって挙動が変わる可能性がありますので、導入・ご利用の際は自己責任にてお願いいたします。

---
name: dev-workflow
description: issueのリンクから開発作業を開始する。ブランチ作成、実装、AIレビュー、PR作成までの一連の開発フローを実行する。
---

# 開発ワークフロー

## When to Use

- GitHubのissueリンクを渡されて「作業を開始して」と依頼されたとき

## Instructions

### 全体の流れ

issueリンクを受け取ったら、以下の順序で作業を進める。
【確認】という部分においては、必ずユーザーの判断を経てから次に進むこと。

Step 1: ブランチ作成
  ↓ 【確認】生成するブランチ名をユーザーに確認し、許可が出ればブランチ作成
Step 2: 実装
Step 3: コミット
Step 4: AIレビュー・レビュー結果対応
Step 5: PR作成
  ↓ 【確認】PRの内容をユーザーに確認し、許可が出れば作成

### Step 1: ブランチ作成

`~/.cursor/commands/create-branch.md` の手順に従ってブランチを作成する。

**確認ポイント**: ブランチ名を生成したら、作成前にユーザーへ確認する。
「ブランチ名は `feature/123-add-user-profile` でよいですか」

### Step 2: 実装

issueの要件に沿って実装を進める。

- issueの受け入れ条件を満たすコードを書く
- 既存のコーディング規約に従う
- 必ず動作の検証を行い、issueの要件を満たすか確認すること

**確認ポイント**: 実装方針に迷う内容があればユーザーへ確認すること。
issueの要件が曖昧な場合も、解釈を提示して確認を取ってから進める。

### Step 3: コミット

`~/.cursor/commands/commit.md` の手順に従ってコミットを実施する。

### Step 4: AIレビュー

`~/.cursor/commands/run-review.md` の手順に従ってレビューを実施する。
`code-reviewer` サブエージェントを呼び出し、差分をレビューする。
レビューで指摘が出た場合は修正し、再度レビューを実施する。
「LGTM」が返ってくるまでレビューと修正をくり返すこと。
「LGTM」が返ってきたら、ユーザーへ指摘内容と修正概要を報告する。

### Step 5: PR作成

`~/.cursor/commands/make-pr.md` の手順に従ってPRを作成する。

**確認ポイント**: PRのタイトルと本文を生成したら、作成前にユーザーへ確認する。
ユーザーから指摘があれば、指摘反映後のタイトルと本文を再度提示し、ユーザーへ確認する。
これをユーザーの指摘がなくなるまでくり返すこと。
`gh pr create` の実行は、ユーザーの承認後に行う。

# ブランチ作成

issueの内容からブランチを作成する。

## 手順

1. `gh issue view <issue番号> --repo <リポジトリ>` でissueの内容を取得する
2. issueのタイトル、本文、ラベルを確認する
3. ブランチ名を決定して作成する

git checkout -b <プレフィックス>/issue-<issue番号>

## ブランチ命名規則

下記命名規則に従うこと

- issueのラベルがbug → プレフィックス = bug
- issueのラベルがfeature → プレフィックス = feature
- issueのラベルが上記以外 → プレフィックスをユーザーへ確認
- issue番号 → issueの番号

例1: feature/issue-123
例2: bug/issue-123

# コミット実行

現在の作業内容を適切な粒度でコミットする。

## 手順

1. `git status` で変更内容を確認する
2. コミット対象を決め、不要な変更が混ざっていないか確認する
3. `git add <対象ファイル>` で必要なファイルのみステージする
4. `git diff --staged` でステージ済み差分を確認する
5. 変更内容を元に、コミットメッセージを作成する
6. `git commit -m "<コミットメッセージ>"` を実行する
7. `git status` でコミット後の状態を確認する

## 注意事項

- 無関係な変更はコミットに含めない
- コミットは意味のある単位で分ける
- コミットメッセージは実装内容がわかるテキストにすること

# コードレビュー実行

現在のブランチの差分をレビューする。

## 手順

1. `gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'` でデフォルトブランチ名を取得する
2. `git diff origin/<デフォルトブランチ>...HEAD` で差分を取得する
3. `code-reviewer` サブエージェントにレビューを依頼する
4. 指摘があれば修正し、再度レビューを実施する
5. 「LGTM」が返ってくるまで、手順2~4を繰り返す
6. 「LGTM」が返ってきたら完了

# PR作成

現在のブランチでPRを作成する。

## 手順

1. `git push origin HEAD` でリモートにプッシュする
2. PRタイトルはコミットメッセージから生成する
3. 作業中のリポジトリ内にPRテンプレートがあるか確認する
   - 優先順:
     - `.github/pull_request_template.md`
     - `.github/PULL_REQUEST_TEMPLATE.md`
     - `.github/PULL_REQUEST_TEMPLATE/*.md`
4. テンプレートが見つかった場合は、その内容をPR本文として利用する
   - 複数見つかった場合は候補を提示し、どれを使うかユーザーに確認する
5. テンプレートが見つからない場合は、このファイルの「PRテンプレート」セクションを利用する
6. 生成したPRタイトル・本文をユーザーに確認する
7. ユーザー承認後に `gh pr create` でPRを作成する

## PRテンプレート

タイトル: <変更内容の要約>

## 詳細 / Details

<実装内容の概要>

## 関連チケット URL / Issue URL

- <関連issueのURL>

## 影響範囲 / Expected impact

<今回の修正が影響するコンポーネント、画面、機能名など>

## レビューで確認してほしい点 / Review

- [ ] <レビュー観点を箇条書き>

## 動作確認手順 / Operational acceptance testing(OAT)

- <動作確認手順を箇条書き>

---
name: code-reviewer
model: claude-opus-4-8
description: 現在ブランチの差分をレビューし、問題点と修正案のみを報告するレビュー専用サブエージェント
---

# コードレビュアー

## 役割

PRに含まれる差分をレビューし、問題点を報告するサブエージェント。

## レビュー観点

### 機能面
- issueの要件を満たしているか
- ユーザーに確認した仕様を満たしているか
- エッジケースが考慮されているか

### コード品質
- コーディング規約に違反していないか
- 不要なコードが残っていないか
- 保守性の高いコードになっているか

### セキュリティ
- ユーザー入力のバリデーションがあるか
- 機密情報がハードコードされていないか
- 脆弱性のある実装が残っていないか

## 手順

1. `gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'` でデフォルトブランチ名を取得する
2. `git diff origin/<デフォルトブランチ>...HEAD` で差分を取得する
3. 上記の観点でレビューする
4. 問題があれば、ファイル名・行番号・指摘内容・修正案を報告する
5. 問題がなければ「LGTM」と報告する

## 注意事項

- コードの修正はしない。指摘と修正案の報告のみを行う
- 修正するかは親エージェントが判断する
- コミット、プッシュ、PR作成などの操作は行わない

関連記事Cursor Commands活用術 ― レビューとPR作成の
自動化プロンプト

2025.12.04

関連記事Cursor Commands活用術 ― 単体テスト自動生成プロンプト

2025.11.25