2026年3月、Y Combinator CEO の Garry Tan 氏が Claude Code 用のカスタムスキル集「gstack」を MIT ライセンスで無料公開しました。公開から48時間で GitHub スター数が10,000を超え、記事執筆時点で49,000超に達しています。
Tan 氏は X（旧 Twitter）でこう述べています。「過去7日間で1日平均17,000行のコードを書いている。35%はテストコード。15セッションの並列実行でこれを実現した」。この数字の是非は別として、gstack が単なるコーディング補助ではなく、開発フロー全体を自動化しようとするツールであることは確かです。
gstack は26本のスキルが「Think → Plan → Build → Review → Test → Ship → Reflect」というスプリントサイクルに沿って連鎖する設計です。この記事では全スキルの詳細、実際の導入方法、設計思想の解説まで体系的にまとめます。Claude Code の基本的な使い方やClaude Code Skills の基礎は別記事で解説しているため、本記事は gstack 固有の内容に集中します。
スター数：49,000超（2026年3月時点）／フォーク数：6,200超
gstackとは何か：スプリント型AIエンジニアリングチーム
gstack を一言で表すと「Claude Code を複数の専門家ロールが連携するチームとして機能させるためのスキル集」です。
Claude Code Skills の仕組み自体は誰でも自由に設計できますが、「何を作るか」から「本番にデプロイするか」まで一貫したワークフローとして設計されたスキルセットは珍しく、それが gstack の最大の特徴です。
設計の3つの柱
| 柱 | 内容 | 具体例 |
|---|---|---|
| スキルの連鎖 | 各スキルの出力がファイルに保存され、後続スキルがそれを参照する | /plan-eng-review のテスト計画を /qa が自動参照 |
| 役割の分離 | CEO視点・エンジニア視点・デザイナー視点・セキュリティ視点が別スキルに分離 | CEO視点 (/plan-ceo-review) とエンジニア視点 (/plan-eng-review) は独立 |
| 安全性の組み込み | セーフティガードが開発フローに最初から組み込まれている | /careful が rm -rf の前に警告を挿入 |
「ただのプロンプト集」vs「完成したワークフロー」
gstack に対する最も多い批判は「Markdown ファイルを大げさに宣伝しているだけ」というものです。技術的な新規性という点ではこの批判は正しい側面があります。
しかしスキルの設計には実際に相当な時間がかかります。「どの情報をどの順番でClaudeに渡すか」「スキル間でどうデータを引き継ぐか」「安全に自律実行させるには何を制限するか」——これらを自分で設計するコストをゼロにして、即使えるようにしたのが gstack の価値です。自分でスキルを設計する際の参考実装としても価値があります。
インストール方法
要件
| ツール | 必要性 | 備考 |
|---|---|---|
| Claude Code | 必須 | Anthropic API または Amazon Bedrock 経由で使用 |
| Git | 必須 | リポジトリのクローンとスキルの取得に使用 |
| Bun v1.0+ | 必須 | ブラウザデーモン（/browse）のビルドに使用。bun.sh から導入 |
| Node.js | Windows のみ必要 | Linux・macOS では不要 |
グローバルインストール（自分だけが使う場合）
約30秒で完了します。グローバルインストールすると自分のすべてのプロジェクトで gstack が使えるようになります。
git clone https://github.com/garrytan/gstack.git ~/.claude/skills/gstack \ && cd ~/.claude/skills/gstack \ && ./setup
インストール後、~/.claude/CLAUDE.md に gstack セクションが追加され、利用可能なスキルが一覧化されます。Claude Code を起動すると /office-hours・/review などのスラッシュコマンドが使えるようになります。
リポジトリインストール（チームで共有する場合）
プロジェクトのリポジトリに gstack を追加することで、チームメンバー全員が同じスキルセットを使えるようになります。
# プロジェクトのルートディレクトリで実行 cp -Rf ~/.claude/skills/gstack .claude/skills/gstack \ && rm -rf .claude/skills/gstack/.git \ && cd .claude/skills/gstack \ && ./setup
.git ディレクトリを削除してからコピーすることで、gstack の Git ヒストリーがプロジェクトのヒストリーと混在しないようにしています。
インストール後の CLAUDE.md の構成
インストールが完了すると、CLAUDE.md に以下のような gstack セクションが追加されます。
# gstack Available skills (use /skillname to invoke): ## Planning - /office-hours - Start here. YC-style problem interrogation - /plan-ceo-review - CEO-level scope + architecture review - /plan-eng-review - Engineering architecture + test planning - /design-consultation - Full design system from scratch - /plan-design-review - Score current design 0-10 per dimension ## Implementation & Verification - /review - Pre-landing code review (no changes) - /investigate - Root cause analysis with 3-strike rule - /design-review - Live site visual audit (80-point checklist) - /qa - Quality assurance (4 modes) - /browse - Persistent Chromium daemon for testing ## Release - /ship - Create PR (no confirmation required) - /land-and-deploy - Merge + deploy + health check - /canary - Post-deploy monitoring (10 min default) - /benchmark - Performance metrics (TTFB, FCP, LCP) - /document-release - Update README, ARCHITECTURE, CHANGELOG - /retro - Weekly retrospective ## Security & Safety - /cso - Security audit (14-phase methodology) - /careful - Warn before destructive commands - /freeze [path] - Block writes outside specified path - /guard - /careful + /freeze combined
アップグレード
# Claude Code 内で実行 /gstack-upgrade
エスカレートするスヌーズ機能があり、アップグレードを先送りしていると通知間隔が24h→48h→1週間と広がります。
全26スキルの一覧
公開当初は「18のロール＋7のツール」と紹介されていましたが、現在は26本以上のスキルが公開されています。
| カテゴリ | スキル名 | 主な機能 |
|---|---|---|
| プランニング（5本） | /office-hours | YCスタイルでプロダクトを根本から問い直す。コードは一切書かない |
| /plan-ceo-review | CEO視点で10項目・4スコープモードでレビュー | |
| /plan-eng-review | エンジニア視点でアーキテクチャ・テスト計画を策定 | |
| /plan-design-review | デザインを0-10で評価し卓越さの基準を提示 | |
| /design-consultation | ゼロからデザインシステム（タイポ・カラー・コンポーネント）を構築 | |
| 実装・検証（6本） | /review | PRレビュー（コード変更なし）。差分50/200行で検証強度を自動選択 |
| /investigate | 調査なし修正なし原則。3ストライクでエスカレーション | |
| /design-review | ライブサイト80項目視覚監査＋AIスラップスコア | |
| /qa | 4モードの品質保証。WTF-likelihood で自動停止 | |
| /qa-only | コード変更なしのバグレポートのみ生成 | |
| /browse | 永続Chromiumデーモン。初回以降100〜200ms で応答 | |
| リリース（8本） | /ship | 確認不要でベースマージ→テスト→CHANGELOG→PR作成 |
| /land-and-deploy | マージ→本番デプロイ→ヘルスチェック（プラットフォーム自動検出） | |
| /canary | デプロイ後10分間の自動監視（ベースライン比較方式） | |
| /benchmark | TTFB・FCP・LCP等の計測。A-Fのパフォーマンスグレード | |
| /document-release | README・ARCHITECTURE・CHANGELOG を自動更新 | |
| /codex | OpenAI Codexによるセカンドオピニオン（Review・Challenge・Consult） | |
| /retro | 週次振り返り。複数リポジトリ横断・ツイート可能サマリー生成 | |
| /setup-deploy | デプロイ設定の初期化 | |
| セキュリティ（1本） | /cso | 14フェーズ監査。Daily（8/10閾値）とComprehensive（2/10閾値） |
| セーフティ（4本） | /careful | 危険コマンド（rm -rf・DROP TABLE等）の前に警告 |
| /freeze [path] | 指定ディレクトリ外へのEdit・Writeをブロック | |
| /guard | /careful + /freeze の複合（最大安全モード） | |
| /unfreeze | /freeze の解除 | |
| ユーティリティ（2本） | /setup-browser-cookies | Chrome・Arc・Brave・Edgeのセッションをインポート |
| /gstack-upgrade | 自動アップグレード（エスカレートするスヌーズ付き） |
スプリント型ワークフロー：Think → Plan → Build → Review → Test → Ship → Reflect
gstack の設計の核心は、各スキルがファイルを介して連鎖することです。前のスキルが ~/.gstack/projects/ や .gstack/ に保存した情報を、後続スキルが自動的に参照します。
| 段階 | スキル | やること | 出力先 |
|---|---|---|---|
| Think | /office-hours | 「何を作るか」を根本から問い直し、具体的な宿題を定義 | ~/.gstack/projects/ |
| Plan | /plan-ceo-review + /plan-eng-review | CEOとエンジニア両視点でアーキテクチャ・テスト計画を策定 | ~/.gstack/projects/{slug}/ |
| Build | （Claude Code 通常機能） | コードを実装。gstack は監視しない | Git diff |
| Review | /review → /codex（任意） | PRをコード変更なしでレビュー。CodexのセカンドオピニオンはMINUS側から検証 | インラインコメント・修正提案 |
| Test | /qa → /design-review（UIあり） | テスト計画に基づいてQA実行。UIがあれば視覚監査も | .gstack/qa-reports/ |
| Ship | /ship → /land-and-deploy → /canary | PR作成→マージ→デプロイ→10分間監視 | GitHub PR・デプロイログ |
| Reflect | /retro | 週次で改善点を振り返り。次のスプリントの計画材料 | 週次レポート |
1機能30分・15本並列の実態
Tan 氏が主張する「1機能30分・15本並列実行」は、Conductor（@conductor_build）という外部のマルチセッション管理ツールと組み合わせて実現しています。Claude Code 単体の機能ではありません。
Conductor は複数の Claude Code セッションを管理するツールで、異なる機能を別々のワークスペースで同時進行させます。各セッションは独立しているため、1つが長引いても他に影響しません。
プランニング層の詳細
/office-hours：YCスタイルで問いを問い直す
“ここから始めよ”が SKILL.md に書かれている gstack の起点です。コードを一切生成せず、「そもそも何を作るべきか」を整理することだけに集中します。
2つのモードがあります。
| モード | 特徴 | 向いている場面 |
|---|---|---|
| Startup モード | YC流の6つの強制質問（課題・顧客・解決策・なぜ今・競合・ビジネスモデル）。1問ずつ回答を待ってから次の質問に進む | 新規プロダクト・機能の立ち上げ。投資家に説明できるレベルで整理したいとき |
| Builder モード | 楽しさ・創造性優先。制約を最小化して自由にアイデアを展開 | 個人プロジェクト・実験的な機能・プロトタイプ |
最後に「具体的な宿題」を出します。「コードを書け」ではなく、次に取るべきアクションを明確にする形式です。
SKILL.md には YC の投資哲学が反映されています。「インタレストは需要ではない（waitlist への登録・いいねは、実際の行動・支払いとは別物）」という原則が組み込まれており、ユーザーの本質的な行動を問い直す設計になっています。
/plan-ceo-review：4スコープモードと10項目レビュー
プロダクトを経営者の視点で評価するスキルです。まず現在のフェーズに合ったスコープモードを選び、そのモードに対応した10項目のレビューを実行します。
| スコープモード | 意味 | 使うタイミング |
|---|---|---|
| EXPANSION | 積極的に機能・品質を拡張する局面 | 初期開発・新機能追加期・成長フェーズ |
| SELECTIVE EXPANSION | 優先度の高い改善のみを選択する局面 | 中期の安定成長期 |
| HOLD | 品質維持・バグ修正のみの局面 | リリース直前・安定稼働期・フリーズ期間 |
| REDUCTION | 機能削除・シンプル化を進める局面 | リファクタリング・技術負債解消・機能廃止 |
10項目のレビュー対象：アーキテクチャ・エラーマップ・セキュリティ・データフロー・コード品質・テスト・パフォーマンス・可観測性・デプロイ・長期軌跡。
特徴的なのはサブエージェントによる「敵対的レビュー」（最大3イテレーション）です。自分の設計を擁護する視点だけでなく、意図的に批判的な視点でレビューを行うことで、盲点を発見します。レビュー結果は CEO プランドキュメントとして ~/.gstack/projects/ に保存されます。
/plan-eng-review：スコープチャレンジ機能付きの設計検証
エンジニアリングマネージャーの視点で設計を検証するスキルです。
スコープチャレンジ機能が重要な特徴です。変更ファイルが8ファイルを超える場合、スコープ削減のレビューが自動で発動します。「大きすぎる変更を一度に入れていないか」をシステムが警告する設計思想です。
- 鉄の掟：既存動作を変更したら必ず回帰テストを追加
- テスト計画の自動引き継ぎ：テスト計画を
~/.gstack/projects/{slug}/に保存し、/qaスキルがそれを参照して実行 PROACTIVE=false設定で自動起動を無効化可能
実装・検証層の詳細
/review：差分サイズで4段階に自動スケーリングするレビュー
/review はコードを変更せず、レビューのみを行うスキルです。PRをマージする前に実行する想定で設計されています。
差分の大きさに応じて、検証の深さが自動で変わります。
| 差分サイズ | 実行される検証 | 理由 |
|---|---|---|
| 50行未満 | 検証スキップ | 小さすぎる変更にフルレビューは過剰 |
| 50〜199行 | Codex または Claude サブエージェント（1パス） | 標準的な変更に適切な深度 |
| 200行以上 | 4パス全実行（下記参照） | 大きな変更には複数の独立した視点が必要 |
200行以上の場合の4パス：
- Codex 構造レビュー：コード構造・ロジックの整合性チェック
- Claude 敵対的レビュー：意図的に批判的な視点でバグ・設計問題を探す
- Codex 敵対的レビュー：Codex の別視点から同様に検証
- 統合レビュー：3つの結果を統合し、矛盾を解消して最終レポートを作成
検出対象：SQL インジェクション・LLM トラスト境界違反（外部入力をそのまま LLM に渡していないか）・競合状態。発見した問題は AUTO-FIX（自動修正）と ASK（承認後修正）に自動分類されます。
/design-review：AIスラップを数値化する視覚監査
「AIスラップ（AI Slap）」とは、AI が生成しがちな凡庸・画一的なデザインパターンのことです。gstack では独自の概念として定義しており、/design-review がデザインスコア（A〜F）とAIスラップスコア（A〜F）の二軸で評価します。
AIスラップのブラックリストに含まれる典型パターン：
- 紫〜インディゴのグラデーション背景（最も多く見られる AI スラップ）
- 「Features」セクションの3カラムグリッド（機能を横並びで3つ並べる）
- すべてのセクションをページ中央寄せ
- 装飾的な絵文字アイコンの多用
- ヒーロー見出しに「Revolutionize」「Transform」「Unleash」などの誇張語
- 過剰な丸角・大きな影・発光（グロー）エフェクト
- セクション背景の濃淡交互（白→薄グレー→白→薄グレー）
- CTA ボタンの「Get Started for Free」
80項目のチェックリストはさらに細かく分類されており、階層・タイポグラフィ・カラー・スペーシング・インタラクション・レスポンシブ・モーション・コンテンツ品質・AIスラップ検出・パフォーマンス視覚の10カテゴリをカバーします。
修正は1修正1コミット方式（style(design): FINDING-NNN形式）で行い、変更の追跡が容易になっています。
/qa：WTF-likelihood で自律暴走を防ぐ
4つのモードで実行できます。
| モード | 対象範囲 | 用途 |
|---|---|---|
| Quick | 重大なバグのみ | 時間が限られているリリース直前 |
| Standard（デフォルト） | 一般的な品質チェック | 通常の開発サイクル |
| Exhaustive | 全項目を徹底検証 | 重要リリース前の完全検証 |
| Regression | 変更影響ページ・ファイルのみ | フィーチャーブランチでの差分テスト |
WTF-likelihood（混乱可能性）は gstack 独自の安全機能です。以下の条件で自動停止し、ユーザーに確認を求めます。
- 50件の修正を行った後
- 信頼度が20%未満になった場合（「これが正しい修正かどうか自信がない」状態）
この機能は「AI が何かおかしいと感じているのに修正を続けて事態を悪化させる」という典型的な自律実行の暴走を防ぐための設計です。テスト結果は .gstack/qa-reports/ に保存されます。
/investigate：3ストライクルールの根本原因分析
「何が起きているか分からないまま修正を試みない」という原則を徹底したスキルです。バグの原因が不明な場合に使います。
| フェーズ | やること |
|---|---|
| 1. 調査 | エラーログ・スタックトレース・最近の変更を収集。仮説を立てる前にデータを集める |
| 2. パターン分析 | 収集したデータからパターンを見つける。「この種類のエラーが繰り返されている」などを特定 |
| 3. 仮説検証 | 最も可能性が高い根本原因を1つ選び、テストで検証する |
| 4. 実装 | 検証した根本原因に対してのみ修正を実施。最小限の変更で対処 |
3回修正を試みても解決しない場合はエスカレーション（ユーザーへの報告・停止）します。また修正に5ファイル以上の変更が必要な場合は「爆発半径チェック」が発動し、変更範囲が広すぎないか確認を取ります。
リリース層の詳細
/ship：「言ったらやる」方式のPR作成
「/ship と言ったらやれ」という設計コンセプトのスキルです。基本的に途中確認なしで進みますが、以下の3条件では自動停止します。
| 停止条件 | 理由 |
|---|---|
| マージコンフリクトが発生した場合 | 自動解決すると意図しない変更が混入する可能性があるため |
| このリリースで自分が導入したテストが失敗した場合 | 自分で追加したテストが通らないのはバグがあるサイン |
| PATCH 超えのバージョン変更が必要な場合 | MINOR・MAJOR のバンプは人間の判断が必要 |
処理フロー：ベースブランチへのマージ→テスト実行→カバレッジ監査→バージョンバンプ→CHANGELOG 自動生成→PR作成。
/land-and-deploy：唯一の確認ゲートはマージ直前
/ship で作成した PR をマージして本番にデプロイするスキルです。GitHub Actions・Fly.io・Render・Vercel などのプラットフォームを自動検出してデプロイコマンドを選びます。
処理全体の中で唯一の強制確認ゲートはマージ直前の Readiness Check のみです。全チェックを通過した後、「本当にマージしてよいか」という最終確認だけ人間に求めます。デプロイ失敗時はリバートコミットを自動提案します。
/canary：ベースライン比較方式の10分監視
デプロイ後10分間、継続的にメトリクスを監視します。一般的な監視と異なる点はベースライン比較方式を採用していることです。
「エラー率5%を超えたらアラート」のような絶対閾値ではなく、「デプロイ前と比べて何%増えたか」で判断します。これにより、もともとエラー率が高いサービスでの誤アラートを防ぎつつ、デプロイによって引き起こされた問題だけを検出できます。
2回連続で検出されたパターンのみアラートというフィルターもあり、一時的なスパイクを問題として扱いません。
/codex：OpenAI Codex によるセカンドオピニオン
Claude だけでなく OpenAI Codex からもレビューを受けることで、1つの AI の盲点をカバーするスキルです。
| モード | 動作 | 用途 |
|---|---|---|
| Review | pass/fail の判定を出す | 最終チェックとしての合否判定 |
| Challenge | 意図的にバグ・セキュリティ問題を探す敵対的テスト | 重要な機能のリリース前 |
| Consult | 自由質問形式 | アーキテクチャの相談・設計のセカンドオピニオン |
Codex のペルソナは「200 IQ の自閉症開発者：直接的・簡潔・技術的に正確」と定義されており、曖昧な表現や回り道のない評価を返す設計です。Claude と Codex 両方が実行した場合、差異を比較分析して統合した見解を出します。
/retro：AI共著コミットも追跡する週次振り返り
デフォルトで直近7日間の Git ヒストリーを分析し、週次の振り返りを行います。
- グローバルモード：複数リポジトリを横断して一括分析
- AI共著コミットの追跡：Anthropic ノーリプライ等の AI 共著者を「AI-assisted commits」として別カウント
- ツイート可能なサマリー：1行に収まる週次サマリーを生成（X投稿用に最適化）
- 24h・14d・30d など分析期間をカスタマイズ可能
セキュリティ監査とセーフティガード
/cso：Chief Security Officer の14フェーズ監査
「インフラファースト」の方針で、まず git ヒストリーへの秘密鍵混入・サプライチェーンリスク・CI/CD パイプラインの脆弱性を探します。
2つのモードがあります：
- Daily モード：信頼度 8/10 以上の問題のみ報告。日常的なセキュリティチェックに使用
- Comprehensive モード：信頼度 2/10 以上（可能性のあるすべて）を報告。重要リリース前の完全監査に使用
発見事項にはすべて攻撃の再現ステップバイステップが含まれます。「どんな攻撃シナリオが成立するか」を具体的に記述することで、リスクの優先度を正確に判断できます。監査レポートは .gstack/security-reports/ に保存されます。
セーフティガード：3段階で制御する安全設計
/careful・/freeze・/guard は Claude Code の Hooks 機能（PreToolUse フック）を使って実装されています。スキルを呼び出すと CLAUDE.md に設定が書き込まれ、以降の操作に常時適用されます。
| スキル | 仕組み | 制限されるもの | 制限されないもの |
|---|---|---|---|
| /careful | PreToolUse フックで危険コマンドを検出し permissionDecision: "ask" を返す |
rm -rf・DROP TABLE・git push –force・kubectl delete 等 | node_modules・.next・dist などビルドアーティファクトの削除は警告なし |
| /freeze [path] | 指定パス外への Edit・Write をブロック | 指定外ディレクトリへのファイル書き込み・編集 | Read・Bash・Glob・Grep（読み取り・実行系）は影響なし |
| /guard | /careful + /freeze の複合適用 | 上記すべての組み合わせ | 同上 |
技術的な実装の特徴
なぜ Bun を採用しているか
gstack のブラウザデーモン（/browse が使う Chromium 管理機能）は Bun で実装されています。ARCHITECTURE.md では Node.js ではなく Bun を選んだ理由が明示されています。
| 特徴 | 詳細 | Node.js との違い |
|---|---|---|
| コンパイル済みバイナリ | 約58MB・依存関係なし | Node.js は npm install が必要。Bun は単一バイナリで配布可能 |
| ネイティブ SQLite | ネイティブアドオンなしで動作 | Node.js の better-sqlite3 はネイティブビルドが必要で CI/CD で失敗しやすい |
| ネイティブ TypeScript | 開発時はソース直実行・デプロイ時はコンパイル | Node.js は tsx・ts-node 等の追加ツールが必要 |
/browse の永続デーモン設計
/browse は毎回 Chromium を起動せず、永続デーモンを使い回す設計です。初回起動後は100〜200ms でコマンドに応答します。
| 設計項目 | 内容 |
|---|---|
| ポート管理 | ランダムポート（10,000〜60,000）を自動選択。複数インスタンスの競合を防止 |
| 状態保存 | .gstack/browse.json に PID・ポート・ベアラートークン・バージョンを保存（パーミッション 0o600） |
| 自動再起動 | バージョン変更時にデーモンを自動再起動 |
| セキュリティ | localhost バインドのみ・ベアラートークン認証・実 DB のコピーを使用（実ブラウザのクッキーには書き込まない） |
| 要素参照 | CSS セレクタではなく ARIA アクセシビリティツリーの @ref 方式で要素を参照 |
テレメトリの設計（デフォルト OFF）
gstack にはオプトインのテレメトリがあります。公開時 Hacker News で「YC が投資先の構築内容を把握するための手段ではないか」という懸念が上がりましたが、Tan 氏はデフォルト OFF・コード収集なしを公言しています。
| 収集する情報 | 収集しない情報 |
|---|---|
| スキル名・実行時間・成功/失敗 | ソースコード・ファイルパス・ブランチ名 |
| gstack バージョン・OS 種別 | プロンプト内容・ユーザー名・組織名 |
バックエンドは Supabase（行レベルセキュリティ）で、ソースコードが公開されているため自分で確認できます。
テスト基盤の3層構造
gstack 自体のテスト基盤も興味深い設計です。
| Tier | 内容 | コスト・時間 |
|---|---|---|
| Tier 1：静的テスト | コマンドのパース・SKILL.md の構文チェック | 無料・5秒以内 |
| Tier 2：E2E テスト | 実際の Claude Code セッションを使ったエンドツーエンドテスト | 約 $3.85・約20分 |
| Tier 3：LLM-as-judge | LLM がスキルの出力品質を採点 | 約 $0.15・約30秒 |
批判と、それでも使う価値がある理由
gstack は公開と同時に大きな反響を得た一方で、批判も多くありました。フラットに整理します。
| 批判 | Tan氏・コミュニティの反応 | 筆者の見解 |
|---|---|---|
| 「ただの Markdown プロンプト集に過ぎない」 | 「使ってから判断してほしい。お金返せないけどそもそも無料」 | Markdown であることは事実。ただし設計の完成度（スキル連鎖・安全設計）は別の話。参考実装として価値がある |
| 「YC CEO という地位が過剰な注目を生んだ」 | （直接反論なし） | 公平な批判。技術的新規性は低い。ただし注目度と実用性は分けて評価すべき |
| 「1日1万〜2万行は誇張・非現実的」 | 「35%はテスト。15並列セッションで実現。Conductorとの組み合わせ」 | 生成行数より品質の議論が重要。並列化ツールの詳細は別途確認が必要 |
| 「テレメトリが怪しい」 | 「デフォルト OFF・コード収集なし。ソースを確認してほしい」 | 懸念は正当。ソースが公開されているため自分で確認できる点は評価できる |
| 「自律実行が暴走した報告がある」 | 「/careful・/freeze を使えば防げる。Claude Code の設定の問題」 | WTF-likelihood・3ストライクルール等の安全機能を理解して使うことが重要 |
スキルの設計には実際に相当な時間がかかります。gstack の価値はその設計コストをゼロにして即使えることと、設計のお手本として参照できることの2点です。
導入の実践的なヒント
まず試すべきスキル3本
すべてのスキルを一度に使おうとせず、まずは以下の3本から始めるのが現実的です。
| スキル | 推奨理由 | 期待できる効果 |
|---|---|---|
| /careful | インストールするだけで危険操作に警告が入る。副作用なし | rm -rf などのミスを防止。実行コストほぼゼロ |
| /review | コードを変更しないためリスクなし。PR前のセーフティネット | PRの品質チェックが自動化。SQL注入等の見落としを発見 |
| /office-hours | コードを一切書かない安全なスキル。思考整理に使える | 「作る前に考える」習慣がつく。過剰実装を防げる |
チームで導入する際の注意点
- CLAUDE.md に記載：リポジトリの CLAUDE.md に gstack スキルの一覧と使い方を記載することで、チームメンバーが同じコンテキストを持てる。Skills設計ガイド参照
- テレメトリの確認：チームで使う場合は全員がテレメトリ設定を理解・同意してから導入する
- /freeze で重要ファイルを保護：本番設定・認証情報のディレクトリを freeze することで誤編集リスクを軽減
- カスタマイズ方法：gstack の SKILL.md は MIT ライセンスで自由改変可能。リポジトリにコピーしてから .git を削除した上で編集することで、アップグレード時の上書きを防げる
既存のスキルと組み合わせる
gstack は自分が持っているカスタムスキルと共存できます。Skills改善サイクルで紹介している「NG/OKパターン蓄積」や「参照ファイルへの知識逃がし」の考え方を gstack のスキルに追加することで、プロジェクト固有のルールを組み込めます。
よくある質問
まとめ
gstack は Claude Code を「個人アシスタント」から「スプリント型 AI エンジニアリングチーム」に変えるスキル集です。
| カテゴリ | スキル数 | 主なスキル |
|---|---|---|
| プランニング | 5本 | /office-hours・/plan-ceo-review・/plan-eng-review |
| 実装・検証 | 6本 | /review・/design-review・/qa・/investigate |
| リリース | 8本 | /ship・/land-and-deploy・/canary・/codex・/retro |
| セキュリティ | 1本 | /cso（14フェーズ監査） |
| セーフティ | 4本 | /careful・/freeze・/guard・/unfreeze |
| ユーティリティ | 2本 | /setup-browser-cookies・/gstack-upgrade |
設計思想として特に注目すべきは、スキルの連鎖（出力をファイルで引き継ぐ）・WTF-likelihood による自動停止・AIスラップ検出・Hooks を使ったセーフティガードの4点です。
まず /careful だけインストールして試すところから始めてください。副作用なしで危険操作の防止だけを得られます。その後 /review・/office-hours と順番に試しながら、自分のワークフローに合うスキルを見極めていくのが現実的です。gstack の設計からスキルの書き方を学び、プロジェクト固有のカスタマイズに活かすことが長期的な活用の形です。Claude Code Skills入門・Skills設計ガイド・Skills改善サイクルも合わせて参照してください。
