gstack解剖 — ハーネスエンジニアリング実践事例

gstackはGitHubスター6万個の人気ツールだ。ただしここではツール紹介ではなく、gstackがハーネスエンジニアリングのどのパターンを実装しているかを解剖する。

1. 役割ベースルーティング

gstackの核心は一つのモデルを23の役割に分離したことだ。/reviewと打てばStaff Engineerが、/qaと打てばQA Leadが起動する。

これはオーケストレーションパターンの「ルーティング」だ。開発者がルーター役を果たし、状況に合った専門家を手動で呼び出す。各役割ごとにシステムプロンプト、許可ツール、出力形式が異なる。

同じClaudeモデルなのに/ceoで呼べばプロダクト戦略を論じ、/csoで呼べばOWASP脆弱性をスキャンする。モデルが変わったのではなくハーネスが変わったのだ。

2. パイプラインオーケストレーション

/office-hours → /plan-ceo-review → /plan-eng-review → コーディング → /review → /qa → /ship

この順序がgstackのスプリントパイプラインだ。前段階の出力が次段階の入力になる。/office-hoursで作成されたデザインドキュメントを/plan-ceo-reviewが読み、/plan-eng-reviewが作成したテストプランを/qaが実行する。

チェイニングパターンの教科書的実装。各段階で異なる専門家（プロンプト）を使いながら情報が蓄積される構造。

3. ガードレールレイヤー

/careful — 危険行動前の確認強化。/freeze — 特定ファイルの修正を完全ブロック。/guard — 全体安全モード。

これは実行段階のガードレールだ。モデルが本番コードを触る、テストなしでデプロイする、セキュリティ脆弱性を作るのを事前に防ぐ。

4. フィードバックループ

/reviewがバグを見つけたら自動修正する。/qaが実際のブラウザを開いてクリックし、エラーを発見したらコードを直して再検証する。

「実行 → 結果確認 → 修正 → 再実行」のループが各スキル内に内蔵されている。単にコードを生成して終わりではなく、結果を見て反復するエージェントループパターン。

5. コンテキスト蓄積

/learnスキルがセッション間の学習内容を永続保存する。プロジェクトパターン、落とし穴、好みが蓄積されるとハーネスがプロジェクトに特化していく。/retroは週間成果を定量測定する。

これはコンテキストウィンドウの限界を外部ストレージで克服するパターンだ。CLAUDE.mdと同じ原理。

結局何が違うのか

誰かがClaude Codeに「このリポのバグ直して」と言う。gstackユーザーは/plan-eng-reviewで設計を検証し、コーディング後/reviewで本番バグを捕捉し、/qaでブラウザテストを回し、/shipでPRを出す。

同じモデルだ。違いはハーネスだ。60日間60万行という数字がその差を証明している。