この記事のポイント
- gstackのインストールから実際の利用開始まで、つまずきやすいポイントを含めて手順を紹介
/plan-ceo-review、/design-review、/review、/ship、/qa、/retroなど主要コマンドの実行結果を公開- 企画→設計→実装→レビュー→デザイン修正→追加機能→PR作成→QA→ふりかえりまで1セッションで完了した全記録
はじめに
前回の記事で、Y Combinator CEOが公開したClaude Code用スキルセット「gstack」の概要を紹介しました。
「面白そうだけど、実際どうなの？」「本当に開発が効率化されるの？」
そう思った方も多いのではないでしょうか。そこで今回は、実際にgstackを導入して、ブログ記事一覧のデモプロジェクト（Vanilla JS / HTML / CSS）で使ってみた体験をレポートします。
インストール手順と実際の画面
Step 1: gstackをcloneする
まず、ターミナルで以下のコマンドを実行します。
git clone https://github.com/garrytan/gstack ~/.claude/skills/gstackこれで ~/.claude/skills/gstack にスキルファイルがダウンロードされます。
Step 2: セットアップスクリプトを実行する
cd ~/.claude/skills/gstack
./setupセットアップスクリプトが実行されると、必要なファイルの配置とClaude Codeへのスキル登録が行われます。
Step 3: CLAUDE.mdに追記する
プロジェクトの CLAUDE.md に、gstackを使うことを記載します。これによりClaude Codeが各コマンドの存在を認識します。
## gstack
gstackスキルを使用する。以下のコマンドが利用可能:
- /plan-ceo-review: CEO視点の企画レビュー
- /plan-eng-review: エンジニアリング設計レビュー
- /review: パラノイアなコードレビュー
- /ship: 自動リリース（テスト→push→PR作成）
- /browse: ブラウザ自動操作QA
- /qa: 変更差分ベースの自動QA
- /retro: ふりかえりつまずきポイント
セットアップで1つ注意点があります。./setup を実行する前に、Claude Codeが既にインストールされていて、~/.claude/ ディレクトリが存在する必要があります。Claude Codeを一度も起動したことがない場合は、先に起動しておきましょう。
/plan-ceo-review を使ってみた
最初に試したのは /plan-ceo-review です。「ブログ記事の一覧ページにフィルタ機能を追加したい」というタスクに対して実行してみました。
入力した内容
/plan-ceo-review
ブログ記事の一覧ページに、カテゴリと年月でフィルタリングできる機能を追加したい実際の出力内容
まずシステム監査が走り、既存コードの状態（8記事、3カテゴリ、日付範囲3ヶ月分）を把握した上で、3つの実装アプローチが提示されました。
| アプローチ | 内容 | 評価 |
|---|---|---|
| A) シンプルドロップダウン | カテゴリと年月の2つのプルダウン。最小構成 | Completeness 5/10 |
| B) ピルボタン＋URL連動 | カテゴリはクリック可能なボタン、年月はドロップダウン。フィルタ状態がURLに保存される | Completeness 8/10 |
| C) フル検索バー | B + テキスト検索 + アクティブフィルタのタグ表示 | Completeness 10/10 |
推奨はB。URL連動は「ちゃんとしたプロダクト」感を出すのに効果的で、Aとほぼ同じ工数。
さらに「SCOPE EXPANSION」モードを選ぶと、5つの拡張提案が1つずつ個別に提示されました。
- フィルタ結果カウンター（「3件の記事」のリアルタイム表示）
- カードアニメーション（フィルタ切替時のfade-in）
- フィルタリセットボタン + 空状態の導線（0件時に「全記事を表示する」リンク）
- レスポンシブ対応（モバイルでのピル横スクロール）
- テストスイート（Vitestによるフィルタロジック単体テスト）
各提案に対して「A) このプランに追加」「B) TODOSに延期」「C) スキップ」の3択で選べます。結果、5件すべてを採択しました。
その後、10セクション（アーキテクチャ、エラーマップ、セキュリティ、データフロー、コード品質、テスト、パフォーマンス、観測性、デプロイ、デザイン）にわたるレビューが実行され、最終的にデザインドキュメント（docs/designs/blog-filter.md）とTODOS.md（テキスト検索P2、E2EテストP3）が自動生成されました。
感想
「フィルタ機能を付けたい」としか考えていなかったところに、3つの実装アプローチと5つの拡張提案が出てきたのは新鮮でした。特に「URL連動」や「空状態の導線」は、1人で考えているとつい後回しにしがちな部分です。提案ごとに個別承認なので、スコープが勝手に膨らむこともありません。
/plan-eng-review を使ってみた
CEO視点のレビューで方針が固まった後、/plan-eng-review を実行しました。
実際の出力内容
エンジニアリングマネージャー視点で、以下が整理されました。
| 観点 | 指摘内容 |
|---|---|
| スコープ | 5ファイル、新規クラス0。複雑度チェック通過 |
| 既存コード活用 | renderPosts、getCategoryLabel、empty stateをすべて再利用 |
| ファイル分離 | フィルタロジックをfilter.jsに分離してテスタビリティ確保 |
| fetchエラー | try-catch + res.okチェックでエラーハンドリング追加 |
| テストランナー | Vitestを採択（ESMネイティブ、設定簡単） |
最終的なアーキテクチャが確定しました。
src/js/filter.js ← 純粋関数（filterPosts, getCategoryLabel等）
src/js/app.js ← UI構築、イベント処理、URL連動
tests/filter.test.js ← filter.jsを直接importしてテスト感想
設計段階で「テストのためにファイルを分離すべきか」「テストランナーは何を使うか」まで議論できるのは助かります。実装に入る前に方針が固まっているので、迷いなくコードが書けました。
実装
/plan-eng-review で決まった設計に沿って実装しました。Claude Codeが設計通りにコードを書いてくれます。
filter.js: 純粋関数4つ（filterPosts, getCategoryLabel, getUniqueMonths, formatMonth）app.js: フィルタUI構築、イベント処理、URL連動（pushState/popstate）、エラーハンドリングstyle.css: ピルボタン、ドロップダウン、fade-inアニメーション、レスポンシブfilter.test.js: 23テスト
テスト結果: 23/23 パス。実装の所要時間は体感5分程度でした。
/design-review を使ってみた
実装後に /design-review を実行しました。ヘッドレスブラウザ（Playwright）でサイトを自動操作し、デザインを監査するコマンドです。
実際の出力内容
まず「First Impression（第一印象）」が出力されます。
サイトは「シンプルで機能的な技術ブログ」を伝えている。クリーンで読みやすい。
次にデザインシステムの自動抽出（フォント、カラーパレット、見出し階層、タッチターゲット）が行われ、レスポンシブ表示のスクリーンショット（モバイル/タブレット/デスクトップ）が撮影されました。
発見された問題4件：
| # | 問題 | 重要度 | 修正内容 |
|---|---|---|---|
| 1 | ピルボタンにfocus-visibleリングなし | High | outline: 2px solid 追加 |
| 2 | aria-pressed属性なし | Medium | ボタン切替時にaria-pressed連動 |
| 3 | 要約テキストが15.2px（16px未満） | Medium | font-size 1rem + max-width 65ch |
| 4 | 年月ドロップダウンにfocus-visibleなし | Medium | outline追加 |
各修正は1コミットずつ原子的にコミットされ、修正後に再度スクリーンショットで検証されました。
最終スコア: Design Score B+ / AI Slop Score A
感想
「focus-visible」や「aria-pressed」など、アクセシビリティの問題を自動で検出・修正してくれるのは強力です。フォントサイズが0.05rem（0.8px）だけ小さかった問題まで拾ってくれました。人間の目では気づきにくい部分です。
/review を使ってみた
テキスト検索機能を追加した後、featureブランチで /review を実行しました。
実際の出力内容
まずスコープドリフト検出が走ります。
Scope Check: CLEAN
Intent: テキスト検索機能を追加（TODOS.md P2）
Delivered: filterPostsにquery引数追加、検索UI、URL連動、テスト8件追加「意図通りの変更しかない」ことが確認されました。
次に2パスのレビュー:
- Pass 1 (CRITICAL): SQL安全性、レース条件、LLM信頼境界、Enum完全性 → 該当なし
- Pass 2 (INFORMATIONAL): 1件発見 → 検索inputのfont-size 0.95rem (15.2px) を1rem (16px) に自動修正
Pre-Landing Review: 1 issue (0 critical, 1 informational)
AUTO-FIXED:
- [src/css/style.css:89] Search input font-size 0.95rem (15.2px) → 1rem (16px)感想
/review は単なる「コードを読んでコメントする」レビューではなく、チェックリストに基づく構造的なレビューです。スコープドリフト検出（余計な変更が混ざっていないか）、TODOS.mdとのクロスリファレンス、ドキュメント鮮度チェックまで自動で行われます。問題が見つかった場合は自動修正（AUTO-FIX）か、ユーザーに判断を求める（ASK）かに分類されるのも良い設計です。
/ship を使ってみた
レビュー後に /ship を実行しました。
実行の流れ
/shipと入力するだけで、以下が自動実行されました。
- プリフライト: ブランチ確認、レビュー準備ダッシュボードを表示
- mainをマージ:
git fetch origin main && git merge origin/main - テスト実行: 31/31 パス
- テストカバレッジ監査: 8/8 新コードパスすべてにテストあり（100%）
- プリランディングレビュー: font-size自動修正済み、0件
- 検証ゲート: テスト再実行 31/31 パス（修正後の再検証）
- push:
git push -u origin <branch> - PR作成:
gh pr createでPR自動生成
出力されたPR
PRが自動作成されました。PR本文にはSummary、Test Coverage、Pre-Landing Review、Design Review、TODOSの各セクションが自動生成されています。
感想
「テスト → カバレッジ監査 → レビュー → 検証ゲート（テスト再実行） → push → PR作成」を1コマンドでやってくれるのは快適です。特に「検証ゲート」が良くて、レビューで自動修正が入った後にテストを再実行して安全を確認してくれます。PR本文の自動生成も、テスト結果やレビュー結果が構造化されているので、そのまま使えるクオリティでした。
/qa を使ってみた
PRをマージした後に /qa を実行しました。ヘッドレスブラウザで実際にサイトを操作してテストするコマンドです。
実際の出力内容
/qa はfeatureブランチ上で実行すると自動的にdiff-awareモードになり、変更したファイルから影響のあるページを推定してテストしてくれます。さらに、/plan-eng-review で作成したテストプランを自動検出して活用しました。
9つのテストが実行されました:
| # | テスト内容 | 結果 |
|---|---|---|
| 1 | テキスト検索「gstack」→ 1件表示 | PASS |
| 2 | 検索 + カテゴリ（AI + テック）→ 3件表示 | PASS |
| 3 | リセットボタンで検索クリア | PASS |
| 4 | URL復元（?q=Playwright&category=tech） | PASS |
| 5 | 空状態（検索0件 + リセットリンク表示） | PASS |
| 6 | 空状態リセットリンク → 全件復帰 | PASS |
| 7 | カテゴリフィルタ（insight → 3件） | PASS |
| 8 | 年月 + 検索URL（?month=2026-01&q=QA）→ 1件 | PASS |
| 9 | 不正URLパラメータ → エラーなしで処理 | PASS |
レスポンシブチェック（モバイル/タブレット/デスクトップ）、コンソールエラーチェックもすべてパス。
Health Score: 100/100
感想
手動でブラウザを開いて「カテゴリを切り替えて…」「URLをコピーして再アクセスして…」という確認を全部自動でやってくれます。特にURL復元テスト（パラメータ付きでアクセスしてフィルタが正しく復元されるか）は手動だと面倒な作業なので、自動化の価値が大きいです。Playwrightのセットアップも特に手間なく動きました。
/retro を使ってみた
一連の作業が終わった後に /retro を実行してみました。
実際の出力内容
git履歴から自動的にふりかえりが生成されました。
| 指標 | 値 |
|---|---|
| コミット数 | 9 |
| 追加行数 | +2,898 |
| 削除行数 | -284 |
| テスト比率 | 22% |
| AI支援コミット | 78% |
| アクティブセッション | 2（合計~30分） |
| 集中スコア | 78%（src/に集中） |
Ship of the Week: カテゴリ・年月フィルタ機能（2,183行）
よかった点:
- filterPostsを純粋関数として分離 → テキスト検索は15行の追加で実装できた
- 初日から31テストで100%カバレッジ
- 4つのアクセシビリティ修正を原子的コミットで対応
改善点:
- 最初のフィルタ機能をmain直コミットした（featureブランチを使うべきだった）
- VERSIONファイルがない（リリース追跡ができない）
- E2Eテストがまだない（TODOS.md P3）
感想
個人開発でふりかえりをやる習慣がなかったので、コミット履歴から自動生成されるのは良い仕組みです。「集中スコア」や「テスト比率」など、定量的な指標で自分の開発パターンを客観視できます。チーム開発なら、メンバーごとの分析や称賛・改善点も自動生成されます。
全体の流れ
今回は /plan-ceo-review から /retro まで、gstackのほぼすべてのコマンドを使いました。
| ステップ | コマンド |
|---|---|
| 1 | /plan-ceo-review — CEO視点の企画レビュー |
| 2 | /plan-eng-review — エンジニアリング設計レビュー |
| 3 | 実装 — フィルタ機能 + テスト23件 |
| 4 | /design-review — ビジュアルQA + 修正4件 |
| 5 | 実装 — テキスト検索機能 + テスト8件 |
| 6 | /review — コードレビュー |
| 7 | /ship — PR作成 + push |
| 8 | /qa — ブラウザ自動QA（9テスト） |
| 9 | /retro — ふりかえり |
企画→設計→実装→デザイン修正→追加機能→レビュー→PR作成→QA→ふりかえりまで、1つのセッションで完了しました。
最終成果物
- フィルタ機能: カテゴリピルボタン + 年月ドロップダウン + テキスト検索
- URL連動:
?category=tech&month=2026-03&q=AIでブックマーク・共有可能 - アクセシビリティ: aria-pressed、focus-visible、44px+タッチターゲット
- レスポンシブ: モバイル対応（ピル横スクロール）
- アニメーション: fade-in + prefers-reduced-motion対応
- テスト: 31件（Vitest）、100%パス
- QA Health Score: 100/100
- Design Score: B+ / AI Slop Score: A
- PR: 自動作成・マージ済み
使ってみて感じたメリットと注意点
メリット
| メリット | 詳細 |
|---|---|
| 拡張提案が新しい視点をくれる | /plan-ceo-review でURL連動や空状態の導線など、1人では後回しにしがちな改善案が出る |
| 設計→実装の接続がスムーズ | /plan-eng-review で決めたアーキテクチャに沿ってそのまま実装できる |
| アクセシビリティを自動検出 | /design-review でfocus-visible、aria-pressed、フォントサイズなどの問題を自動修正 |
| リリースが1コマンド | /ship でテスト→カバレッジ監査→レビュー→push→PR作成まで自動化 |
| QAも自動化 | /qa でブラウザ操作テスト。URLパラメータ復元など手動では面倒なテストも自動 |
| 提案ごとに個別承認 | スコープが勝手に膨らまない。採用/延期/スキップを1つずつ選べる |
注意点
| 注意点 | 対策 |
|---|---|
| コンテキストが長くなりがち | 1タスクごとに新しいセッションを開始する |
| 全コマンドを毎回使う必要はない | プロジェクトの規模に合わせて必要なものだけ使う |
/review はfeatureブランチが必要 | mainに直コミットしていると差分がなく実行できない |
/design-review は開発サーバー起動が必要 | npm run dev でサーバーを立ててから実行する |
おすすめの使い方パターン
すべてのコマンドを毎回使う必要はありません。プロジェクトの規模に合わせた使い分けがおすすめです。
個人の小規模プロジェクト
実装 → /review → 手動でpush/review だけでも十分価値があります。自分のコードを構造的にチェックしてくれるだけで品質が上がります。
中規模プロジェクト
/plan-eng-review → 実装 → /review → /ship設計レビューと自動リリースを加えるパターン。PR作成まで自動化されるので効率的です。
チーム開発・本番サービス
/plan-ceo-review → /plan-eng-review → 実装 → /design-review → /review → /ship → /qa → /retroフルコースで使うパターン。今回のハンズオンはまさにこの流れでした。
まとめ
| 項目 | 評価 |
|---|---|
| 導入の手軽さ | cloneとセットアップで数分。CLAUDE.mdへの追記も簡単 |
| 一番使えたコマンド | /ship（テスト→レビュー→PR作成の全自動化が快適） |
| 一番新鮮だったコマンド | /plan-ceo-review（拡張提案を個別承認で採用できる） |
| 意外と良かったコマンド | /design-review（アクセシビリティの自動検出・修正） |
| 総合的な所感 | 「AIをチームとして使う」が本当に体験できた |
gstackは「AIをチームとして使う」という発想を手軽に試せるスキルセットです。CEO、エンジニアリングマネージャー、デザイナー、QAエンジニアと、それぞれ別の視点でレビューしてくれるのが最大の特徴です。まずは /review から試してみて、自分のワークフローに合うコマンドを見つけていくのがおすすめです。
関連記事
AI導入でお困りですか？
「Claude Codeを使っているけど、もっと効率的な使い方を知りたい」「AI開発ツールの導入支援をしてほしい」
そんなご要望がありましたら、AI DARUMAにご相談ください。開発ワークフローへのAI導入を実践的にお手伝いします。
〒723-0062 広島県三原市本町 1丁目7-29 2階 コワーキングスペースarica内