実際の開発シナリオ：新機能から production までの Gstack 完全ワークフロー

前の 5 記事では Gstack の各 skill を個別に紹介しました——でも読み終わっても、まだこんな疑問があるかもしれません：

「これらの skill は実際どうつなげて使うの？」

/plan-ceo-review がプロダクト意思決定を問い、/review が production レベルのバグを探すことを知っているだけでは不十分です——実際の開発サイクルで、各 skill がいつ介入するのか、実行後に何をするのかを知る必要があります。

この記事では具体的なシナリオを使って完全なフローをデモします。

シナリオ設定

あなたが SaaS ツールを作っていて、新機能を追加したいとします：ユーザーが複数のレポートを 1 つの PDF にまとめてエクスポートできる機能。

10 数人のユーザーフィードバックからの要求で、高優先度だと判断しています——でもまだコードには手をつけていません。

ステップ 1：`/plan-ceo-review`——まず作る価値があるかを問う

Claude Code を開いて入力します：

/plan-ceo-review

「レポートを合わせて PDF にエクスポート」する機能を追加したいと思っています。ユーザーが複数のレポートを選んで、システムが 1 つの PDF に統合してダウンロードできるようにします。
約 15 人のユーザーフィードバックからの要求で、定期的にクライアントにレポートを渡す必要がある consultant タイプのユーザーが主体です。

Gstack の CEO モードはいくつかの質問をしてきます：

この 15 人のユーザーは今どうやってこの問題を解決しているか？自分で手動で PDF を統合しているか？他のツールを使っているか？
「統合エクスポート」は彼らの解決策か、それとも彼らの問題か？本当の痛みは「クライアントにレポートを渡すのが面倒」ということではないか？
「統合エクスポート」以外に、もっと根本的な解決策はないか——例えばレポートに直接「共有リンク」をクライアントに送れる機能を作るとか？
統合 PDF の要件が本当に成立するとして、統合順序、レポートカバー、透かしは v1 でやるのか、まず最もシンプルなバージョンを出すのか？

これらの質問は、作業開始前に 1 つのことを確認させてくれます：あなたはユーザーの本当の問題を解決しているのか、あなたが思い込んでいる問題を解決しているのかを。

実行後に確認できたとします：PDF 統合は確かに彼らのコアニーズで、v1 はまず最もシンプルなバージョン（レポートを選択して統合ダウンロード）にして、高度な機能は後で追加する。

ステップ 2：`/plan-eng-review`——「何をするか」を「どうやれば正しいか」に変換する

意思決定が固まったら、エンジニアモードに切り替えます：

/plan-eng-review

機能確認：ユーザーは dashboard で複数のレポートをチェック（最大 10 個）し、「統合エクスポート」をクリックするとシステムがバックグラウンドで統合し、完了後にユーザーに通知してダウンロードできるようにする。
ユーザーの各レポートは平均 5-20 ページ、最大 1 つで 50 ページ。
バックエンドは Node.js + PostgreSQL で、レポートは S3 に保存されている。

Gstack のエンジニアモードが出力します：

シーケンス図——ユーザートリガー → バックエンドがリクエストを受信 → バックグラウンドジョブ起動 → S3 から各レポートを取得 → PDF を統合 → S3 に保存 → ユーザーに通知。図には非同期境界が描かれます。

エッジケースリスト：

統合中に 1 つのレポートの S3 URL が無効になったらどうするか？
ユーザーがジョブ完了前に再度トリガーしたらどうなるか？
統合後の PDF はどれくらい保存するか？クリーンアップ機能はあるか？
10 のレポートの統合にどれくらいの時間がかかるか？タイムアウトは何秒に設定するか？

テストマトリクス：

Unit test：PDF 統合ロジック
Integration test：バックグラウンドジョブの完全フロー
E2E：ユーザーがレポートを選択してダウンロードするまでの完全パス

この出力が作業開始前のアーキテクチャ設計ドキュメントになります。これを持ってコーディングを始め、問題があったら参照すれば、Claude に「どう書けばいいか」を聞き続けるより遥かにクリアです。

ステップ 3：実装

このフェーズで Gstack は退場し、あなた（と Claude）がコードを書きます。

Claude Code を使って /plan-eng-review の設計に従って実装します。技術的な問題があれば引き続き対話できますが、特定の Gstack skill を使う必要はありません——このフェーズは純粋な実装です。

書き終わったら確認します：

コア機能が動作する
基本的な unit test が書かれている
ローカルでテスト済み、明らかな問題はない

ステップ 4：`/review`——CI は通るが production でクラッシュする問題を探す

/review

他に説明を加える必要はありません。Gstack が git diff を読んで、今回の変更が引き起こした問題を探します。

今回見つかったとします：

Critical：PDF 統合は並行リクエスト下で race condition があります——ユーザーが素早く 2 回クリックすると、2 つのジョブがトリガーされ、重複した費用と結果が発生する可能性があります
High：S3 の presigned URL はバックグラウンドジョブが 1 時間を超えると期限切れになりますが、タイムアウトが 2 時間に設定されています
Medium：統合後の PDF にクリーンアップ機能がなく、S3 のコストが増え続けます

Critical と High を修正し、Medium は次のスプリントで処理するイシューを開きます。

ステップ 5：`/qa`——AI に本物のブラウザで機能をテストさせる

/qa

Gstack が git diff を分析し、影響を受けたページを特定します——主に dashboard のレポートリストページとエクスポートステータスページ——そしてブラウザでテストします：

3 つのレポートを選択して統合をトリガーし、バックグラウンドジョブが起動することを確認
ジョブが完了するまで待ち、通知が表示されること、ダウンロードリンクが有効であることを確認
PDF をダウンロードし、内容が正しいことを確認
レポートを 1 つだけ選択したエッジケースをテスト
レポートを選択してキャンセルするフローをテスト

実行後にヘルススコアが出力されます。87 だとしましょう——メインフローに問題はなく、いくつかの UX の小さな問題（例えばローディング状態のテキストが不明確）はあるが、ブロッカーではないことを意味します。

ステップ 6：`/ship`——ワンクリック納品

/ship

Gstack が完全なリリースチェックリストを実行します：

✅ Sync main — ブランチは main と同期されている
✅ Run tests — すべてのテストが通過
✅ Push branch — remote にプッシュ済み
✅ Open PR — PR が作成され、変更の範囲、テスト方法、既知の medium issue を含む明確な説明が添付されている

PR をレビューしてマージします。

完全フロー一覧

新機能の要件
    ↓
/plan-ceo-review   ← 「作る価値があるか」を確認し、スコープを明確に定義
    ↓
/plan-eng-review   ← アーキテクチャを設計し、エッジケースと failure mode を特定
    ↓
実装（Claude Code + あなた自身）
    ↓
/review            ← production レベルの問題を探し、critical / high を修正
    ↓
/qa                ← ブラウザで実際にテストし、機能が UI レベルで動作することを確認
    ↓
/ship              ← Sync、test、push、PR 一気通貫
    ↓
マージ、リリース

このフローにどれくらい時間がかかるか

実装時間を除いた完全サイクル、6 ステップ：

/plan-ceo-review：10-15 分（対話 + 思考）
/plan-eng-review：10-20 分（複雑な機能はより多くの出力時間が必要）
/review：5-10 分（結果を読む + critical issue を修正）
/qa：5-15 分（影響を受けたページ数による）
/ship：2-3 分

合計 30-60 分、実装除く。少なくないように聞こえますが、これらの 6 ステップで防げる問題は、通常後始末にかかる時間の方が遥かに長いです。

すべての機能でフル流を実行する必要はない

小さな変更は一部のステップをスキップできます：

小さなバグ修正：直接 /review + /ship、Plan Review をスキップ
コピーやスタイルの変更：/qa でビジュアルを確認し、/ship
設定オプションを追加：/plan-eng-review（アーキテクチャを素早く確認）+ /review + /ship

判断基準は 1 つ：今回の変更で問題が起きたら、後始末にどれくらい時間と労力がかかるか？ 答えが大きいほど、フルフローを実行する価値があります。

Gstack シリーズはここで完結です。1 人で、9 つの認知モード、繰り返し実行できる開発リズム——「作る価値があるか」から「production へ」まで、各段階に対応するツールがあり、記憶力や運に頼らない。

→ Gstack 入門コースのシリーズ総覧に戻る

シナリオ設定

ステップ 1：/plan-ceo-review——まず作る価値があるかを問う

ステップ 2：/plan-eng-review——「何をするか」を「どうやれば正しいか」に変換する

ステップ 3：実装

ステップ 4：/review——CI は通るが production でクラッシュする問題を探す

ステップ 5：/qa——AI に本物のブラウザで機能をテストさせる

ステップ 6：/ship——ワンクリック納品