前回まで

前回はスキルの種類の1つ目の分類として、ユーティリティスキルを紹介しました。今回は2つ目の分類としてワークフロースキルを紹介します。

この2つの違いは、ざっくりいうと粒度です。GitHubでの操作を例にしてみると、次のようなイメージになります。

• ユーティリティ: 「コミットする」のようなピンポイントの操作
• ワークフロー: 「ブランチを切る → 実装 → レビュー → CI → マージ」のような流れ全体

ユーティリティが手の中で完結する1つの作業だとすると、ワークフローはその作業をいくつもつないで、一連の流れをまるごと任せるためのスキルです。

PRベースの開発ワークフロー例

普段開発を行っているのであれば、日々の開発の流れを思い浮かべてみてください。たとえば、ブログのようなプロジェクトのリポジトリがあるとします。mainブランチへのコミットでCloudflare PagesやNetlifyなどにデプロイされる、というイメージです。

そういったプロジェクトでは、だいたい次のような流れで開発をするんじゃないでしょうか。

1. mainから新しいブランチを切る。ブランチ名はtopic/top-page-tabのような感じ
2. そのブランチで実装を完了させ、コミットしてプッシュ
3. チームメンバーにレビューを依頼 → 修正、承認
4. mainにマージ
5. CIがgreenであることを確認し、デプロイ先で変更が反映されているかをチェック

これら全部を1つのコマンドにまとめてAIエージェントに任せてしまうというのが、「ワークフロー」型のスキルです。

ワークフロースキルの作り方

作り方は基本的にユーティリティスキルと同じです。本シリーズの過去記事で紹介したように、/skill-creatorを呼び出して、Claude Codeに「次のように開発を進めるスキルが欲しい」と伝えます。

/skill-creator 以下の開発のフローを pr-based-dev スキルとして作成

- ユーザーは、スキルと共に実装したい内容をエージェントに伝達
- 既存コードを調査し、内容を精査。問題なければ以下ステップを経て実装を行う
  - 現在のブランチから新しくブランチを作成
    - ブランチ名例: `topic/{title-of-impl}`
  - そのブランチをcheckoutして実際の開発を実施
  - 完了したらpush、元のbranchに対してPRを作成
  - サブエージェントを使いレビューを実施
  - CIが設定されていたらCIがグリーンになるまで修正を継続
- 完了したら実装内容とPRのURLをユーザーに報告

上記はプロンプト例として簡潔にまとめていますが、Claude Codeに相談しながら進めるのでももちろん問題ありません。

そうするとスキルを作成してくれるので、以降は、

/pr-based-dev トップページのボディエリアにタブUIを作って

などと伝えれば、PRを作ってひととおり実装を完了するまでやってくれます。基本的にはこれだけなのでシンプルです。

あとは実際に使ってみると、いろいろと思っていた挙動と違うような部分がでてくると思うので、それを自分で使いつつ、調整していくという流れがよいかと思います。

ひとまず基本としてはこれだけです。このようなステップに分かれた一連の処理を行わせるスキルを作り、後はまるっとClaude Codeに一連の流れを任せましょうというのが、このワークフロー的なスキルの目指すところです。

ワークフロースキルを便利に使うためのTips

ここからは、ワークフロースキルをより便利に使うためのTipsを紹介します。

CLI風のオプション引数で挙動を変更

まず1つ目は、引数によるオプション指定です。前回、スキルをCLIのようなものと考えるという話を書きましたが、実際にCLIのオプション引数のような仕組みを用意し、スキルの挙動を変更するようにするのがオススメです。公式の解説としては以下をご参照ください。

• スキルで Claude を拡張する: スキルに引数を渡す

この/pr-based-devであれば、たとえば次のようなオプションが考えられます。

• -nor --no-review: レビューをスキップ
• -noci --no-ci: CI確認をスキップ
• -a --auto: 完了したらPRをマージ

使い方は次のようになります。

/pr-based-dev -nor -a タブを実装して

もしくは以下でも同様。短いと忘れるので、長いのと両方用意しておきます。

/pr-based-dev --no-review --auto タブを実装して

用意しておくといっても、特別な何かが必要なわけではありません。実際には、-norのような文字列がプロンプトにあれば、それをClaude Codeが引数として認識するだけの単純な仕組みです。それでもCLIに近い感覚でスキルを呼ぶことができ、スキルを入力するときにヒントも表示されて便利です。

mainブランチのような安定ブランチではなく、developのような中継用のベースブランチで作業しており、確認もレビューも後回しにしてガンガン修正を積み上げていくというケースがあるかもしれません。そういった場面ではこのようなオプションを用意し、レビューもCIもスキップして終わったら即時マージさせるようにすると便利です。

レビュワーの変更スキル

もう1つ、オプション引数のTipsとして、筆者が便利に使っているものを紹介します。

筆者の場合、こういった開発を一貫して行うワークフロー系のスキルには、たいていサブエージェントを使ったレビューを組み込んでいます。問題があれば調整させる形で、かつ、このレビュワーをオプションで切り替えられるようにしています。

具体的には次の引数を用意して使っています。

• -op --opus： Opusモデルでレビュー
• -so --sonnet： Sonnetモデルでレビュー

Claude CodeにはOpusやSonnetなど、複数のモデルが用意されています。Opusは大きめのモデルで、設計判断のように深く考えてほしい場面に向きますが、その分トークン単価は高めです。Sonnetはバランス型で、軽めの修正レビューや、機械的な確認が主目的の場面に使うと相性がよいです。

レビュー対象の規模や、どこまで深く読み込んでほしいかに応じて、このオプションを切り替えれば、料金と精度のバランスを取りやすくなります。

ユーティリティスキルなどとの連携

このようなワークフロー的なスキルですが、自分でユーティリティスキルやサブエージェントをすでに持っていれば、スキル作成を頼んだときに勝手に拾い、スキルを構成してくれます。

たとえば前述のPR開発ワークフロースキルですが、筆者が手元で試しに作ったところ、以下がスキル内で自動で組み込まれました。

• /commits: 9回目で解説したコミットスキル
• /light-review: 2サブエージェントでライトにレビューさせるスキル
• /deep-review: 5エージェントで突っ込んでレビューさせるスキル
• /watch-ci: CIが終わるのを待って継続的に修正するスキル
• code-reviewerサブエージェント: コードレビュー用サブエージェント

おそらく、前項で説明した-a --autoでPRをマージすることまで求めると、以下も組み込まれるでしょう。

• /pr-complete: PRをマージして実装を完了するスキル

これにより、前回書いたようなnode_modulesはコミットしないで.gitignoreに登録する（/commits）とか、PRをマージしたらCIが緑になるのをチェックする（/watch-ci）とか、マージ完了したらブランチを削除する（/pr-complete）など、マイクロな開発Tipsもワークフローの中でカバーされるのです。

こういう流れを見てみると、自分でスキルを組み立てて、それをライブラリのように持っておくことがいかに重要かがわかるのではないでしょうか。カードゲームで言えば、これらスキルの集まりはデッキのようなもので、整備を継続していくことは、自分のデッキを組み立てていくことに近いかもしれません。

プロジェクト依存のワークフロー

ここまでで紹介しているスキルやサブエージェントは、ユーザーの全体的な設定を前提として話を進めてきました。ですが、ユーザーのホームディレクトリに.claude/ディレクトリを作るのと同様、プロジェクトのディレクトリに.claude/を作り、その中にスキルやサブエージェントのテキストファイルを置いておくこともできます。

その場合、たとえば~/my-project/で作業していたとすれば、~/my-project/.claude/配下に置いたスキルやサブエージェントも利用可能で、これは~/my-project/で作業しているときにだけ有効になります。

この仕組みを利用することで、プロジェクト内だけで便利に利用できるスキルを、チームで共有することが可能です。このローカルスコープなスキルの利用方法はさまざまですが、プロジェクト固有の、覚えておかなければならない前提が多いような一連の作業をまとめるのにも役立ちます。

たとえば筆者の担当しているプロジェクトですと、Webアプリのフロント部分をまるっと一式ビルドした一連のファイルを、クライアントのリポジトリの、特定の命名規則のブランチにpushして納品するというルールがあったりします。その納品の前には手元でバージョンを上げ、そして決まったブランチにもpushしてタグを打って……みたいな流れがあるのですが、そういったフローもこのスキルで作っておくことで、簡単に呼び出すことができます。

特に便利なのはdescriptionフィールドの活用です。この連載でも紹介したように、スキルには概要を示すdescriptionを設定できます。そこに「納品時に使用する」などと書いておけば、Claude Codeに「納品したい」というだけで一連の作業を行ってくれます。スキルを整備していくことで、ただ雑にやりたいことを投げるだけで、整備されたフローを経て処理してくれる状態を作れるのです。

プロジェクト固有のワークフロースキルの例

そういったプロジェクト固有のワークフロースキルですが、たとえばサイトの性質によって、次のような処理をスキルにしておくと便利かもしれません。

• ECサイト
  • /add-product-item: 商品情報を追加。データベースや商品詳細ページ、画像ギャラリーを更新してPRを作成
• 記事のあるサイト
  • /add-article: 新しく記事を作成、記事のカテゴライズにより、フォーマットや必要な情報を対話形式で答えていくことで、ドラフトを作り、PRを作成
• ライブラリなどOSSのリポジトリ
  • /version-increment: バージョンアップの準備。差分ログの自動作成、タグやリリースの作成、npmへのパブリッシュを対話形式で案内

このようなワークフローの中には、機械的な処理が含まれるため、それらはちょっとしたスクリプトや、npmコマンドとして切り出しておくと便利に使えます。

例に挙げた/version-incrementであれば、バージョン番号の1.2.33のようなsemverに基づくバージョンとしては、どこを上げるべきかとか、具体的な差分ログのテキスト作成はAIの力を使うが、それらを更新するドキュメンテーションの仕組みや、タグ付け、リリース作成のような処理は、スクリプトなどを書いてもらって自動化するという具合です。

まぁ、こちらから細かく指示しなくても、Claude Codeがよしなにスクリプトを用意してくれることがほとんどです。考え方としては、ユーティリティスキルが個々の操作を担うように、ワークフロースキルは別の道具を組み合わせて大きなワークフローを組み立てる、と捉えるとよいのではないかと思います。

今回は2つ目の分類として「ワークフロー」のスキルを紹介しました。なお、このワークフロー型スキルを実用的に運用する上では、git worktreeというGitの機能と、pnpmというnpmの代替パッケージマネージャの利用をセットで使うことをオススメします。これについては下記の記事で詳細を解説していますので、こちらもご覧ください。

• git worktreeとpnpmで作る並列開発環境 | AI時代におさえておきたい開発セットアップ

次回は3つ目の「ナレッジ」のスキルについて解説します。