gstack:AIソフトウェアエンジニアリングスタック

エージェントスキルで作られたソフトウェアファクトリー

目次

AIコーディングエージェントは、すでに関数の作成、リポジトリの修正、テストの実行、プルリクエストの作成が可能です。より難しい問題は、コードが書かれる前、中、後のすべての段階で、エージェントが再現可能なエンジニアリングプロセスに従うようにすることです。

Garry Tanのプロジェクトであるgstackは、当初Claude Codeを軸に構築されましたが、異なるアプローチを採用しています。コーディングエージェントを別のプラットフォームで置き換えるのではなく、すでに使用しているエージェントに、専門的なスキル、ブラウザツール、レビュー、セーフティコントロール、リリースプロセスをラップ(包み込む)します。プロジェクトは、その結果を仮想エンジニアリングチームと説明しています。23名のスペシャリストと8つのパワーツール、すべてがスラッシュコマンド、すべてがMarkdown、MITライセンスで公開されています。

gstack: a virtual engineering team of agent skills layered around a coding agent

比較対象は、gstackのどの部分が必要かによって異なります。Superpowersのようなスキルコレクション、OpenSpecやGitHub Spec Kitのような仕様システム、BMADのようなメソッドロジー、Rufloのようなオーケストレーションプラットフォーム、または自分自身でメンテナンスしているエージェントスキルセットなどです。これらの中には、gstackと置き換わるのではなく組み合わせられるものもあります。これらすべての属するより広いエコシステムは、当サイトのAI開発ツールハブで整理されています。

gstackとは何か?

gstackは、AIエンジニアリングワークフローのオープンソースコレクションです。gstackの枠組みでは、ソフトウェア開発はいくつか異なる種類の推論で構成されるとされています。汎用的なコーディングプロンプトにこれらすべてをこなわせるのは不適切な抽象化です。そのため、プロジェクトは専門的なスキルを公開しています。

  • プロダクトの探索
  • プロダクトおよびCEOレビュー
  • アーキテクチャレビュー
  • 開発者体験(DX)レビュー
  • デザインレビュー
  • 実装レビュー
  • ブラウザベースのQA
  • 調査およびデバッグ
  • セキュリティ分析
  • ドキュメンテーション
  • ベンチマーキング
  • リリース準備
  • デプロイメント
  • レトロスペクティブ

プロジェクトは、これらの役割を仮想エンジニアリングチームとして提示しています。プロダクトを再考するCEO、アーキテクチャを確定するエンジニアリングマネージャー、「AIスロップ(低品質なAI生成物)」を捉えるデザイナー、本番環境のバグを見つけるレビュアー、実際のブラウザを開くQAリード、OWASPとSTRIDE監査を行うセキュリティ担当官、そしてPRを出荷するリリースエンジニアです。スキル定義を取り巻くツールチェーンはTypeScriptとBunです。セットアップスクリプト、生成されるスキルドキュメント、セッションフック、~/.gstack/ 配下での状態管理、バンドルされたブラウザ、およびスタンドアロンのCLIセットから構成されています。

gstackは基盤モデルではなく、Claude Codeの代替品でもありません。エージェントハーネスの上で実行されるプロセスレイヤーです。

flowchart TD A[LLM] --> B[Claude Code または他のサポート対象ハーネス] B --> C[gstack スキルとワークフロールール] subgraph G[gstack プロセスステージ] D1[計画] D2[アーキテクチャレビュー] D3[デザインレビュー] D4[コードレビュー] D5[ブラウザQA] D6[セキュリティ] D7[リリースとデプロイ] D8[学習とメモリ] end C --> G G --> E[Gitリポジトリ、ブラウザ、開発ツール]

gstackの位置づけを決める2つの構造的特性があります。第一に、プロジェクトはそれをツールコレクションではなくプロセスとして説明しています。スキルはスプリントが実行される順序(思考、計画、構築、レビュー、テスト、出荷、振り返り)で実行され、各スキルはその成果物を次のスキルに引き継ぎます。つまり、/office-hours は /plan-ceo-review が読むデザインドキュメントを書き、/plan-eng-review は /qa が引き継ぐテストプランを書きます。第二に、gstackはClaude Code専用ではありません。./setup はマシンにインストールされているエージェントを自動検出し、./setup --host <name> はCodex CLI、OpenCode、Cursor、Factory Droid、Kiro、Slate、OpenClaw、Hermesを対象にします。また、リポジトリ内の2KBの指示専用ダイジェストは、インストールの全く必要ないルール読み取り型エージェントに対応しています。

なぜgstackが存在するのか

空のClaude Codeセッションは非常に柔軟ですが、その柔軟性が弱点の一つでもあります。次のような機能リクエストを考えてみましょう。

アプリケーションに組織レベルのAPIトークンを追加する。

能力のあるエージェントは、すぐにリポジトリを調べ始め、認証コードの修正に取りかかるかもしれません。一方で、シニアエンジニアはまず、トークンの所有者は誰か、ユーザーが複数の組織に属せるか、トークンはどのように失効させるのか、権限は継承されるのか、既存の認証に何が起こるか、トークンは期限切れにするべきか、シークレットはどのように表示されるのか、どの監査イベントが必要なのか、などを最初に尋ねます。エージェントがこれらの質問を最終的に発見することはあるかもしれませんが、実装前にそれらが発見される保証はありません。gstackは、その規律を再利用可能なワークフローに移動させます。idea -> coding agent -> code の代わりに、変更はプロダクトレビュー、技術的計画、アーキテクチャレビュー、実装、コードレビュー、ブラウザQA、リリースという名前の付いたステージを通過します。各ステージには専用のコマンドがあり(完全なシーケンスは後述する実践的なgstackワークフローに記載)、それぞれが独立したプロセスとなります。

これにより、AIが正しくなるわけではありません。誤りの確率分布を変えるのです。エージェントは、より早く前提を疑い、証拠を調査し、いくつかの視点から自分の作業をレビューし、コードがコンパイルできたらそこで止めるのではなく、アプリケーションを検証するように押し出されます。

gstackがMarkdownスキルをプロセスに変える方法

gstackの大部分の機能は、Markdownスキル定義に由来します。エージェントスキルでは、以下のことを記述できます。

  • いつ実行すべきか
  • どのようなコンテキストを調べるべきか
  • どのような質問をするべきか
  • どのツールを使用してもよいか
  • どのコマンドを実行すべきか
  • どのような証拠を集めるべきか
  • どのチェックをパスしなければならないか
  • 結果をどのように構造化すべきか

そのようなスキルは、ドキュメント、再利用可能なプロンプト、標準手順書(SOP)、実行可能なワークフロー設定の中間に位置します。基本的な仕組みは、開発者向け Claude Skills と SKILL.mdで詳述されています。gstackはそのプリミティブの上にインフラストラクチャを追加します。生成されるスキル定義、起動および完了フック、~/.gstack/ 配下での状態管理、ブラウザ自動化、セーフティメカニズム、リポジトリ検査、オプトインによるテレメトリ、/learn によって管理されるセッション間メモリ、および別途のGBrainプロジェクトによるオプションの永続的ナレッジです。/setup-gbrain は、ローカルPGLiteデータベース、Supabaseプロジェクト、またはリモートMCPエンドポイントとして構築できます。

最も重要なgstackスキル

正確なコレクションは急速に変化しますが、いくつかのワークフローが、このシステムがどのように使用されることを意図しているかを示しています。

office-hours

/office-hours はプロジェクトや機能の初期段階に位置します。コードが書かれる前に、問題について6つの強制質問を実行し、READMEの具体例では「デイリーブリーフィングアプリ」のリクエストを「パーソナル・チーフ・オブ・スタッフAI」に再構成し、すべての下流のスキルが読むデザインドキュメントを作成します。「プロジェクト検索をより良くしたい」のような曖昧な入力に対して、出力はコードではなく要件定義です。

plan-ceo-review

/plan-ceo-review は、計画の背後にあるプロダクトレベルの前提を検証します。4つのスコープモード(Expansion、Selective Expansion、Hold Scope、Reduction)で動作し、スコープに挑戦したり、欠落した機 hộiを特定したり、不要な作業を削減したり、問題を異なるフレームワークで定義することを提案したりできます。要件が確定する前に実行される段階であり、多くのコーディングエージェントツールには存在しません。

plan-eng-review

/plan-eng-review は、視点をエンジニアリング側に向けます。アーキテクチャ、データフロー、図解、エッジケース、テストマトリクス、障害モード、セキュリティ上の懸念点などです。プロダクトレビューとは別々に保たれており、両方を1つの大きなプロンプトに統合すると、モデルがプロダクト判断と実装判断を混同するのを防ぐためです。

plan-design-review と design-review

gstackは、ビジュアルデザインとインタラクションデザインを独立した学科として扱います。/plan-design-review は、各デザイン次元を0から10で評価し、10点とはどのような状態か説明し、ギャップを埋めるために計画を編集します。「AIスロップ」の検出が名前の付いたチェック項目として含まれています。後行の /design-review は、同じ監査を実際の実装に対して実行し、原子的コミットとビフォー/アフタースクリーンショットを用いて発見された問題を修正します。Webアプリケーションでは、両方ともgstackのブラウザ自動化と組み合わされます。

review

/review は、スタッフエンジニアの視点から、リポジトリの変更に対するエンジニアリングレビューを実行します。明らかな発見事項は自動修正し、残りは承認のためにフラグを立て、過剰構築されたコードに対して助言的な簡略化レンズを維持します。正常に書かれたコードは、必ずしもマージすべきコードとは限りません。

investigate

/investigate は、プロジェクトがIron Lawと呼ぶ体系的なデバッグルールを強制します。調査なしに修正しないこと。データフローを 추적し、仮説をテストし、3回の失敗した修正試行の後で停止し、無意味な試行錯誤を続けることを防ぎます。また、/freeze を自動活性化し、調査中のモジュールへの編集をロックします。

qa と qa-only

/qa は、エージェントがブラウザを操作し、アプリケーションとインタラクションし、バグを見つけ、原子的コミットで修正し、再検証し、すべての修正に対して回帰テストを生成します。/qa-only は同じ方法論をレポートモードで実行します。多くのコーディングエージェントは、検証を「テストがパスした」で止めます。Webアプリケーションの場合、ブラウザは、統合エラー、レイアウトの問題、誤ったフロー、認証の失敗、JavaScript例外が通常可視化される場所です。

ship, land-and-deploy, canary

リリースチェーンは1つではなく、3つのスキルです。/ship はmainを同期し、テストを実行し、カバレッジを監査し、プッシュし、プルリクエストを開きます。プロジェクトにテストフレームワークがなければ、それをブートストラップします。/land-and-deploy はマージし、CIとデプロイを待ち、本番環境の健全性を検証します。/canary は、デプロイ後の監視ループを実行し、コンソールエラー、パフォーマンスの劣化、ページの失敗を監視します。

autoplan, spec, learn, retro

/autoplan は、CEO、デザイン、DX、エンジニアリングレビューのパイプラインを自動的に実行します。エンジニアリングレビューは常に最後であり、出荷ゲートが最終的に修正された計画をレビューします。承認のために提示するのは、好み(テイスト)に関する決定のみです。/spec は、曖昧な意図を5つのフェーズ(理由、スコープ、技術的(必須のコード読解を含む)、ドラフト、ファイル)を経て、正確で実行可能な仕様に変換します。登録前にアウトサイドレビューによる品質ゲートを設けます。/learn は、gstackがセッション間で学んだもの(パターン、落とし穴、好み)をレビュー、検索、剪定、エクスポート機能付きで管理します。/retro はチーム認識型の週次レトロスペクティブを生成し、/retro global はすべてのプロジェクトとAIツールにわたって実行します。

gstackにおけるブラウザ自動化

サポート対象のmacOSシステム(macOS 15以降)では、gstackはまず Aside ブラウザを駆動します。これはあなたの実際のブラウザであり、実際のログインセッションを持ち、エージェント自身がタブを開き、終了時に閉じることができます。Asideが利用できない場合、gstackは独自のChromiumベースエンジンにフォールバックします。これは ./setup によってビルドされ、コマンドごとに新しいブラウザを起動するのではなく、永続的なデーモンとして動作します。

flowchart LR A[コーディングエージェント] --> B[gstack ブラウザCLI] B --> C[ローカルブラウザサービス] C --> D[Aside またはバンドルされたChromium] D --> E[アプリケーション]

永続的なブラウザ状態により、クッキー、認証セッション、タブが操作の間で生存し、ブラウザベースのQAを実用的なものにします。/open-gstack-browser はフォールバックエンジンをヘッドフルモードで公開し、サイドバーエージェントが素早いアクション(クリック、ナビゲーション、スクリーンショット)をSonnetにルーティングし、読み取りや分析をOpusにルーティングします。エージェントがCAPTCHA、認証壁、またはMFAプロンプトに遭遇すると、$B handoff はクッキーとタブを保持したまま、同じページで可視ブラウザを開きます。ユーザーがそれを解決し、$B resume がエージェントが中断した場所から継続します。エージェントは3回連続で失敗した後、自動的にハンドオフを提案します。/pair-agent は、スコープ付きトークン、タブ分離、レート制限、タブごとのアクティビティ帰属機能により、他のエージェント(OpenClaw、Hermes、Codex、Cursor、curlを実行できるものなど)とブラウザを共有します。

永続エンジンにより、セキュリティサーフェスも増加します。認証セッションへのアクセスを持つエージェントは、意味のある権限を持つためです。gstackは、これに対して多層的なプロンプトインジェクション防御を提供します。すべてのページ読み取り時のコンテンツフィルター(データマーキング、隠し要素の除去、ARIAのスクリュービング、URLブロックリスト)、およびエージェントが参照する前にページ由来のコンテンツをスキャンするサイドカーサブプロセス内のローカルML分類器、そしてブロック前に分類器の合意を要求する判決コンバイナです。ページの内容は信頼できない入力として扱われ、エージェントはページから構文を取りますが、決して指示をもらいません。ブラウザ駆動のQAを使用する前後で確認すべきこと:

  • エージェントが操作できる認証済み環境を事前に決定し、フォールバックエンジンを使用する場合は、QA作業のために隔離されたプロファイルを優先する。
  • 緊急時のキルスイッチを認識する:GSTACK_SECURITY_OFF=1 はセキュリティレイヤーを無効にします。これを設定したままにしないこと。
  • 永続デーモンは実行間でクッキーとセッションを保持するため、完了後には停止し、ps aux | grep -i chrom のようなコマンドで何も実行されていないことを確認すること。
  • 有効にする前に、クローンされたリポジトリ内のフックとセーフティメカニズムを読むこと。これらはプレーンファイルなので、CI設定をレビューするようにレビューすること。
  • クローンを更新した後、./setup を再実行し、生成されるコンポーネントがスキル定義と同期しているようにすること。

セーフティガードレールと第二の意見

3つのパワーツールがセッションレベルのセーフティスイッチとして機能します。/careful は破壊的なコマンド(rm -rf、DROP TABLE、フォースプッシュ、git reset --hard)の前に警告を出し、「be careful」と言うと活性化します。ルートディレクトリやホームディレクトリの再帰的削除、デフォルトブランチへのフォースプッシュは硬直的に拒否されます。/freeze はファイル編集を1つのディレクトリに制限し、デバッグ中にエージェントが無関係なコードを「修正」できないようにし、/guard は両方を同時に活性化します。

第二の意見レビューはハーネスを横断します。Claude Codeでは、/codex は作業をOpenAI Codex CLIに送り、独立したレビュー、挑戦、または相談を行います。他のハーネスでは、/claude-code が逆を行います。各レポートは、実際にレビューを完了したプロバイダを特定します。

実践的なgstackワークフロー

すべての変更に対してgstackのすべてのスキルを必要としません。合理的な機能開発ワークフロー:

  1. /office-hours
  2. /plan-ceo-review
  3. 実装計画の作成
  4. /plan-eng-review
  5. 実装
  6. /review
  7. /qa
  8. /ship

どのレビュースキルを追加するかは、ソフトウェアの対象が誰であるかによって異なります。

開発対象 計画ステージ(コード前) ライブ監査(出荷後)
最終ユーザー(UI、Webアプリ、モバイル) /plan-design-review /design-review
開発者(API、CLI、SDK、ドキュメント) /plan-devex-review /devex-review
アーキテクチャ(データフロー、パフォーマンス) /plan-eng-review /review
上記すべて /autoplan –

自明的なバグ修正の場合、investigate、実装、レビュー、テストに直接進むことが多いです。同じ形状のツール中立バージョン(仕様、デザイン、タスク、実装、検証)は、要件からコードまでの仕様駆動開発ワークフローにあります。プロジェクトのREADMEは、これらスプリントの10から15個を並列実行し、それぞれが独自の隔離ワークスペースを持つことを説明しています。スプリント構造こそが、並列エージェントが混沌の源にならないように保つものだと、プロジェクトは述べています。

gstackのインストール

現在のインストールには、動作するClaude Codeセットアップ、Git、Bun v1.0+、およびWindowsの場合Node.jsが必要です。BunはWindows上でPlaywrightのパイプトランスポートに既知のバグがあるため、browseサーバーはそこではNode.jsにフォールバックします。まだClaude Codeを設定していない場合は、まず Claude Code概要 から始めてください。macOSでは、ブラウザスキルのためにAsideブラウザ(macOS 15以降)が推奨されます。これがない場合、バンドルされたChromiumデーモンが使用されます。

  1. 前提条件を確認します:git --version と bun --version(ツールチェーンはBunベースです)。

  2. gstackをClaudeスキルディレクトリにクローンします:

    git clone --single-branch --depth 1 \
      https://github.com/garrytan/gstack.git \
      ~/.claude/skills/gstack
    
  3. クローンされたディレクトリからセットアップスクリプトを実行します:

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

    セットアップは、サポート対象のスキルに必要なコンポーネントをインストールし生成し、バンドルされたブラウザをビルドします。Chromiumのインストール失敗はベストエフォートであり、セットアップは理由を記録し、すべてのスキルの登録を完了し、どのスキルが影響を受けるかを出力します。

  4. プロジェクトの CLAUDE.md に ## gstack セクションを追加します。プロジェクトのインストール手順にはこのステップが含まれており、これがClaude Codeがスキルをルーティングする理由です:すべてのWeb閲覧にはgstackの /browse を使用し、mcp__claude-in-chrome__* ツールは決して使用せず、利用可能なスキルを列挙します。

  5. インストールを検証します:クローンされたディレクトリに生成されたファイルが存在することを確認し、Claude Codeセッションを開始し、スクラッチプロジェクトで /office-hours を実行して、スキルが認識されることを確認します。

チームモード

リポジトリにおいて、gstackは、開発者が個別に設定された環境ではなく、1つのワークフローを共有するチーム志向のセットアップを提供します。

(cd ~/.claude/skills/gstack && ./setup --team) && \
  ~/.claude/skills/gstack/bin/gstack-team-init required && \
  git add .claude/ CLAUDE.md && \
  git commit -m "require gstack for AI-assisted work"

required は、gstackがない場合のリポジトリ内でのAI支援作業をブロックします。チームメイトをブロックするのではなく促すために、これを optional に交換できます。リポジトリにファイルはベンダリングされません。すべてのClaude Codeセッションは、高速な自動更新チェック(1時間に1回にスロットリングされ、ネットワーク障害に安全、サイレント)から始まります。これにより、チーム内のバージョンドリフトが解消されます。個人的な設定は1つの開発者を向上させ、リポジトリレベルの設定は共有されたエンジニアリング慣行を生み出します。

他のハーネス、アップグレード、アンインストール

  • 他のエージェント:./setup --host codex、--host opencode、--host cursor、--host factory、--host kiro、--host slate、--host openclaw、および --host hermes は、スキルを各エージェントの独自のスキルディレクトリにインストールします。agents-digest/gstack-AGENTS.md にある2KBの指示専用ダイジェストは、ルールファイルのみを読み取れるエージェントを対象にします。
  • コマンド命名:スキルはデフォルトで短い名前で登録されます(/qa、/review)。./setup --prefix は名前空間付きの名前(/gstack-qa)に切り替え、gstackと他のスキルパックを並行して実行する場合に重要です。
  • アップグレード:git pull の後で ./setup を再実行(ファイルコピーでインストールされるWindowsでは必須)、または /gstack-upgrade スキルを使用します。~/.gstack/config.yaml で auto_upgrade: true を設定すると、インストールが自動的に最新に保たれます。
  • テレメトリはデフォルトでオフであり、初回実行時にオプトインを求めます。オプトインした場合、スキル名、実行時間、成功/失敗、gstackバージョン、OSが送信されます。コード、ファイルパス、リポジトリ名、プロンプトは決して送信されません。gstack-config set telemetry off でいつでも無効にできます。
  • アンインストール:~/.claude/skills/gstack/bin/gstack-uninstall は、スキル、シンボリックリンク、~/.gstack/ の状態、プロジェクトローカル状態、browseデーモン、フック登録を削除します。

インストールの検証と一般的な失敗の修正

  • ./setup が失敗する – bun --version でBunがPATHにあることを確認します。生成されるコンポーネントはBunツールチェーンによってビルドされます。
  • Claude Codeによってスキルが認識されない – クローンが実際に ~/.claude/skills/gstack に存在すること、プロジェクトの CLAUDE.md にgstackセクションがあることを確認し、./setup を再実行します。
  • /browse が NEED_ASIDE または ASIDE_NOT_RUNNING を報告する – プローブはフォールバックブラウザを使用することを示しています。LinuxおよびWindowsでは正常です。macOSでは、Asideが開かれていないか、サインインされていないことを意味します。
  • フォールバックブラウザが失敗する – cd ~/.claude/skills/gstack && bun install && bun run build を実行します。
  • 更新後の古いインストール – /gstack-upgrade を実行するか、~/.gstack/config.yaml で auto_upgrade: true を設定します。

gstackをすべて採用せずに試す

開発プロセスを移行するのではなく、gstackを実在するが非クリティカルな機能に使用してください。プロジェクトのクイックスタートは同じ試行であり、「そこで止まる」ことで終わります:

  1. /office-hours – 問題定義
  2. /plan-ceo-review – プロダクト推論
  3. /review – 実装後のエンジニアリング検証
  4. /qa – Webプロジェクトのランタイム検証

これらのステージが、通常のClaude Codeワークフローが見逃す発見事項を表面化させる場合、システムの残りは探る価値があります。一方、エンジニアリング判断を変えることなく、追加のテキストを生成するだけの場合、スタック全体を採用することはおそらく助けになりません。

gstackが得意なこと

分離されたエンジニアリング役割。 巨大な「シニアエンジニアになれ」という指示の代わりに、プロダクト戦略、アーキテクチャ、UX、QA、セキュリティ、リリースエンジニアリングは、それぞれ独自の推論モードを得ます。

検証であり、単なる生成ではない。 レビュー、回帰テスト生成付きのブラウザQA、セキュリティ監査、ベンチマーキング、およびship-deploy-canaryチェーンは、gstackにおいて任意の事後処理ではなく、第一級のワークフローです。

検査可能。 行動レイヤーの多くは、プロプライエタリ自律エージェントの内部ワークフローとは異なり、開発者が読んで修正できるプレーンなMarkdownファイルです。リポジトリは、スタック自体の監査ツールも同梱しています:gstack-context-bill はインストールされたスキルツリーのコスト(トークン数)を報告し、gstack-egress はテレメトリを含むすべてのマシン外送信に対してハッシュチェーン付きレシートを書き出します。

チームインフラストラクチャ。 スキルはエンジニアリング慣習をエンコードできます。各セッションで

API互換性を確認し、統合テストを実行し、
ブラウザコンソールを調べ、変更履歴を更新することを忘れないでください。

とタイプする代わりに、要件は再利用可能なワークフローに存在し、チームモードはそのワークフローをリポジトリ要件にします。

gstackが過剰になり得る場所

gstackは意図的に意見が強められており、それが適合性を制限します:成熟した組織には、すでにアーキテクチャレビュー手順、リリースツール、CIゲート、QA自動化、セキュリティスキャン、ADR慣習、仕様テンプレート、コードレビューポリシーがあり、上に別の完全なメソッドロジーを追加すると、明確さではなく重複を生みます。

また、コンテキストとトークンのコストもあります。各追加のレビューステージは、リポジトリ検査、モデル推論、および潜在的により多くの外部モデル呼び出しを追加します。目標は、正しいソフトウェアを出荷するために必要な最小の信頼できるプロセスであり、AIレビューの最大数ではありません。gstack-context-bill は、どの程度保持するか決定する前に、インストールされたスキルセットがセッションあたり実際にどれほどのコストかを定量化できます。

gstackは、すべてのコミットのための儀式としてではなく、選択し適応するワークフローを持つツールボックスとして最も機能します。

gstackの代替品と組み合わせ

最も近い代替品と、各々が占めるレイヤー:

システム 主な焦点 ワークフロースタイル エージェント可搬性 最適な適合
gstack 完全なエンジニアリングワークフロー 役割指向のスキルとツール ./setup --host を介した10エージェント 端到端AI支援エンジニアリング
Superpowers エンジニアリングメソッドロジー 自動的な構成可能スキル 高い 規律あるコーディングとTDD
OpenSpec 変更仕様 軽量な仕様成果物 高い ブラウンフィールド機能開発
GitHub Spec Kit 仕様駆動開発 構造化された多段階ワークフロー 高い 形式的な要件からコードのプロセス
BMAD Method AI駆動アジャイル開発 適応的な役割とワークフロー 高い より大きな端到端プロジェクト
Ruflo マルチエージェントオーケストレーション エージェント、スウォーム、メモリ プラットフォーム志向 並列自律エージェントシステム
カスタムスキル 独自のプロセス 完全にカスタマイズ可能 非常に高い可能性 確立された実践を持つ成熟したチーム

gstack + Superpowers:役割内の実装規律

両方ともスキルフレームワークであり、最も重複します。組み合わせる場合の役割分担:gstackが周囲の役割(プロダクト、デザイン、QA、リリース)を提供し、Superpowersが実装フェーズ内の規律(TDD、実装前の計画、体系的なデバッグ、サブエージェントレビュー)を提供します。両方のスキルセットをインストールし、同じフェーズに対して2つの矛盾する指示をエージェントが見ないように、重複するスキルを削減します。コマンド名が衝突する場合、gstackを ./setup --prefix でインストールし、スキルが /gstack-* として登録され、他のパックと共存するようにします。インストールとワークフローの詳細は、Superpowersクイックスタートにあります。

gstack + OpenSpec:永続的な仕様、ライブレビュー

OpenSpecは、明示的な変更仕様(提案された変更、仕様、設計決定、実装タスクの成果物)を中心に、人間とエージェントを揃えます。重要な特性は永続性です。チャット会話はコンテキスト履歴に消えますが、仕様はリポジトリに残り、人間と将来のエージェントセッションがレビューできます。gstackは、仕様が存在する前のプロダクトレビューと、実装後のレビューとQAを追加します:

flowchart LR A[機能リクエスト] --> B[gstack プロダクトレビュー] B --> C[OpenSpec 変更] C --> D[実装] D --> E[gstack レビュー] E --> F[gstack QA]

具体的なシーケンス:/office-hours と /plan-ceo-review を実行し、結果をOpenSpec変更としてキャプチャし、それに対して実装し、その後 /review と /qa を実行します。gstackが独自の /spec スキルも同梱していることに注意してください。これは仕様を ~/.gstack 配下にアーカイブします。OpenSpecが仕様の所有者である場合、2つが発散しないようにgstackの /spec をループから外してください。OpenSpecクイックスタートは、探索-提案-適用-アーカイブのループを詳細に説明しています。

gstack + GitHub Spec Kit:1つの計画バックボーンを選択

Spec Kitのコアワークフローは、明示的なステージのシーケンス(憲法、仕様化、計画、タスク、実装、収束)であり、バグ修正、アイデア評価、拡張、プリセット、統合に拡張されています。Spec Kitとgstackの両方が計画ステージを中心にしているため、両方の完全なフローを実行すると作業が重複します。要件トレーサビリティと形式的なステージが重要であれば、Spec Kitに仕様バックボーンを所有させ、Spec Kitが強制しないレイヤー(プロダクトレビュー、デザインレビュー、ブラウザQA、出荷)にはgstackを使用します。KiroやClaude Codeを含む、より広い仕様駆動セットアップの比較は、GitHub Spec Kit vs Kiro vs Claude Code SDD ワークフローにあります。

BMAD と Ruflo:異なる軸

BMADは、適応的なワークフローでプロダクト思考、仕様、アーキテクチャ、実装をカバーする、より広いAI駆動開発メソッドロジーです。儀礼の規模を作業の大きさにスケーリングします。BMADとgstackの両方がプロセスバックボーンの役割を果たすため、両方を完全に実行するのではなく、バックボーンとして1つを選択してください。gstackの個別のスキルは、メソッドロジーと同時に選択できます。

Rufloはマルチエージェントオーケストレーションを対象としています:協調するワーカー、共有メモリ、スウォーム。gstackは複数の専門家の視点を1つのエンジニアリングワークフローに適用します。一方、オーケストレーションプラットフォームは複数の実行エージェントを1つのエンジニアリング目標に適用します。境界は曖昧です – gstackは外部ツールや追加のモデルを呼び出すことができ、オーケストレーターは構造化されたエンジニアリング役割を実装できます – しかし、決定は独立しています。問題がエージェントがエンジニアリング規律をスキップすることである場合、スキルフレームワークが直接的な修正です。10のエージェントを多数のタスクとリポジトリで同時に実行している場合、オーケストレーターはgstackのようなワークフローの上にあるもので、それを置き換えるものではありません。

カスタムスキル:最もカスタマイズ可能なレイヤー

フレームワークを完全にスキップし、チームがすでに遵守している手順のための小さなスキルコレクションを作成することもできます:

skills/
  architecture-review/
  api-review/
  database-migration-review/
  incident-analysis/
  release-check/
  security-review/

各スキルは、汎用的なフレームワークが知っていることのできない組織固有のナレッジをエンコードします。データベースマイグレーションスキルは、ロールバック分析、テーブルロック分析、インデックスへの影響レビュー、マイグレーション時間見積もり、デプロイ順、以前のアプリケーションバージョンとの互換性を要求できます。APIレビュースキルは、後方互換性、認証チェック、ページングの一貫性、べき等性分析、レートリミット動作、OpenAPI変更を要求できます。実用的なパス:実際に使用するgstackスキルから始まり、その構造を独自の skills/ ディレクトリにコピーし、慣習に合わせてチェックを書き直します。

4つのレイヤー:スキル、仕様、メソッドロジー、オーケストレーター

これらのツールの大部分をカバーする4つのレイヤーがあり、上記の組み合わせがどのように適合するかを示しています:

スキルは「エージェントはどのように行動すべきか?」に答える

gstack、Superpowers、カスタムエージェントスキル。

仕様システムは「何 именноを構築しているのか?」に答える

OpenSpecとGitHub Spec Kit。基本的な仕様駆動の概念と用語は、仕様駆動開発とは何か?で定義されています。

メソッドロジーは「プロジェクトはアイデアからソフトウェアにどのように進むべきか?」に答える

BMAD、Superpowers、gstackの一部。

オーケストレーターは「複数のエージェントはどのように仕事を執行すべきか?」に答える

Rufloと他のマルチエージェントランタイム。

レイヤーは構成可能であり、開発環境はこれら4つすべてを含めることができます:

flowchart TD A[プロダクト要件] --> B[仕様システム] B --> C[エンジニアリングワークフロー] C --> D[エージェントオーケストレーター] D --> E[実装エージェント] D --> F[テストエージェント] D --> G[レビューエージェント] D --> H[QAエージェント] E --> I[リポジトリ] F --> I G --> I H --> I

gstackはすでにこれらの境界のいくつかを跨いでいます。

gstackを使うべきか?

プロジェクトのREADMEは、対象読者を、それでもなお出荷したいテクニカルな創業者やCEO、空白のプロンプトの代わりに構造化された役割を求める初めてのClaude Codeユーザー、そしてすべてのPRに対して厳密なレビュー、QA、リリース自動化を望むテックリードやスタッフエンジニアと説明しています。コーディングエージェントを広く使用しており、制限要因がもはやコード生成自体ではない場合、gstackを試す価値があります。典型的な症状:

  • エージェントが問題を理解する前に実装を始める
  • 実装計画がアーキテクチャ上の影響を見落とす
  • 生成されたコードがテストはパスするがブラウザで失敗する
  • レビューがセッション間で一貫しない
  • リリース手順が繰り返し忘れられる
  • 異なる開発者が全く異なる方法でエージェントにプロンプトする
  • 有用なエンジニアリング指示がCLAUDE.mdファイルに埋もれたままになっている
  • 同じレビュープロンプトを手動で繰り返しタイプしている

自動化がすでに強力な決定論的ゲートを提供し、エージェントが小さく、明確に指定されたタスクのみを処理する場合、gstackはほとんどを追加しません。

gstackとAIソフトウェア開発の方向性

gstackが位置するシフトは世代を追跡しています:コード補完(2022-2023年)、コーディングエージェント(2024-2025年)、仕様とエージェントワークフロー(2025-2026年)、そしてプログラム可能なAIエンジニアリング組織。製品は変化しますが、モデルは常に1つのコンポーネントであり続けます。エンジニアリングの品質はますます周囲のシステムに依存するようになります。

  • 永続的な仕様
  • 再利用可能なスキル
  • リポジトリナレッジ
  • ブラウザアクセス
  • テスト
  • 決定論的ツール
  • レビューループ
  • セキュリティコントロール
  • メモリ
  • 人間の承認境界
  • オーケストレーション

結論

gstackは、コーディングエージェントの周囲のエンジニアリングプロセスであり、検査可能でバージョン管理されたスキルとしてパッケージ化されています。その価値は、個々のスキルにあるのではなく、そのプロセスをエージェントに強制することにあります。

試行シーケンスから始め、その位置を稼ぐスキルのみを保持してください。それを超えて、方向性は構成可能なレイヤー – 仕様、スキル、決定論的検証、オーケストレーション – で、それぞれが他のものができないことを実行します。

参考文献

購読する

システム、インフラ、AIエンジニアリングの新記事をお届けします。