元記事: 開発自動化の基盤を設計する software-factory スキルの使い方（cccskills）
スキルのページ: software-factory
この記事の結論
software-factoryは、チケットからマージまでをエージェントに任せる仕組みを、共通の用語で設計するためのスキルです。
入れておくと、開発リーダーや個人開発者が、決まった用語と問いに沿って設計を詰められるようになります。
この記事では、そろえられる用語とサービス構成、インストール方法、依頼文の例、使う前に知っておきたい注意点を順に紹介します。
software-factoryを使うと、開発自動化の設計を決まった用語と決まった問いで詰められます。
ここでいう「ソフトウェアファクトリー」は、チケットやPR、定期実行をきっかけにエージェントが動き、マージされたコードに仕上げる仕組みのことです。
たとえば次のように頼みます。
software-factoryを使って、未分類のチケットを振り分けるソフトウェアファクトリーを設計してください。
チケットはGitHub Issuesで管理しています。
エージェントは仕組みの全体像より先に、解きたい問題から話を始めます。
未分類のチケットのようなよくある課題なら、付属のEXAMPLE-TASKS.mdにある対応するタスクの例が参照先です。
設計は「サービス」と「タスク」の2つに分かれます。
サービス側では、チケット管理やGitホストなどの枠（スロット）ごとに製品を決めます。
タスク側で答えるのは、起動条件や人の確認箇所など5つの問いです。
**すべての枠に製品が入り、すべての問いに答えが出たら設計は完成です。
**
会話の途中で「ジョブ」や「ワークフロー」と言うと、エージェントは正式な用語の「タスク」を示します。
そのため、チーム内で言葉がぶれないまま議論を進められます。
このスキルの中心は、設計で使う9つの用語です。
エージェントはこの用語だけを使い、避けるべき言い方が出てきたら言い換えます。
| 用語 | 意味 |
|---|---|
| Task（タスク） | 一度定義して何度も実行する作業の種類。レビュー、調査、実装など |
| Trigger（トリガー） | ランを始めるきっかけ。チケット管理やGitホストの変更、時刻、別のラン |
| Run（ラン） | 1つのタスクを1台のランナーで実行する1回分 |
| Runner（ランナー） | ランが動く使い捨ての環境。終わると何も残らない |
| Ticket tracker（チケット管理） | チケットの置き場所で、人とエージェントの窓口 |
| Ticket source（チケットの発生源） | フィードバックボタン、監視、エラートラッカー、受信箱など |
| Git host（Gitホスト） | ブランチ、PR、レビューの置き場所 |
| Orchestrator（オーケストレーター） | トリガーを受けてランを起動し、待機中・実行中・完了を記録する |
| Observability platform（可観測性基盤） | ランのログや状態を人が確かめる場所。なくてもよい |
設計の前提になる考え方も決まっています。
1つは、ランが人の返答を待たずにいったん終わることです。
人がチケットやPRを変更したときに、新しいランが始まります。
もう1つは、ランナーに前回の記憶が残らないことです。
そのため過去の経緯は、チケット管理、Gitホスト、オーケストレーターにだけ残ります。
トリガーを増やすほど自動化は加速しますが、歯止めがないと質の低い変更が量産されます。
そこで組み込むのが、次の3つのブレーキです。
| ブレーキ | 内容 |
|---|---|
| 自動チェック | 型、リント、テストなど、すべてのランが通る決まった関門 |
| 自動レビュー | 別のランが差分を先入観なく読み、規約やチケットと照らし合わせる |
| 人のレビュー | マージ前に人がPRを読む。見つけた問題は自動チェックや自動レビューに反映する |
自動のトリガーは1つずつ足し、最初は絞って動かします。
バグ報告10件に1件だけ処理する、定期実行は1日1回にする、といった具合です。
あわせて、最初はすべてのPRを人が確認します。
ランの繰り返しにも、数回で人に戻す上限を設けておきます。
各サービスは、製品を当てはめる枠として扱います。
1つの製品で複数の枠を埋めてもかまいません。
スキルに載っている構成例は次の3つです。
| サービス | すべてGitHub | チケットはLinear | 自前のトラッカー |
|---|---|---|---|
| チケット管理 | GitHub Issues | Linear | 自前のアプリ |
| チケットの発生源 | フィードバックボタン | フィードバックボタン、監視 | フィードバックボタン、監視 |
| Gitホスト | GitHub | GitHub | GitHub |
| オーケストレーター | GitHub Actions | 自前のサーバーとデータベース | 自前のアプリ |
| ランナー | Actionsのランナー | Actions、E2B、Daytona、VPS | 自前のアプリかサンドボックス |
| 可観測性基盤 | なし（Actionsの実行画面で足りる） | LLMのトレースツール | 自前のアプリ |
基本方針は「サービスは買い、タスクは作る」です。
設計の工夫はタスクに込め、サービスは汎用品で済ませます。
チケット管理については既製品が勧められています。
安定していて、利用者がすでに使い方を知っており、外部の人も招きやすいからです。
各タスクについて、次の5つの問いに答えます。
チケットの発生源に対しては、同じチケットを二重に起票しないための仕組みを問います。
ターミナルで次のコマンドを実行してください。
途中で、Claude CodeやCodexなど入れる先を選べます。
npx skills add https://github.com/mattpocock/skills --skill software-factory
エージェントにインストールを任せる場合は、次の文面をそのまま送ってください。
次の Agent Skill をインストールしてください。
https://github.com/mattpocock/skills/tree/main/skills/in-progress/software-factory
まず SKILL.md と付属ファイルの中身を確認し、不審な処理（外部への送信、認証情報の読み取りなど）がないことを確かめてから、Claude Code なら ~/.claude/skills/software-factory/、Codex なら ~/.agents/skills/software-factory/ に配置してください。
置き場所は、すべてのプロジェクトで使うかどうかで選びます。
| 入れる先 | すべてのプロジェクトで使う | 特定のプロジェクトだけで使う |
|---|---|---|
| Claude Code | ~/.claude/skills/ | プロジェクトの.claude/skills/ |
| Codex | ~/.agents/skills/ | プロジェクトの.agents/skills/ |
このスキルは、エージェントが自分の判断で読み込まない設定になっています。
使うときは依頼文でスキル名を指定するか、Claude Codeなら/software-factoryで呼び出してください。
1つ目は、何から自動化するか決まっていないときの相談です。
software-factoryを使って、レビュー待ちのPRがたまっている問題を解決するファクトリーを設計してください。
まずは人のレビューを残したまま始めたいです。
エージェントはEXAMPLE-TASKS.mdから合うタスクを選び、サービスの枠と各タスクの5つの問いを順に埋めていきます。
最初のトリガーは1つに絞り、どこで人が確認するかも答えに含めます。
2つ目は、製品選びの相談です。
software-factoryを使って、ランナーに何を使うか決めたいです。
GitHub Actionsと外部のサンドボックスを比べてください。
エージェントは付属のRUNNERS.mdを読んで全体像をつかんだうえで、現在の選択肢を調べ直します。
調査資料では選択肢が種類ごとに分けられ、その枠を決めるための問いが並んでいます。
返ってくるのは、その問いに沿った比較です。
3つ目は、1つのタスクを詰める依頼です。
software-factoryを使って、PRの自動レビューのタスクについて、起動条件、読み書きするサービス、次に起動するもの、人の確認箇所、重複実行の防ぎ方を整理してください。
5つの問いに1つずつ答えた整理が返ってきます。
答えが出ない項目は、そのまま設計の未決事項として残ります。
software-factoryは設計を整理するためのスキルです。
含まれるファイルはSKILL.mdと5つのMarkdown資料だけで、自動化を動かすスクリプトは入っていません。
GitHub Actionsの設定やランナーの構築は、設計が固まったあとに別途進めることになります。
付属の調査資料にある製品の情報は、全体像をつかむための手がかりです。
SKILL.mdには、現在の選択肢はエージェントが自分で調べ直すよう書かれています。
製品の機能や料金は、決める前に公式の情報で確かめてください。
スキルはリポジトリのin-progressフォルダに置かれており、ライセンスはMITです。
**入れる前と更新したときに、SKILL.mdと付属ファイルの中身を読んでおくと安心です。
**
同じmattpocock/skillsリポジトリには、設計の前後で使えるスキルもあります。
code-reviewは、規約への適合と仕様の実現を分けて変更をレビューするスキルです。
自動レビューのタスクを考えるときの参考になります。
domain-modelingは、プロジェクトの業務用語や概念の境界を整理し、用語集に記録するスキルです。
どのスキルから手をつけるか迷ったときは、ask-mattに相談できます。
ask-mattは、状況に合うスキルと順序を案内してくれます。
このスキルが扱うのは設計の用語と考え方で、構築の手順やスクリプトは含まれていません。
助けてくれるのは、どのサービスを使い、どのタスクを何がきっかけで動かすかを決めるところまでです。
できます。
構成例の1つが、チケット管理をGitHub Issues、オーケストレーターをGitHub Actions、ランナーをActionsのランナーにする形です。
この構成ではActionsの実行画面で足りるため、可観測性基盤は置いていません。
解きたい問題をそのまま伝えてください。
未分類のチケット、自動レビュー待ちのPR、誰も読まないバグ報告などがあれば、エージェントがEXAMPLE-TASKS.mdから対応するタスクの例を示します。
自動チェック、自動レビュー、人のレビューの3つのブレーキを組み込む前提です。
トリガーは1つずつ絞って足し、すべてのPRを人が確認するところから始めます。
ブレーキが信頼できると分かってから、少しずつ絞りを緩めていきます。
software-factoryは、チケットやPRからマージまでをエージェントに任せる仕組みを、共通の用語で設計するためのスキルです。
チーム内で呼び方がそろっていない開発リーダーや、構成を一から考える個人開発者に向いています。
**最初に整理するのは、解きたい問題と、それを担う1つ目のタスクの5つの問いです。
**そこから枠ごとの製品を決め、トリガーを1つずつ増やしていきます。
インストール方法と概要はcccskillsのページにまとめています。
リポジトリは https://github.com/mattpocock/skills/tree/main/skills/in-progress/software-factory です。
この記事は cccskills の読みもの「開発自動化の基盤を設計する software-factory スキルの使い方」の転載です。
スキルの詳細とインストール方法は cccskills の software-factory のページ にあります。