Back to Blog
Claude CodegstackAI開発効率化ツール紹介

gstack 完全ユーザーマニュアル — Claude Codeを仮想エンジニアチームに変えるツールセット

gstack 完全ユーザーマニュアル

Y Combinator代表 Garry Tan 氏が公開した Claude Code 用ツールセット「gstack」を使い倒すための実践ガイド

目次

  1. gstackとは何か
  2. なぜgstackを使うのか
  3. 前提条件とインストール
  4. スプリント方式の哲学
  5. 基本コマンド早見表
  6. フェーズ別スキル詳細解説
  7. パワーツールとマルチAI連携
  8. 安全機能（ガードレール）
  9. ブラウザ操作機能の活用
  10. GBrain — 永続的記憶システム
  11. 並列開発戦略
  12. 実践ワークフロー例
  13. 設定とカスタマイズ
  14. トラブルシューティング
  15. アンインストール
  16. 付録：voice入力での使い方

1. gstackとは何か

gstack は、Y Combinator 代表 Garry Tan 氏が「自分が実際に毎日使っている開発手法」をオープンソース化したものです。Claude Code（およびその他のAIコーディングエージェント）に約30種類の専門的な役割（スキル）を与え、1人の開発者を仮想エンジニアリングチームに変えます。

gstackが提供する仮想的な役職

役割 担当スキル
CEO / 創業者 /plan-ceo-review, /office-hours
エンジニアリングマネージャー /plan-eng-review, /retro
シニアデザイナー /plan-design-review, /design-consultation
デザイナー兼エンジニア /design-review, /design-html
スタッフエンジニア（コードレビュアー） /review, /investigate
QAリード /qa, /qa-only
リリースエンジニア /ship, /land-and-deploy
SRE / パフォーマンスエンジニア /canary, /benchmark
Chief Security Officer /cso
テクニカルライター /document-release, /document-generate
デベロッパーエクスペリエンスリード /plan-devex-review, /devex-review
QAエンジニア（ブラウザ操作） /browse, /open-gstack-browser

重要な前提

  • MITライセンス、完全無料、プレミアム版なし
  • Markdownファイルとシェルスクリプトの集合体であり、ブラックボックスではない
  • すべての挙動を自分でフォーク・改造可能
  • Claude Code 以外にも、OpenAI Codex CLI、OpenCode、Cursor、Factory Droid、Slate、Kiro、Hermes、GBrain、OpenClaw など計10種類のAIエージェントに対応

2. なぜgstackを使うのか

解決する問題

Claude Code は強力ですが、空白のプロンプトに向き合うと多くの開発者が同じ罠にはまります。

罠 gstackの対処
機能依頼を字義通りに実装してしまう /office-hours が「本当は何を作っているのか」を問い直す
計画が抽象的なまま実装に入る /plan-eng-review が図解と状態遷移を強制
デザインが「いかにもAI生成」になる /plan-design-review がAIスロップ（AI臭）を検出
CIは通るが本番でバグる /review がN+1、レース、トラスト境界を網羅的に確認
認証ページなどブラウザ操作が必要なテストができない /qa + /browse が実ブラウザで操作
ドキュメントが古くなる /document-release が差分から自動更新
大量の並列セッションが管理できない スプリント構造により各セッションが自律的に進行

Karpathy の4つの失敗モードに対応

Andrej Karpathy が指摘するAIコーディングの4大失敗モード（誤った前提、過剰な複雑性、無関係な編集、宣言的でない命令的記述）に対し、gstackはワークフロー全体で対応策を組み込んでいます。

3. 前提条件とインストール

必要なもの

ツール 用途 必須/任意
Claude Code メインエージェント 必須
Git バージョン管理 必須
Bun v1.0+ TypeScript実行環境 必須
Node.js Windowsでブラウザ操作時に必要 Windowsのみ
Chrome / Chromium 系ブラウザ クッキーインポート用 任意
OpenAI API キー /codex 機能用 任意
Supabase アカウント GBrain クラウド連携用 任意

インストール手順（30秒）

ステップ1：マシン全体にインストール

Claude Code を開いて以下をそのまま貼り付けるだけです。Claude が実行してくれます。

Install gstack: run `git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git ~/.claude/skills/gstack && cd ~/.claude/skills/gstack && ./setup` then add a "gstack" section to CLAUDE.md that says to use the /browse skill from gstack for all web browsing, never use mcp__claude-in-chrome__* tools, and lists the available skills.

なお、上記コマンドは公式のオリジナル（garrytan/gstack）から取得します。フォーク版（daichitsuchiya39-creator/gstack）を使いたい場合は、URLを置き換えてください。

git clone --single-branch --depth 1 https://github.com/daichitsuchiya39-creator/gstack.git ~/.claude/skills/gstack
cd ~/.claude/skills/gstack && ./setup

ステップ2：チームモード（プロジェクト共有・推奨）

リポジトリ内で以下を実行すると、チーム全員に自動配布されます。

(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必須化
  • optional：使用を推奨するがブロックはしない
  • リポジトリにファイルをvendoringせず、毎セッション開始時に自動更新（1時間に1回スロットル、ネットワーク失敗時セーフ、完全サイレント）

ステップ3：他のAIエージェントに導入する場合

# 自動検出（インストール済みエージェントすべて）
cd ~/.claude/skills/gstack && ./setup

# 特定エージェント指定
./setup --host codex      # OpenAI Codex CLI
./setup --host opencode   # OpenCode
./setup --host cursor     # Cursor
./setup --host factory    # Factory Droid
./setup --host slate      # Slate
./setup --host kiro       # Kiro
./setup --host hermes     # Hermes
./setup --host gbrain     # GBrain (modified)

コマンドプレフィックスの設定

# 短いコマンドにする（推奨）: /qa, /ship, /review
cd ~/.claude/skills/gstack && ./setup --no-prefix

# 名前空間付きにする: /gstack-qa, /gstack-ship
cd ~/.claude/skills/gstack && ./setup --prefix

複数のスキルパックを併用する場合のみ --prefix を推奨。

CLAUDE.md への記載

プロジェクトのCLAUDE.mdに以下のセクションを追加してください（インストール時に自動で行われるはずですが、手動追加が必要な場合の参照）。

## gstack
Use /browse from gstack for all web browsing. Never use mcp__claude-in-chrome__* tools.
Available skills: /office-hours, /plan-ceo-review, /plan-eng-review, /plan-design-review,
/design-consultation, /design-shotgun, /design-html, /review, /ship, /land-and-deploy,
/canary, /benchmark, /browse, /open-gstack-browser, /qa, /qa-only, /design-review,
/setup-browser-cookies, /setup-deploy, /setup-gbrain, /sync-gbrain, /retro, /investigate,
/document-release, /document-generate, /codex, /cso, /autoplan, /pair-agent, /careful,
/freeze, /guard, /unfreeze, /gstack-upgrade, /learn.

4. スプリント方式の哲学

gstackは単なるツール集ではなく、スタートアップのスプリント運用そのものを再現するプロセスです。

コア・サイクル

考える → 計画する → 作る → レビュー → テスト → 出荷 → 振り返る
Think → Plan → Build → Review → Test → Ship → Reflect

各スキルは次のスキルへ自動的にデータを引き継ぎます。

フェーズ スキル 引き渡す成果物
Think /office-hours 設計ドキュメント（~/.gstack/projects/）
Plan /plan-ceo-review → /plan-eng-review スコープ決定 + テストプラン
Build （実装） コード差分
Review /review, /codex バグレポート（自動修正）
Test /qa QAレポート + リグレッションテスト
Ship /ship → /land-and-deploy PR → 本番デプロイ
Monitor /canary 本番ヘルス確認
Reflect /retro 週次振り返り

重要な原則：何も「すり抜けない」のは、各ステップが前のステップを知っているからです。/qa は /plan-eng-review が書いたテストプランを自動的に拾います。/review が見つけたバグは /ship が修正済みであることを確認します。

5. 基本コマンド早見表

最低限覚えるべき7つのコマンド

コマンド 使うタイミング
/office-hours 新しいアイデアを始めるとき
/autoplan 計画フェーズを一気に走らせたいとき
/review コードを書き終えたとき
/qa <URL> アプリの動作確認をしたいとき
/ship PRを作成したいとき
/land-and-deploy マージしてデプロイしたいとき
/retro 週次振り返り

あなたが作っているもの別の「レビュー選択ガイド」

作っているもの 計画段階（実装前） ライブ監査（実装後）
エンドユーザー向け（UI、Web、モバイル） /plan-design-review /design-review
開発者向け（API、CLI、SDK、ドキュメント） /plan-devex-review /devex-review
アーキテクチャ（データフロー、パフォーマンス、テスト） /plan-eng-review /review
上記すべて /autoplan（CEO→デザイン→エンジニア→DXを自動実行） —

6. フェーズ別スキル詳細解説

6.1 Thinkフェーズ：問題を再定義する

/office-hours — YCオフィスアワー

いつ使うか：新しいプロジェクトやアイデアの最初。1行もコードを書く前。

何をするか： ユーザーが言った機能依頼を字義通り受け取らない。代わりに6つの「強制質問」を投げかけて、実は何を作っているのかを明らかにします。

2つのモード：

  1. Startup mode（スタートアップモード）：YC パートナーの評価軸を踏襲

    • 需要の現実性
    • 現状（status quo）
    • 絶望的な具体性（誰か1人の人間を名指しできるか）
    • 最も狭い楔（narrowest wedge）
    • 観察と驚き
    • 未来適合性

  2. Builder mode（ビルダーモード）：ハッカソン、副業、OSS、学習向け

    • 「うわっ」と言わせる版は何か
    • 共有できるものへの最短経路
    • 質問は生成的で、批判的ではない

実例：

あなた:「カレンダー用のデイリーブリーフィングアプリを作りたい」
Claude:「あなたが本当に作っているのは『パーソナル・チーフ・オブ・スタッフAI』だ」
       → 説明されていなかった5つの能力を抽出
       → 4つの前提を提示し、合意・反論・調整を求める
       → 3つの実装アプローチと工数見積もりを生成
       → 設計ドキュメントを `~/.gstack/projects/` に書き出し

その設計ドキュメントはそのまま /plan-ceo-review と /plan-eng-review に渡されるため、文脈の引き継ぎ作業は不要です。

6.2 Planフェーズ：堅牢な計画を立てる

/plan-ceo-review — CEO/創業者モード

いつ使うか：機能依頼を受け取った後、コードを書く前。

何をするか： Brian Cheskyモードと呼んでいます。「この機能をどう実装するか」ではなく「この依頼の中に隠れている10星級のプロダクトは何か」を問います。

例：Craigslist風リスティングアプリで「出品者が写真をアップロードできるようにする」と言ったら：

  • 弱いアシスタント：ファイルピッカーを追加、画像を保存
  • /plan-ceo-review：
    • 写真から商品を識別できないか
    • SKUや型番を推測できないか
    • Web検索でタイトルと説明文を自動生成できないか
    • スペック、カテゴリ、価格比較を取得できないか
    • どの写真がヒーロー画像として転換率が高いか提案できないか
    • アップロード写真が暗い・雑然・低信頼に見えるとき検知できないか

4つのモード：

モード 用途
SCOPE EXPANSION 野心的な拡張案を1つずつ提示、熱心に推奨
SELECTIVE EXPANSION 現スコープを基本として、追加機会を中立的に提示
HOLD SCOPE 既存計画への最大限の厳密さ。拡張は出さない
SCOPE REDUCTION 最小限の動くバージョンを探す

永続化：ビジョンと決定事項は ~/.gstack/projects/ に保存され、会話が終わっても残ります。優れたビジョンはリポジトリの docs/designs/ にプロモートできます。

/plan-eng-review — エンジニアリングマネージャーモード

いつ使うか：プロダクト方向性が固まった後、実装を始める前。

何をするか： ブレインストーミング的な発散を止め、最高の技術リードのように振る舞います。アーキテクチャ、システム境界、データフロー、状態遷移、失敗モード、エッジケース、トラスト境界、テストカバレッジを詰めます。

最大の解放装置：図解

LLMはシステムを描かせると一気に完全になります。/plan-eng-review は以下を強制します：

  • シーケンス図
  • 状態遷移図
  • コンポーネント図
  • データフロー図
  • テストマトリクス

「波打つ手」でごまかすことが難しくなります。

Review Readiness Dashboard： すべてのレビュー（CEO、Eng、Design）の結果がログされ、ダッシュボードに表示されます。/ship 前にこのダッシュボードが必ずチェックされます。

+========================================================+
|              REVIEW READINESS DASHBOARD                 |
+========================================================+
| Review        | Runs | Last Run         | Status      |
|---------------|------|------------------|-------------|
| Eng Review    |  1   | 2026-03-16 15:00 | CLEAR       |
| CEO Review    |  1   | 2026-03-16 14:30 | CLEAR       |
| Design Review |  0   | —                | —           |
+========================================================+
| VERDICT: CLEARED — Eng Review passed                   |
+========================================================+

Eng Review のみ必須ゲートです（gstack-config set skip_eng_review true で無効化可能）。

Plan-to-QAフロー： /plan-eng-review がテストレビューを終えると、テストプラン成果物を ~/.gstack/projects/ に書き出します。あとで /qa を実行すると、そのテストプランが自動的に拾われます。

/plan-design-review — シニアデザイナーモード（計画段階）

いつ使うか：計画書はあるが実装はまだ。デザインの抜けを早期発見したい。

何をするか： 計画書を0〜10点で評価。「10点とはどういう状態か」を説明し、計画書を編集して改善します。

7つの監査パス：

  1. 情報アーキテクチャ
  2. インタラクション状態のカバー範囲（ローディング、空、エラー、成功、ホバー）
  3. ユーザージャーニー
  4. AIスロップリスク（「クリーンでモダンなUI」「グラデーション付きヒーロー」など、AI生成丸出しのパターン）
  5. デザインシステム整合性
  6. レスポンシブ/アクセシビリティ
  7. 未解決デザイン決定

実例：

初期評価: 4/10
"このプランはユーザーダッシュボードを記述しているが、
 ユーザーが最初に何を見るかが指定されていない。
 'アイコン付きカード'と言っているが、これは全てのSaaSテンプレートと同じ。
 ローディング状態0、空状態0、モバイル挙動の記述なし。"

最終評価: 4/10 → 8/10（修正後）
"プランはデザイン完了。実装後 /design-review でビジュアルQAを。"

/plan-devex-review — DX（開発者体験）レビュアーモード

いつ使うか：API、CLI、SDK、ドキュメントなど開発者向けプロダクトを計画中。

何をするか：

  • 開発者ペルソナを掘り下げる
  • 競合製品のTTHW（Time To Hello World）をベンチマーク
  • マジカルモーメントを設計
  • 摩擦点をステップごとにトレース

3つのモード：

モード 用途
DX EXPANSION 拡張的DX
DX POLISH 既存DXの磨き上げ
DX TRIAGE 摩擦点の優先順位付け

20〜45の強制質問を投げます。

/design-consultation — デザインパートナーモード

いつ使うか：何もない状態から始めるとき。デザインシステム未定義、フォント未選定、カラーパレット未定。

何をするか： シニアデザイナーが横に座って、視覚的アイデンティティ全体を一緒に作ります。

  • 美的方向性
  • タイポグラフィ（3+ フォントを役割別に）
  • カラーパレット（16進値付き）
  • スペーシングスケール
  • レイアウトアプローチ
  • モーション戦略

整合性は当たり前。差別化が本質： 「整合性」だけならどの開発ツールも同じです。clean sans-serif、ミュートグレー、ブルーアクセント。/design-consultation は意図的なクリエイティブリスクを提案します。

  • 見出し用の予想外のセリフ書体
  • カテゴリで誰も使っていない大胆なアクセント色
  • データに「権威感」を出す詰めたスペーシング

最終成果物：

  • DESIGN.md をリポジトリルートに書き出し（デザイン唯一の真実）
  • CLAUDE.md を更新（全Claude Codeセッションがこのシステムを尊重）
  • 以降、/design-review がこのシステムに照らして監査可能

6.3 Buildフェーズ：実装

実装フェーズ自体には専用スキルはありません。/plan-ceo-review と /plan-eng-review の出力（計画書）をClaude Codeに渡し、「プランを承認、実装してください（Approve plan. Exit plan mode.）」と指示するだけで実装が始まります。

ただし以下のスキルが実装中に役立ちます：

/design-shotgun — デザイン探索モード

いつ使うか：機能、ページ、ランディング画面のビジュアルが固まらないとき。

何をするか： GPT Image APIを使って3〜6種類のビジュアルバリアントを生成し、ブラウザに比較ボードを開きます。

Taste Memory（味覚記憶）： セッションを跨いで好みを記憶。ミニマルを好む傾向があれば、将来の生成がバイアスされます。設定するものではなく、承認から創発します。

/design-html — デザイン→コード変換モード

いつ使うか：承認したモックアップを実装可能なHTMLに変換したいとき。

何をするか： Pretext（Cheng Lou氏作、元React core）を使い、DOM測定なしで動的計算されるレイアウトを生成します。

ほとんどのAIコード生成は静的CSSを吐きます。ハードコードされた高さ、リサイズで溢れるテキスト、スナップするブレークポイント。/design-html はそれを解決します。

6.4 Reviewフェーズ：バグの先取り

/review — パラノイドなスタッフエンジニアモード

いつ使うか：実装が完了し、テストが緑になった後。

何をするか： 「CIを通過して本番でぶん殴ってくるバグ」を探します。スタイル指摘ではなく構造監査。

探すもの：

  • N+1 クエリ
  • 古い読み取り（stale read）
  • レースコンディション
  • 不適切なトラスト境界
  • インデックス漏れ
  • エスケープバグ
  • 不変条件の破壊
  • 不適切なリトライ
  • 失敗モードを見逃しているテスト
  • 忘れられた enum ハンドラ（新しいステータスや型定数を追加したとき、全 switch 文と allowlist をトレース）

Fix-First方針：

  • 明白な機械的修正：自動修正 → [AUTO-FIXED] file:line Problem → 何をしたか
  • 曖昧な判断（セキュリティ、レース、デザイン決定）：ユーザに確認

/investigate — 体系的デバッガモード

いつ使うか：何かが壊れていて、原因がわからないとき。

Iron Law（鉄則）：根本原因の調査なしに修正しない。

何をするか：

  • データフローをトレース
  • 既知のバグパターンと照合
  • 仮説を1つずつテスト
  • 3回修正に失敗したら停止し、アーキテクチャを疑う

「もう1つだけ試してみる」スパイラルを防ぎ、何時間も無駄にしないようにします。

自動フリーズ： /investigate はデバッグ対象モジュールに対して自動的に /freeze を発動。src/auth/ を調査中にClaudeが src/billing/ を「親切で」編集してしまうのを防ぎます。

/design-review — デザイナー兼コーダーモード（ライブ）

いつ使うか：実装後、ライブサイトの見た目を改善したいとき。

何をするか： ライブサイトに80項目のビジュアル監査を実行。修正ループへ：

  • 各発見項目に対し、ソースファイルを特定
  • 最小限のCSS/スタイル変更
  • style(design): FINDING-NNN でコミット
  • 再ナビゲートして検証
  • ビフォー/アフターのスクリーンショット

実例：

Design Score: C  |  AI Slop Score: D
12 findings (4 high, 5 medium, 3 polish)

style(design): FINDING-001 — 3列アイコングリッドを非対称レイアウトに置換
style(design): FINDING-002 — 見出しスケール 48/32/24/18/16 を追加
style(design): FINDING-003 — グラデーションヒーロー削除、太字タイポグラフィに

Design Score: C → B+  |  AI Slop Score: D → A

/cso — Chief Security Officer

何をするか： OWASP Top 10 + STRIDE 脅威モデル監査を実行。ノイズゼロ設計（17 種類の false positive 除外、8/10+ 信頼度ゲート）。

/codex — 第二意見モード

いつ使うか：別のAIにも見てもらいたいとき。

3つのモード：

  1. review：OpenAI の Codex CLI に同じ差分をレビューさせます。完全独立（Claudeのレビューを見せない）。
  2. challenge：敵対モード。エッジケース、レース、セキュリティホールを能動的に攻撃。
  3. consult：セッション継続のあるオープン会話。

クロスモデル分析：両方がレビュー済みなら、OVERLAP / UNIQUE TO CODEX / UNIQUE TO CLAUDE に分類した比較が生成されます。「同じ患者を2人の医者に診せる」アプローチ。

6.5 Testフェーズ：実ブラウザでQA

/qa — QAリードモード

いつ使うか：機能ブランチで実装が終わり、動作確認したいとき。

4つのモード：

モード 使い方 用途
Diff-aware /qa（自動、機能ブランチ） git diff main を読み、影響ページのみテスト
Full /qa <URL> 全アプリの系統的探索。5〜15分。5〜10個の証拠付き問題
Quick /qa --quick 30秒スモークテスト。ホームページ+トップ5ナビ
Regression /qa --regression baseline.json フルモード→ベースライン比較

実例：

You:   /qa https://staging.myapp.com

Claude: [12ページ探索、3フォーム入力、2フロー検証]

QAレポート: staging.myapp.com — Health Score: 72/100

Top 3 Issues:
1. CRITICAL: チェックアウトフォームが必須項目空でsubmit可能
2. HIGH: モバイルナビメニューが項目選択後に閉じない
3. MEDIUM: ダッシュボードチャートが1024px以下でサイドバーと重なる

6.6 Shipフェーズ：出荷とデプロイ

/ship — リリースマシンモード

何をするか：

  • main と同期
  • 適切なテストを実行
  • changelog やバージョニングを更新
  • push
  • PR を作成または更新

Test Bootstrap： プロジェクトにテストフレームワークがなければ、/ship が自動セットアップ。100%テストカバレッジが目標：vibe coding を safe coding にする。

/land-and-deploy — デプロイパイプラインモード

いつ使うか：PR承認後、本番に出すとき。

PR マージ → CI 待機 → デプロイ完了 → 本番カナリチェック を1コマンドで。

/canary — ポストデプロイ監視モード

ブラウザデーモンを使い、キーページをループでチェック。コンソールエラー、パフォーマンスリグレッション、ビジュアルアノマリを自動検出します。

/document-release — テクニカルライターモード

/ship がPRを作成した後、全ドキュメントファイルを差分とクロスリファレンスして自動更新。/ship から自動呼び出しされるため追加コマンド不要。

6.7 Reflectフェーズ：振り返り

/retro — エンジニアリングマネージャーモード

いつ使うか：週末、月末、リリース後。

バイブではなく、データで何が起きたかを知る。コミット履歴から出荷速度、作業パターン、テストヘルストレンドを分析します。

/retro global で全プロジェクト・全AIツールを横断。

7. パワーツールとマルチAI連携

/autoplan — レビューオートパイロット

CEO + Design + Eng レビューを一括で走らせ、本当に重要な判断だけに集中できます。

自動判断の6原則：

  1. 完全性を選ぶ
  2. 既存パターンに合わせる
  3. 可逆オプションを選ぶ
  4. 過去の類似決定でユーザが選んだ方を選ぶ
  5. 曖昧なものは延期
  6. セキュリティはエスカレート

/pair-agent — マルチエージェント協調

Claude Code と他社AIエージェント（OpenClaw / Hermes / Codex / Cursor）が、スコープ付きトークン、タブ分離、レート制限を持って共有ブラウザで協調。異なるベンダーのAIが安全に同一ブラウザで動く初めての方法です。

/learn — 機関知識モード

gstack は全セッションから学びます。パターン、落とし穴、好み、アーキテクチャ決定が蓄積。他スキルはレコメンド前に自動的に学習を検索します。

23 learnings for this project (14 high confidence, 6 medium, 3 low)

Top patterns:
- [9/10] API responses always wrapped in { data, error } envelope
- [8/10] Tests use factory helpers in test/support/factories.ts
- [8/10] All DB queries go through repository pattern, never direct

8. 安全機能（ガードレール）

/careful — 危険コマンド警告

すべてのBashコマンドを既知の危険パターンと照合：

パターン 危険
rm -rf / rm -r 再帰削除
DROP TABLE / DROP DATABASE / TRUNCATE データ消失
git push --force / git push -f 履歴書き換え
git reset --hard コミット破棄
kubectl delete 本番リソース削除

ホワイトリスト：rm -rf node_modules、dist、.next などのビルドアーティファクトクリーンアップは誤警報なし。

/freeze — 編集ロック

/freeze src/billing

課金バグをデバッグ中に、src/auth/ を「親切に」修正してしまうのを防ぐ。/unfreeze で解除。

/guard — 完全安全モード

/careful + /freeze を1コマンドで。本番触るとき、ライブシステムをデバッグするとき。

9. ブラウザ操作機能の活用

/browse — エージェントに「目」を与える

実Chromiumブラウザで実クリック、実スクリーンショット、〜100ms/コマンド。Playwright（Microsoft製）ベース。

実例：

You: /browse staging.myapp.com — ログインしてサインアップフローをテスト

Claude: [18 tool calls, 〜60秒]

サインアップ動作。オンボーディングにリダイレクト。
変更ページをチェック中...
全4ページ正常読み込み。コンソールエラーなし。

Browser Handoff — 行き詰まったら人間に渡す

CAPTCHA、認証ウォール、MFAなど、ヘッドレスブラウザが行き詰まったら：

Claude: CAPTCHAでスタックしています。可視Chromeを開きます。

> browse handoff "Stuck on CAPTCHA at login page"

全クッキーとタブをそのままに、Chrome が同じURLで開きました。
CAPTCHAを解いて、完了と教えてください。

You: done

Claude: ログイン成功。QA続行。

3回連続失敗で自動的に handoff を提案します。

/setup-browser-cookies — 認証ページのテスト

毎回ヘッドレスブラウザでログインせず、実ブラウザのセッションを直接インポート。Chromium系ブラウザを自動検出し、macOS Keychain 経由でクッキーを復号。

10. GBrain — 永続的記憶システム

GBrain は AI エージェント用の永続的知識ベース。セッションを跨いでエージェントが実際に保持する記憶です。

/setup-gbrain — ワンコマンドセットアップ

4つのパス：

パス 説明 時間
Supabase（既存URL） 別マシンで既にプロビジョン済みのブレインを使う 10秒
Supabase（自動プロビジョン） Personal Access Token を貼り付け、新プロジェクト自動作成 〜90秒
PGLite ローカル アカウントもネットワークも不要、Macローカルのみ 〜30秒
リモート gbrain MCP 別マシンまたは同僚のサーバ 即時

Per-remote Trust Policy（マルチクライアント対応）

層 動作
read-write エージェントはブレイン検索 AND このリポから書き戻し
read-only 検索のみ（マルチクライアントコンサルタント向け）
deny gbrain との一切の相互作用なし

11. 並列開発戦略

1〜3 並列：素のClaude Code

スプリントスキル群を使えば、Claude Code 1セッションで「考える→計画→構築→レビュー→テスト→出荷」を綺麗に運用できます。

10〜15 並列：Conductorで変革モード

Conductor は複数の Claude Code セッションを並列で動かします。

  • セッション1：新アイデアに /office-hours
  • セッション2：PR に /review
  • セッション3：機能を実装
  • セッション4：ステージングに /qa

スプリント構造が並列性を可能にする：プロセスなしの10エージェントは10のカオスソース。プロセスありなら、各エージェントが何をすべきか、いつ止まるべきかを知っています。

12. 実践ワークフロー例

パターンA：新しいアイデアから本番まで（フルスプリント）

1. /office-hours
   → 6つの強制質問、設計ドキュメント生成

2. /plan-ceo-review
   → 10星級プロダクトを発見、4モードで判断

3. /plan-eng-review
   → アーキテクチャ図、状態遷移、テストマトリクス

4. （Claude が実装）
   "Approve plan. Exit plan mode."

5. /review
   → AUTO-FIXED 2件、ASK 1件（レースコンディション）

6. /qa https://staging.myapp.com
   → 実ブラウザでフロー、バグ発見と自動修正

7. /ship
   → テスト42→51（新規9件）、PR作成

8. /land-and-deploy
   → マージ、CI、デプロイ、本番カナリ

9. /canary
   → 8ページを2分ごとに監視

8コマンド、エンドツーエンド。コピーライターではなくチームです。

パターンB：既存アプリの改善

1. /design-consultation → DESIGN.md を確立
2. /design-shotgun → 3バリアント生成、承認
3. /design-html → 動的レイアウトHTML生成
4. /design-review → 80項目監査、9個の修正
5. /ship

パターンC：バグ調査

1. /investigate → 自動 freeze、仮説テスト
2. /review → 関連バグも検出
3. /qa --regression baseline.json
4. /codex challenge → 敵対モードで追加検証
5. /ship

パターンD：セキュリティ重視のリリース前監査

1. /cso → OWASP Top 10 + STRIDE
2. /review → ロジック層のバグ
3. /codex challenge → 第二意見、敵対モード
4. /qa → 認証フローテスト
5. /ship --no-merge

パターンE：週次運用

月曜: /office-hours で新スプリント開始
火〜木: 通常のスプリントスキル
金曜: /retro → チームメトリクス、ストリーク、成長機会
週末: /retro global で複数プロジェクト横断

13. 設定とカスタマイズ

~/.gstack/config.yaml

# 自動アップグレード（セッション開始時にサイレント更新）
auto_upgrade: true

# テレメトリ（オプトイン）
telemetry: off

# 連続チェックポイントモード
checkpoint_mode: continuous  # off (default) | continuous
checkpoint_push: false

# Eng Review必須ゲートをスキップ
skip_eng_review: false

コマンドラインでの設定

gstack-config set telemetry off
gstack-config set auto_upgrade true
gstack-config set checkpoint_mode continuous
gstack-config set skip_eng_review true

プライバシーとテレメトリ

項目 値
デフォルト OFF
送信内容（OPT-IN時のみ） スキル名、所要時間、成功/失敗、gstackバージョン、OS
絶対に送信しない コード、ファイルパス、リポ名、ブランチ名、プロンプト、ユーザ生成コンテンツ

14. トラブルシューティング

スキルが表示されない

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

/browse が失敗する

cd ~/.claude/skills/gstack && bun install && bun run build

インストールが古い

/gstack-upgrade
# または
gstack-config set auto_upgrade true

コマンドを短くしたい

cd ~/.claude/skills/gstack && ./setup --no-prefix
# /gstack-qa → /qa に変わる

Windows ユーザー

  • Git Bash または WSL で動作
  • Node.js が必須（Bunに加えて）
  • bun と node 両方を PATH に通す

Claude がスキルを見つけられない

プロジェクトの CLAUDE.md に gstack セクションがあるか確認してください（セクション3参照）。

15. アンインストール

~/.claude/skills/gstack/bin/gstack-uninstall

# 設定と分析を保持
~/.claude/skills/gstack/bin/gstack-uninstall --keep-state

# 確認なしで強制
~/.claude/skills/gstack/bin/gstack-uninstall --force

アンインストールスクリプトは CLAUDE.md を編集しません。各プロジェクトで ## gstack セクションを手動削除してください。

16. 付録：voice入力での使い方

gstack スキルは voice-friendly な発火フレーズを持っています。AquaVoice、Whisperなどの音声入力ツールで自然に話せます：

あなたが話す 発火するスキル
「セキュリティチェックを走らせて」 /cso
「ウェブサイトをテストして」 /qa
「エンジニアリングレビューをやって」 /plan-eng-review
「オフィスアワー」 /office-hours
「気を付けて」「be careful」 /careful
「セカンドオピニオン」 /codex
「振り返り」 /retro
「探索」「調査」 /investigate

スラッシュコマンド名や略語を覚える必要なし。

まとめ：gstackを使い倒すためのチェックリスト

Week 1：基礎を固める

  • gstack をインストール（30秒）
  • /office-hours でアイデアを再定義
  • /plan-ceo-review でスコープを検討
  • /review を実装後に走らせる
  • /qa でステージングをテスト
  • /ship でPRを作成

Week 2：レビュー文化を確立

  • /autoplan で計画を自動レビュー
  • /codex でセカンドオピニオン
  • /cso でセキュリティ監査
  • /design-consultation で DESIGN.md を確立

Week 3：本番運用

  • /setup-deploy で /land-and-deploy を準備
  • /canary でポストデプロイ監視
  • /benchmark でパフォーマンスベースライン
  • /document-release でドキュメントを最新に

Week 4：チームと並列化

  • チームモード設定（./setup --team）
  • /setup-gbrain で記憶を永続化
  • Conductor で並列セッションを試す
  • /retro で週次振り返り

関連リソース

ドキュメント 内容
Skill Deep Dives 全スキルの哲学、例、ワークフロー
Builder Ethos Boil the Lake、Search Before Building
Using GBrain with GStack GBrain完全ガイド
Browser Reference /browse 完全コマンドリファレンス
Changelog 各バージョンの変更点

ライセンス：MIT。永久に無料。何かを作ろう。

フォーク版リポジトリ：daichitsuchiya39-creator/gstack オリジナル：garrytan/gstack

"I don't think I've typed like a line of code probably since December, basically." — Andrej Karpathy, No Priors podcast, March 2026

Share:
View all posts