パイソンエンジニア部
GitHub のスター数だけを見ても決め手にならない、というのが正直なところではないでしょうか。どれも「Research → Plan → Execute → Review → Ship」という同じ道を歩きます。なのにたくさんの種類がある。その差はどこにあって、自分にはどれが合うのか。この記事はその疑問に答えることを目標にします。
なお Skills の基礎は処方箋 #04、Subagents は処方箋 #05、Slash Commands は処方箋 #06 で、C/A/S（Command/Agent/Skill）の連携アーキテクチャは処方箋 #07 で扱いました。ここでは再説明しないので、まだ読んでいない方はそちらを先に読んでもらえると内容がつながります。
TL;DR
- 全 12 種は「Research → Plan → Execute → Review → Ship」という同じ地図を共有する。違いは「スキルで走るか / コマンドで走るか / エージェントで走るか」の実装スタイルだけ
- スキル型（Superpowers・gstack・BMAD など）: テンプレートで作業手順を固める。個人開発・小チーム向き
- コマンド型（Spec Kit・GSD・HumanLayer など）: 明示的なコマンドでフローを刻む。仕様書ファーストのチーム向き
- エージェント型（Compound・oh-my-claudecode）: 自律チームに委ねて並列処理。大規模タスク向き
- 「まず試したい」なら Superpowers（シンプル）か agent-skills（最軽量）から始めるのが無難
- 数字（skills/commands/agents 数）は claude-code-best-practice の commit
1d236d3（2026-05-23）時点
全 12 種が共有する 1 本の地図
README には次の一文があります。
All major workflows converge on the same architectural pattern: Research → Plan → Execute → Review → Ship
12 種のワークフローはすべて、この 5 段階のループを繰り返しています。
flowchart TD R["Research<br/>要件・文脈収集"] --> P["Plan<br/>設計・タスク分解"] P --> E["Execute<br/>実装・生成"] E --> V["Review<br/>レビュー・検証"] V --> S["Ship<br/>リリース・完了"] V -- "要修正" --> E
違いは「このフローをどのプリミティブで実装するか」です。Skills（テンプレート）で固めるか、Slash Commands（明示的な命令）で刻むか、Agents（自律チーム）に委ねるか。この3軸で分けると選びやすくなります。
3 タイプに分ける
スキル型: テンプレートで手順を固める
Skills（処方箋 #04 を参照）を中心に構成されたワークフローです。各 SKILL.md に「このフェーズでこう動く」という手順が書いてあり、それを呼び出すだけで統一した作業が走ります。段取りを自分で決めたくない人・繰り返しタスクを標準化したい人に向いています。
Superpowers（スター 200k、skills 14、commands 0、agents 0）
github.com/obra/superpowers — git worktree（ブランチを独立したディレクトリに展開して並列作業できる仕組み）を前提としたフローが特徴です。ブレインストーミング → 計画書作成 → サブエージェント駆動開発 → TDD（テスト駆動開発） → コードレビュー → 検証 → ブランチ完了の流れを 14 個のスキルで固めています。スター数が最多で、シンプルな構成のため入門向きです。
gstack（スター 100k、skills 48、commands 0、agents 0）
github.com/garrytan/gstack — /plan-ceo-review・/plan-eng-review・/plan-design-review の 3 種のレビュースキルが充実しており、設計の多角的なチェックを重視するスタイルです。/office-hours で始まり /retro で締めるという、スクラム的なリズムを持ちます。
Matt Pocock Skills（スター 97k、skills 28、commands 0、agents 0）
github.com/mattpocock/skills — /grill-with-docs（ドキュメントを深掘りして理解する）から始まり /to-prd・/to-issues でタスクに落とすフローが特徴的です。TypeScript エコシステム向けに洗練されており、ドキュメントから仕様を引き出す作業が多い人に向いています。
BMAD-METHOD（スター 48k、skills 42、commands 0、agents 0）
github.com/bmad-code-org/BMAD-METHOD — ビジネス要件から PRD（要件定義書）・アーキテクチャ・エピック・スプリント計画までをスキルで連動させます。プロダクトマネジメントの視点が組み込まれており、機能単位でなく「ストーリー」でタスクを管理したい場合に使いやすいです。
コマンド型: 明示的な命令でフローを刻む
Slash Commands（処方箋 #06 を参照）を中心に構成されたワークフローです。「今どのフェーズか」をコマンド名で明示するため、チームで作業を引き継ぐ場面や、人間が承認ポイントを設けたい場面に向いています。
Spec Kit（スター 104k、skills 0、commands 9、agents 0）
github.com/github/spec-kit — /speckit.constitution（ルール定義）→ /speckit.specify（仕様記述）→ /speckit.clarify → /speckit.plan → /speckit.tasks → /speckit.implement の 6 ステップが名前で自明です。仕様書を書くことを最初のゴールに置いており、実装は最後のステップです。「まず仕様書」を徹底したいチームに合います。
Everything Claude Code（ECC）（スター 188k、skills 230、commands 143、agents 48）
github.com/affaan-m/everything-claude-code — 12 種のなかで最大のライブラリです。230 スキル + 143 コマンド + 48 エージェントを持ち、Claude Code に関するほぼあらゆる作業をカバーしています。/ecc:plan から始まり TDD・コードレビュー・セキュリティスキャン・E2E（エンドツーエンド）テストを経てマージするフローです。網羅性を重視する場合の選択肢ですが、規模が大きいためメンテナンスコストも相応です。
Get Shit Done（GSD）（スター 63k、skills 0、commands 67、agents 33）
github.com/gsd-build/get-shit-done — 名前の通り「まず動かす」哲学です。/gsd-new-project → /gsd-discuss-phase → /gsd-plan-phase → /gsd-execute-phase → /gsd-verify-work → /gsd-ship → /gsd-complete-milestone のフローが直線的でわかりやすいです。67 コマンドと 33 エージェントを持つため、コマンド型とエージェント型の中間に位置します。
OpenSpec（スター 50k、skills 0、commands 11、agents 0）
github.com/Fission-AI/OpenSpec — OpenAPI 仕様書の管理に特化しています。/opsx:propose（仕様提案）→ /opsx:apply（適用）→ /opsx:archive（アーカイブ）という 3 ステップのみで、スコープが明確です。API 仕様書を軸に開発を進めるチーム向けです。
HumanLayer（スター 11k、skills 0、commands 27、agents 6）
github.com/humanlayer/humanlayer — /validate_plan（計画を人間が承認）というコマンドがフローの中央にあるのが特徴です。Claude が計画を立て → 人間がそれをレビューして OK を出す → 実装する、という流れです。「Claude に自走させたいが、重要な決定には人間の目を入れたい」というニーズに応えます。
エージェント型: 自律チームに委ねる
Subagents（処方箋 #05・処方箋 #13 を参照）を中心に組まれたワークフローです。複数のエージェントが並列に動き、リード役がタスクを振り分けます。大規模なタスクや、段階ごとに専門化した処理が必要な場合に力を発揮します。
oh-my-claudecode（スター 34k、skills 39、commands 0、agents 19）
github.com/Yeachan-Heo/oh-my-claudecode — /deep-interview（要件を深掘りするインタビュー）で始まり、/team でエージェントチームを編成したあと、team-plan → team-prd → team-exec → team-verify → team-fix → /ralph（ループ自走）→ merge というフローです。人間との対話から始まり、チームが自律的に走っていくという独自の設計が特徴です。
Compound Engineering（スター 17k、skills 38、commands 4、agents 49）
github.com/EveryInc/compound-engineering-plugin — 49 エージェントを持ち、12 種のなかで最大規模のエージェント群です。/ce-compound という コマンドが蓄積したプロンプトと文脈を再利用（複利的に組み合わせる）するのが設計の核心で、繰り返し実行するたびに効率が上がる仕組みを目指しています。
agent-skills（スター 27k、skills 21、commands 7、agents 3）
github.com/addyosmani/agent-skills — /spec → /plan → /build → /test → /review → /ship の 6 ステップで最もシンプルです。スキル、コマンド、エージェントをバランスよく少数だけ持ち、「軽量に使いたい」ニーズに応えます。スター数のわりに構成が小さく、カスタマイズしやすいです。
12 種 比較マトリクス
stars / skills / commands / agents の 4 軸を横並びにします（数値は commit 1d236d3 時点の claude-code-best-practice の集計値）。
| ワークフロー | 略称 | スター | Skills | Commands | Agents | タイプ |
|---|---|---|---|---|---|---|
| Superpowers | SP | 200k | 14 | 0 | 0 | スキル型 |
| Everything CC | ECC | 188k | 230 | 143 | 48 | 混合 |
| Spec Kit | SK | 104k | 0 | 9 | 0 | コマンド型 |
| gstack | GS | 100k | 48 | 0 | 0 | スキル型 |
| Matt Pocock | MP | 97k | 28 | 0 | 0 | スキル型 |
| GSD | GSD | 63k | 0 | 67 | 33 | 混合 |
| OpenSpec | OS | 50k | 0 | 11 | 0 | コマンド型 |
| BMAD | BMAD | 48k | 42 | 0 | 0 | スキル型 |
| oh-my-claudecode | OMC | 34k | 39 | 0 | 19 | エージェント型 |
| agent-skills | AS | 27k | 21 | 7 | 3 | 軽量混合 |
| Compound Eng | CE | 17k | 38 | 4 | 49 | エージェント型 |
| HumanLayer | HL | 11k | 0 | 27 | 6 | コマンド型 |
棒グラフの凡例: 薄い青 = Skills / 濃い灰 = Commands / オレンジ = Agents
xychart-beta title "12 ワークフロー比較 (skills / commands / agents)" x-axis ["SP", "ECC", "SK", "GS", "MP", "GSD", "OS", "BMAD", "OMC", "AS", "CE", "HL"] y-axis "数量" 0 --> 230 bar [14, 230, 0, 48, 28, 0, 0, 42, 39, 21, 38, 0] bar [0, 143, 9, 0, 0, 67, 11, 0, 0, 7, 4, 27] bar [0, 48, 0, 0, 0, 33, 0, 0, 19, 3, 49, 6]
あなたはどのタイプか
次のフローで大まかな候補を絞れます。
flowchart TD S([ワークフローを選ぶ]) --> Q1{人間の開発メンバーは何人？} Q1 -- 1〜2人 --> Q2{まず動かしたい？} Q2 -- Yes --> A1["Superpowers<br/>agent-skills"] Q2 -- No → 仕様書ファースト --> A2["Spec Kit"] Q1 -- 3人以上 --> Q3{人間承認ゲートが必要？} Q3 -- Yes --> A3["HumanLayer"] Q3 -- No --> Q4{大量の並列タスク？} Q4 -- Yes --> A4["Compound Eng<br/>oh-my-claudecode"] Q4 -- No → スプリント管理がある --> A5["BMAD<br/>gstack"] Q4 -- No → コマンドで明示したい --> A6["GSD<br/>ECC"]「まず動かしてから判断したい」という場合は Superpowers が最初の選択肢になることが多いです。スター最多で構成がシンプルなため、Claude Code の基本を学びながら使えます。
実際に試すとしたら
全部試す必要はありません。次の 3 つを状況に応じて選んでみてください。
個人プロジェクト・小規模チームなら Superpowers
git worktree（ブランチを複数ディレクトリに展開できる git の機能）を使った並列開発が学べます。14 個のスキルだけなので把握しやすく、最初の「Claude Code でワークフローを使う」体験に向いています。
軽量に始めるなら agent-skills
/spec → /plan → /build → /test → /review → /ship の 6 コマンドだけです。Addy Osmani（Chrome チームのエンジニア）が個人プロジェクトで使いながら整備しているリポジトリで、シンプルさを保ちながら実用的です。
チーム開発で仕様書から始めるなら Spec Kit
GitHub（Microsoft 傘下）のチームが公開しているリポジトリです。仕様書を書く工程を 6 コマンドで構造化しているため、「実装前に要件を固める文化」を作りたいチームに向いています。
今週やる 1 つ
自分が最も近いと感じるワークフローを 1 つ選び、README を読んでから最初のコマンドを実行してみてください。
# 例: Superpowers を試す場合 git clone https://github.com/obra/superpowers # README に従ってセットアップし、スキルを .claude/skills/ にコピー # 例: agent-skills を試す場合 git clone https://github.com/addyosmani/agent-skills # .claude/agents/ と .claude/skills/ にファイルをコピー # プロジェクトで /spec を実行
最初のコマンドを 1 回叩いてみることが、「自分に合うか」を判断する最短ルートです。
まとめ
12 種は多く見えますが、全部が同じ 5 段階フロー（Research → Plan → Execute → Review → Ship）の上に乗っています。選ぶポイントは「スキル・コマンド・エージェントのどれを主軸にするか」と「チームの規模と人間承認の必要性」の 2 軸に絞られます。
- 個人・小チーム・まず試したい: Superpowers、agent-skills
- 仕様書ファースト・チーム開発: Spec Kit
- スプリント管理・プロダクト開発: BMAD、gstack
- 人間承認ゲートが必要: HumanLayer
- 大規模並列・自律エージェント: Compound Engineering、oh-my-claudecode
- 網羅性を求めるなら: Everything Claude Code（ただしメンテナンスコストが高い）
自分に合うワークフローは、数週間使ってみないとわかりません。まず 1 つ選んで動かしてみることをお勧めします。
