Claude Code向けgstack：23エージェントのワークフローが実際に行うこと

gstack Claude Codeはプロンプト集ではなく、オペレーティングシステム

理解に役立つ捉え方として、 gstack Claude Code は、Claude Codeの上に重ねられたエンジニアリング用のオペレーティングシステムです。各ツールはClaudeに役割、手順、期待される出力を与えます。これらのツールは一体となって、ソフトウェアをアイデアから本番環境へどのように進めるべきかという考え方を組み込んでいます。

汎用的なプロンプトは、たとえば次のようなものです。

Review my implementation plan.

役割に基づくワークフローでは、より焦点を絞った問いを投げかけます。

/plan-eng-review

そのスキルは、アーキテクチャ、依存関係、障害モード、テスト容易性、ロールアウトのリスク、実装の順序を検討するようClaudeに指示できます。プロダクト志向の計画スキルは、同じ計画をユーザー価値とスコープの観点から検証できます。デザイン志向のスキルは、バックエンドの境界ではなく、操作の細部に疑問を投げかけることができます。

違いは再現性にあります。チームメンバーがそれぞれ40行のレビュープロンプトを覚えたり、独自のチェックリストを作ったりする必要はありません。手順はスキルに組み込まれています。

トレードオフも同じくらい重要です。gstackは、他者が定めた手順を自分たちのリポジトリに持ち込みます。複数回のレビュー、明示的なQA、体系的なリリース作業には、それらが消費するコンテキストと時間に見合う価値があるという前提に立っています。本番環境への変更では適切なことが多い一方、誤字の修正や短い社内用スクリプトには過剰です。

23個の役割別ツールが実際にカバーする範囲

リポジトリ内の正確な構成は変わり得るため、私はチェックアウトした SKILL.md ファイルを正として扱い、スクリーンショットや公開時の説明には頼りません。アーキテクチャ上で重要なのは、責任の分担です。

gstackを「プロンプト集」と呼ぶだけでは、その価値を十分に表せないのはこのためです。計画の成果物が実装に引き継がれ、実装によって差分が生まれ、レビューとQAがその差分を検証し、リリースと文書化が結果をまとめます。

「23エージェントのワークフロー」という表現が誤解を招き得るのも、このためです。スキルを呼び出すと、実際にはClaude Codeが指示を読み込み、現在のセッションで利用可能なツールを使って、対応するワークフローを実行します。スキルが明示的に作業を委任しない限り、共通の状態を共有する23個の永続プロセスが存在するわけではありません。

計画段階の重複は意図的なもの

プロダクト、エンジニアリング、デザインのレビューには重複があります。これは意図的です。

提案された「顧客の全アクティビティをエクスポートする」機能を考えてみましょう。

• プロダクトレビューでは、ユーザーが必要としているのは完全なエクスポートなのか、条件で絞り込んだレポートなのかを問います。
• エンジニアリングレビューでは、エクスポート処理がメモリに収まるか、再試行がどのように機能するかを問います。
• デザインレビューでは、エクスポートの状態、失敗の表示、ダウンロードの操作部をどこに配置するかを問います。
• QAでは、レコードがない場合、リンクが期限切れになった場合、ジョブが中断された場合に何が起こるかを問います。

実際には、この分離によって、汎用的な実装計画の中では見えなくなる前提を発見できます。その代償は、コンテキストを繰り返し読み込むことです。計画がすでに8,000トークンある場合、複数回のレビューはコストが高くなり、指摘が重複することもあります。

レビューとQAは異なる仕事

/review は主に、差分、型、テスト、呼び出し箇所、リポジトリの規約といったコード上の根拠に基づきます。 /qa と /browse は、アプリケーションそのものから実行時の根拠を収集できます。

この分離は、gstackの特に優れた考え方のひとつです。差分は正しく見えても、描画された結果が使いものにならないことがあります。逆に、ブラウザーで正常系の確認が通っても、実装に競合状態や認可の回避が入り込んでいることがあります。

実用的な手順は、次のようになります。

/plan-eng-review
/careful
# Implement the approved plan in Claude Code
/review
/qa
/document-release
/ship

これを必須のパイプラインと考えないでください。データベースのマイグレーションでは、視覚的なデザインよりもエンジニアリングレビューとロールバック計画のほうがはるかに重要な場合があります。CSSのリグレッションでは、 /browse、デザインレビュー、QAが中心的なワークフローになるかもしれません。

盲目的に信頼せずにgstackをインストールする

一般的なユーザーレベルのインストールでは、Claude Codeのスキルディレクトリ配下にリポジトリを配置し、そのセットアップスクリプトを実行します。

git clone https://github.com/garrytan/gstack.git \
  ~/.claude/skills/gstack

cd ~/.claude/skills/gstack
./setup

セットアップ後、新しいコマンドがすぐに認識されない場合は、Claude Codeを再起動してください。その後、公開されている数がチェックアウトした内容とまだ一致していると決めつけず、インストールされたスキルを確認します。

find ~/.claude/skills/gstack \
  -name SKILL.md \
  -print |
  sort

find ~/.claude/skills/gstack \
  -name SKILL.md |
  wc -l

よくある落とし穴は、リポジトリが人気だからという理由だけで、何を変更するのかを読まずにインストールスクリプトを実行することです。gstackには、単なる静的なMarkdownではなく、実行可能なワークフローの仕組みが含まれています。セットアップを実行する前に、内容を確認してください。

cd ~/.claude/skills/gstack
git status --short
git log -1 --oneline
sed -n '1,240p' setup

チームに展開する場合は、リポジトリの最新状態を暗黙に追い続けるのではなく、レビュー済みのコミットに固定してください。

git clone https://github.com/garrytan/gstack.git vendor/gstack
cd vendor/gstack
git checkout <reviewed-commit-sha>
./setup

正確なインストール手順や依存関係は、プロジェクトの発展に伴って変わる可能性があります。そのため、この記事を含む古い記事からコピーしたコマンドよりも、リポジトリの現在のREADMEとセットアップスクリプトを優先してください。

ワークフローをClaude Codeの権限設定で制御する

一部のgstackツールは、ファイルの確認、テストの実行、ブラウザーの操作、Gitとのやり取りのために広いアクセス権を必要とします。だからといって、すべてのツールに無制限のシェル権限やリリース権限を与えるべきということではありません。

プロジェクトレベルの .claude/settings.json で、慎重な基本設定を定めることができます。

{
  "permissions": {
    "allow": [
      "Bash(git status:*)",
      "Bash(git diff:*)",
      "Bash(npm test:*)",
      "Bash(npm run lint:*)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Bash(git push:*)",
      "Bash(git push --force:*)"
    ]
  }
}

これはポリシーの例として扱い、どこでもそのまま使えるファイルとは考えないでください。コマンドは、使用するパッケージマネージャー、テストランナー、Claude Codeのバージョンに合わせて調整してください。

明示的に拒否する対象を git push にすることは、評価中に特に有用です。 /ship は引き続きリリース準備の状況を確認できますが、最終的にネットワークを介した変更を行う権限は人間が保持します。チームがワークフローを理解した後で、厳密に範囲を限定したプッシュ権限を認めるべきか判断できます。

また、ブラウザーを使うスキルは、ステージング環境やテストデータを投入したローカル環境で試してください。本番セッションでのブラウザー自動化は、ワークフローが破壊的な操作部をクリックすると、実際のレコードを変更する可能性があります。

仕組み全体を採用する前に、一部から導入する

私は、初日から23個すべてのツールをチームに導入することは勧めません。既存のプロセスで最も多くの情報が失われている箇所から始めてください。

妥当な評価マトリックスは、次のとおりです。

選んだツールを実際の変更で何度か使い、次の点を記録してください。

• どの指摘がコードやスコープの変更につながったか。
• どの指摘が重複していたか。
• どれだけのコンテキストを繰り返し伝える必要があったか。
• 生成された成果物は実装との整合性を保っていたか。
• どのコマンドが、チームとしてCIでは許可しない権限を必要としたか。
• 開発者は、各役割をいつ呼び出すべきか理解していたか。

コンテキストのオーバーヘッドは、机上の問題ではありません。各役割には、リポジトリの状態、要件、過去の決定が必要です。セッションを分けると判断の理由が失われる可能性があり、長い単一セッションでは古い前提が蓄積する可能性があります。私は承認済みの計画を、たとえば次のようなリポジトリ内のファイルに保存します。 docs/plans/export-jobs.md。そのうえで、各ワークフローにその成果物を使うよう指示します。会話のコンテキストがプロジェクトの記憶として機能することを期待するより、永続的に保存されたファイルのほうが信頼できます。

文書化された動作と宣伝上の主張

根拠を示せる主張は、gstackが23個の役割別Claude Codeツールと、ソフトウェアのライフサイクル全体にわたる、明確な方針を持つワークフローを提供するということです。この動作は、インストールされたスキルを読み、テスト用リポジトリで実行することで検証できます。

生産量を劇的に増やす、エンジニアリングチームを置き換える、何週間もの作業を数時間に縮めるといった、より広範な主張は、自分たちの環境で実証されるまでは宣伝文句です。結果は、リポジトリの品質、テストカバレッジ、タスクの曖昧さ、モデルの選択、権限、作業を監督する開発者に左右されます。

現在のモデルラインアップも、これらの制約を解消するわけではありません。Sonnet 4.6は継続的なコーディング作業の実用的な標準選択肢になり得る一方、Haiku 4.5は軽めの分類や文書化のタスクに適している場合があります。Fable 5の1Mコンテキストは非常に大量の資料を扱う際に役立ち、gpt-5.6-solは対応環境でエンジニアリング向けの別の選択肢を提供します。どのモデルも、役割を指定するプロンプトを、検証済みのプロダクト知識や本番環境での根拠に変えるものではありません。

実践上のポイント

• gstackは、Claude Codeのスキルを通じて実装された、明確な方針を持つ開発プロセスとして捉えてください。
• 「23エージェント」は、自動的に連携する永続的なワーカーではなく、役割別のツールとして理解してください。
• リポジトリからインストールし、確認します setup。チームで使用する際は、レビュー済みのコミットに固定してください。
• 既知のデリバリー上の問題に対処するワークフローを、まず二つか三つ導入してください。
• 承認済みの計画や決定事項をファイルに保存し、各役割が永続的なコンテキストを共有できるようにしてください。
• コードレビューと実行時のQAを分けてください。それぞれ異なる種類の不具合を検出します。
• 評価中は、シークレット、本番環境のセッション、Gitのプッシュ、デプロイコマンドを制限してください。
• 実行したコマンドの数ではなく、有用な発見と未然に防いだ不具合を測定してください。
• プロセス全体の運用コストが、それによって防げる不具合のコストを下回る場合にのみ、運用システム全体を導入してください。