- オーケストレーターとは
- 全体の構成
- commandを用意する
- skillをオーケストレーターにする
- サブエージェントで専門家を呼ぶ
- 二重管理を防ぐ構成
- 実際の使い方
- チームで共有する
- 現時点の制約
- まとめ
エンジニアの関口です。
開発チームには、暗黙の手順があります。issueを確認してブランチを切る。実装してレビューを通す。PRを立てる。手順自体は決まっているのに、毎回手動で回しています。
ブランチの命名規則やPRのテンプレートは、チームで決めたルールがあるはずです。でも、それを毎回思い出しながら作業するのは地味にコストがかかります。
Cursorには .cursor/commands/ にコマンドファイルを置いて /コマンド名 で叩く仕組みがあります。/make-pr でPRを作る、/create-branch でブランチを切る。個別の作業は、すでにcommandで自動化している方も多いのではないでしょうか。
ただ、commandは「個別の手順書」です。開発フロー全体を通して動かすには、commandを順番に呼び出す「指揮者」が必要です。
この記事では、Cursor Skillsをオーケストレーターとして使い、既存のcommandを束ねて開発フローを組み立てる方法を紹介します。
オーケストレーターとは
オーケストレーターは、複数の処理を決められた順序で呼び出し、全体の流れを制御する役割です。マイクロサービスのオーケストレーションパターンと同じ考え方です。
Cursorの文脈では、こうなります。
- command = 個別の手順書。
/make-prで単体実行できる - skill = オーケストレーター。commandを順番に呼び出して、開発フロー全体を制御する
- agent = 専門家。レビューなど特定の役割を担う
skillが全体の流れを知っていて、各ステップで対応するcommandやagentを呼び出す。この構成が「skillをオーケストレーターにする」ということです。
全体の構成
.cursor/
├── commands/
│ ├── create-branch.md # /create-branch で単体実行できる
│ ├── make-pr.md # /make-pr で単体実行できる
│ └── run-review.md # /run-review で単体実行できる
├── skills/
│ └── dev-workflow/
│ └── SKILL.md # オーケストレーター
└── agents/
└── code-reviewer.md # レビュー担当エージェント
commandは個別に /コマンド名 で叩ける。skillはissueリンクを受け取ったときに自動で読み込まれ、commandを順番に呼び出す。agentはskillから呼ばれて並行で動く。
commandを用意する
まず、個別の手順書となるcommandファイルを作ります。
ブランチ作成（create-branch.md）
# ブランチ作成 issueの内容からブランチを作成する。 ## 手順 1. `gh issue view <issue番号> --repo <リポジトリ>` でissueの内容を取得する 2. issueのタイトル、本文、ラベルを確認する 3. ブランチ名を決定して作成する git checkout -b <プレフィックス>/<issue番号>-<要約> ## ブランチ命名規則 issueのラベルに応じてプレフィックスを使い分ける。 - bug → fix/ - enhancement → feature/ - それ以外 → chore/ 例: feature/123-add-user-profile
PR作成（make-pr.md）
# PR作成 現在のブランチでPRを作成する。 ## 手順 1. `git push -u origin HEAD` でリモートにプッシュする 2. `gh pr create` でPRを作成する 3. PRタイトルはコミットメッセージから生成する 4. PR本文には関連issueへのリンクを含める ## PRテンプレート タイトル: <変更内容の要約> 本文: ### 概要 <変更内容> ### 関連issue close #<issue番号> ### 変更内容 <箇条書き> ### テスト <テスト方法や確認手順>
レビュー実行（run-review.md）
# コードレビュー実行 現在のブランチの差分をレビューする。 ## 手順 1. `git diff main...HEAD` で差分を取得する 2. code-reviewer サブエージェントにレビューを依頼する 3. 指摘があれば修正し、再度レビューを実施する 4. 「LGTM」が返ってきたら完了
これらのcommandは、それぞれ /create-branch、/make-pr、/run-review で単体実行できます。ブランチだけ切りたい、PRだけ立てたい。そんなときはcommandを直接叩けば済みます。
skillをオーケストレーターにする
次に、これらのcommandを束ねるskillを作ります。
--- name: dev-workflow description: issueのリンクから開発作業を開始する。ブランチ作成、実装、AIレビュー、PR作成までの一連の開発フローを実行する。 --- # 開発ワークフロー ## When to Use - GitHubのissueリンクを渡されて「作業を開始して」と依頼されたとき - 「このissueに取り組んで」と依頼されたとき - issueのURLが含まれるメッセージを受け取ったとき ## Instructions ### 全体の流れ issueリンクを受け取ったら、以下の順序で作業を進める。 各ステップの間に確認ポイントを挟み、人間の判断を経てから次に進む。 Step 1: ブランチ作成 ↓ 【確認】ブランチ名を確認 Step 2: 実装 ↓ 【確認】実装内容を確認 Step 3: AIレビュー ↓ 【確認】レビュー結果を確認 Step 4: PR作成 ↓ 【確認】PRの内容を確認してから作成 ### Step 1: ブランチ作成 `.cursor/commands/create-branch.md` の手順に従ってブランチを作成する。 **確認ポイント**: ブランチ名を生成したら、作成前にユーザーへ確認する。 「ブランチ名は `feature/123-add-user-profile` でよいですか」 ### Step 2: 実装 issueの要件に沿って実装を進める。 - issueの受け入れ条件を満たすコードを書く - 既存のコーディング規約に従う - テストが必要な場合はテストも書く - コミットメッセージにissue番号を含める **確認ポイント**: 実装方針に迷う場合はユーザーへ確認する。 issueの要件が曖昧な場合も、解釈を提示して確認を取ってから進める。 ### Step 3: AIレビュー `.cursor/commands/run-review.md` の手順に従ってレビューを実施する。 code-reviewer サブエージェントを呼び出し、差分をレビューする。 **確認ポイント**: レビューで指摘が出た場合、修正案をユーザーへ提示する。 修正するかどうかはユーザーが判断する。 ### Step 4: PR作成 `.cursor/commands/make-pr.md` の手順に従ってPRを作成する。 **確認ポイント**: PRのタイトルと本文を生成したら、作成前にユーザーへ確認する。 `gh pr create` の実行は、ユーザーの承認後に行う。
skillの Instructions に書いているのは「全体の流れ」と「各ステップでどのcommandを参照するか」だけです。個別の手順（ブランチ命名規則やPRテンプレート）はcommandファイルに書いてあります。
AIがskillを読み込むと、Step 1で .cursor/commands/create-branch.md を読みに行き、その中の手順を実行します。Step 4では .cursor/commands/make-pr.md を読みに行きます。skillは流れを制御するだけで、手順の詳細は持ちません。
サブエージェントで専門家を呼ぶ
Step 3のAIレビューでは、サブエージェントを活用します。.cursor/agents/code-reviewer.md にレビュー担当のエージェントを定義しておきます。
# コードレビュアー ## 役割 PRに含まれる差分をレビューし、問題点を報告するサブエージェント。 ## レビュー観点 ### 機能面 - issueの要件を満たしているか - エッジケースが考慮されているか ### コード品質 - コーディング規約に違反していないか - 不要なコードが残っていないか ### セキュリティ - ユーザー入力のバリデーションがあるか - 機密情報がハードコードされていないか ## 手順 1. `git diff main...HEAD` で差分を取得する 2. 上記の観点でレビューする 3. 問題があれば、ファイル名・行番号・指摘内容・修正案を報告する 4. 問題がなければ「LGTM」と報告する ## 注意事項 - コードの修正はしない。指摘と修正案の報告のみを行う - 修正するかは親エージェントが判断する
サブエージェントが指摘を返し、親エージェント（skill）が修正を判断する。オーケストレーターは専門家の報告を受けて、次のステップに進むか修正に戻るかを決めます。
二重管理を防ぐ構成
この構成の利点は、手順の本体がcommandに1箇所だけ存在することです。
PRテンプレートを変更したいときは commands/make-pr.md だけ更新すれば済みます。skillを書き換える必要はありません。skillはcommandファイルのパスを参照しているだけなので、commandの中身が変わればskillから呼ばれたときも自動で反映されます。
逆に、開発フローの順序を変えたいとき（たとえばレビューの前にlintを追加したいとき）は、skillのInstructionsに参照先を1行追加するだけです。
### Step 3: lint実行 `.cursor/commands/run-lint.md` の手順に従ってlintを実行する。 ### Step 4: AIレビュー `.cursor/commands/run-review.md` の手順に従ってレビューを実施する。
commandを増やしてもskillの変更は最小限。skillを変えてもcommandの中身は変わらない。それぞれの責務が分離されています。
実際の使い方
使い方は2通りあります。
開発フロー全体を動かす
CursorのチャットにissueのURLを貼って「作業を開始して」と伝えます。
https://github.com/your-org/your-repo/issues/123 このissueの作業を開始して
skillの「When to Use」にissueリンクを受け取った場合の条件を書いてあるので、AIが自動でskillを読み込みます。あとはskillが各commandを順番に呼び出して進めてくれます。
ただし、各ステップの間で確認が入ります。実際の流れはこうなります。
- AIがissueの内容を取得し、ブランチ名を提案する → ブランチ名の確認を求められる
- 承認したらブランチを作成し、実装を進める
- 実装完了後、サブエージェントがレビューする → 指摘内容の確認を求められる
- レビューを通過したらPRのタイトルと本文を生成する → PR内容の確認を求められる
- 承認したら
gh pr createを実行する
完全な自動化ではなく、要所で人間が判断する設計です。AIが勝手にPRを立てることはありません。確認ポイントをskillの中に明示しておくことで、AIが「ここで止まって聞く」という振る舞いを守ってくれます。
個別のcommandだけ叩く
PRだけ作りたいときは /make-pr で直接叩けます。ブランチだけ切りたいときは /create-branch です。skillを経由せず、commandだけで完結します。
開発フロー全体を通すか、個別の作業だけ実行するか。同じcommandファイルを使い回せるので、どちらの使い方も1つの構成で満たせます。
チームで共有する
skill、command、agentはすべてMarkdownファイルです。リポジトリにコミットすれば、チーム全員が同じ構成で開発を進められます。
新しいメンバーがissueのリンクを渡して「作業を開始して」と伝えれば、チームの開発規約に沿った作業が自動で始まります。ブランチの命名規則やPRのテンプレートを口頭で教える必要はありません。
この考え方は、Builder.ioの記事「Agent Skills vs. Rules vs. Commands」でも整理されています。
https://builder.io/blog/agent-skills-rules-commands
commands are for ergonomics. Skills are for policy.
commandはエルゴノミクス（操作の快適さ）のため、skillはポリシー（全体の流れや規約）のため。この分担を意識すると、二重管理に陥りません。
現時点の制約
スキル間の自動連携はできない
あるスキルが完了したら別のスキルを自動でトリガーする機能は、まだ実装されていません。CursorのフォーラムにFeature Requestとして上がっている段階です。
現状では、1つのスキルの中に複数ステップをまとめるか、サブエージェントで並行処理するかの選択になります。
コマンドの実行には確認が入る
Cursorのエージェントモードでは、シェルコマンドの実行前に確認ダイアログが表示されます。セキュリティ上の理由です。完全な自動実行ではなく、コマンドごとに「実行していいですか」と聞かれます。頻繁に実行するコマンドは、Cursor設定の「Allowed Commands」に登録しておくとスキップできます。
まとめ
Cursor Skillsは、開発フローのオーケストレーターとして機能します。
commandに個別の手順を書き、skillがそれらを束ねて全体の流れを制御する。agentが専門的な役割を担う。この3層構造で、issueのリンクを渡すだけでブランチ作成からPR作成まで動く開発フローが組み上がります。
手順の本体はcommandに1箇所だけ。二重管理にならず、commandを増やしてもskillの変更は最小限です。
まずは普段使っているcommandを棚卸しするところから始めてみてください。それらを束ねるskillを1つ作れば、開発フロー全体がつながります。
www.yayoi-kk.co.jp
弥生のエンジニアに関するnote記事もご覧ください。
note.yayoi-kk.co.jp
