golem15/msd-core
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
9e2ef2c94dea3f1267deba570c9a423fb38c2f85
msd-core/docs/ja-JP/issue-driven-orchestration.md
Tom Boucher 3bb2f8f1c5 docs: rebrand to GSD Core and restructure docs with Diataxis (#605) 
* chore: wire docs/agents config into AGENTS.md Agent skills section

Add the `## Agent skills` discovery block pointing the engineering
skills at the existing docs/agents/{issue-tracker,triage-labels,domain}.md
files (issue tracker, triage label mapping, single-context domain docs).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

* docs: rebrand to GSD Core and restructure docs with Diataxis

Reorganise the root README and docs/ around the Diataxis framework
(tutorials, how-to guides, reference, explanation), add new how-to
guides and schema references (STATE.md / CONTEXT.md / PLAN.md /
planning artifacts), and cross-link the whole set. Update the lone
legacy gsd-build reference to open-gsd; keep internal get-shit-done/
filesystem paths unchanged (directory rename tracked separately in
open-gsd/gsd-core#604). Regenerate the ja-JP, ko-KR, pt-BR and zh-CN
localised trees to mirror the new structure.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

* docs: backfill changeset PR number (#605)

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-02 08:13:09 -04:00

93 lines
14 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# GSD によるイシュー駆動オーケストレーション
**ステータス：** 安定したワークフローガイド
**対象：** GitHub Issues、Linear、Jira、または類似のイシュートラッカーで作業を追跡し、GSD の既存プリミティブを通じて AI 支援実装を推進したい開発者。
## このガイドについて
GSD がすでに提供するコマンドをイシュートラッカー → ワークスペース → 計画/実行 → 検証/レビュー → PR ループに組み合わせるためのレシピです。これはドキュメントのみです。新しいコマンドなし、デーモンなし、トラッカー統合なし——以下で参照するすべてのコマンドは今日の GSD に既に存在します。
この形は OpenAI のオープンソース [Symphony オーケストレーションリファレンス](https://openai.com/index/open-source-codex-orchestration-symphony/)（[リポジトリ](https://github.com/openai/symphony)）にインスパイアされています。GSD は Symphony をベンダリングまたはラッピングしません。オーケストレーションの *概念* は GSD がすでに公開しているプリミティブにきれいにマッピングされます；このガイドはグルーコードを書いたり GSD の安全ゲートを回避したりせずにパターンを採用できるようにマッピングを説明するだけです。
## なぜこれが存在するか
GSD にはイシュー駆動 AI 開発のビルディングブロックがあります——`/gsd-workspace --new`、`/gsd-manager`、`/gsd-autonomous`、`/gsd-verify-work`、`/gsd-review`、`/gsd-ship`、さらに `STATE.md` とフェーズアーティファクトスイート——しかし、カスタムオーケストレーションスクリプトを書かずに単一のトラッカーイシューから端から端まで動かす方法を説明するガイドがありませんでした。そのガイドなしでは失敗モードは：
- 過少使用：開発者が discuss/plan/execute を手動で実行し、作業パターンが合致しているときでも `/gsd-manager` や `/gsd-autonomous` に手を出さない。
- 回避策スクリプト：開発者がトラッカーと `claude` 呼び出しの間にアドホックなシェルループを配線し、`STATE.md`、フェーズマニフェスト、検証ゲートを迂回する。
このガイドは正規ループを発見しやすくします。
## 概念マッピング
各行は Symphony スタイルのオーケストレーション概念を、それをすでに提供する GSD プリミティブにマッピングします。Symphony のドキュメント、ブログ投稿、サードパーティのオーケストレーション記事を読む際の変換キーとしてこのテーブルを使ってください。
| Symphony の概念 | GSD プリミティブ |
|---|---|
| `WORKFLOW.md`（トップレベルの意図） | `ROADMAP.md`（プロジェクトの意図）、`STATE.md`（ライブステータス）、フェーズ `CONTEXT.md`（フェーズごとのスコープ）、フェーズ `PLAN.md`（実行可能なステップ） |
| タスクごとの分離されたエージェントワークスペース | `/gsd-workspace --new --strategy worktree` |
| エージェントのディスパッチと並列性 | `/gsd-manager`（インタラクティブダッシュボード）、`/gsd-autonomous`（非同期） |
| フェーズごとの計画と議論ステップ | `/gsd-discuss-phase` → `/gsd-plan-phase` → `/gsd-execute-phase` |
| 作業の証明 / テスト証拠 | `/gsd-verify-work`（`/clear` をまたいで永続する UAT.md） |
| 対立的レビュー | `/gsd-review`（計画のクロス AI ピアレビュー） |
| ヒューマンマージゲート | `/gsd-ship`（PR を作成し、オプションのコードレビュー、マージ準備） |
| フォローアップキャプチャ | `/gsd-capture`、`/gsd-capture --seed`、`/gsd-new-milestone`、または手動で開いたトラッカーイシュー |
| 並列性制御 | マネージャー / バックグラウンドエージェントのセマンティクス（常時オンのポーラーなし） |
このマッピングは一方向です：GSD が安全ゲート（検証、ヒューマンレビュー、フォローアップ作成の明示的確認）を所有します。Symphony の「継続的オーケストレーション」フレーミングは意図的に採用していません——[非目標](#non-goals) を参照してください。
## エンドツーエンドフロー
単一のトラッカーイシューから端から端まで実行できるように書かれた、正規のイシュー → PR ループ。実行前に括弧内のプレースホルダーを置き換えてください。
1. **トラッカーイシューを選ぶ。** トラッカー（GitHub、Linear など）から、自律的な実装に十分な範囲があるイシューを一つ選びます——境界が明確なスコープ、観察可能な受け入れ基準、実行をブロックする上流の依存関係なし。
2. **GSD フェーズにマッピングする。** イシューが `ROADMAP.md` の既存フェーズにマッピングされる場合はそれを選択します。そうでない場合は、関連イシューの新しいマイルストーンのために `/gsd-new-milestone` を実行するか、`/gsd-phase` / `/gsd-phase --insert` でフェーズを開きます。フェーズの `CONTEXT.md` にトラッカーイシューの URL を記録し、圧縮後もトレーサビリティが維持されるようにします。
3. **分離されたワークスペースを作成する。** `/gsd-workspace --new --strategy worktree <slug>` を実行して、独立した `.planning/` ディレクトリを持つ git ワークツリーを立ち上げます。ワークツリーは安全境界です：探索、部分的なコミット、中断された計画はすべて `main` の外に留まります。
4. **GSD を通じて discuss → plan → execute を実行する。** ワークスペース内から、`/gsd-discuss-phase` で曖昧さを明確にし、`/gsd-plan-phase` で `PLAN.md` を生成し、`/gsd-manager`（インタラクティブダッシュボード）または `/gsd-execute-phase` / `/gsd-autonomous`（非同期）で実装します。GSD の外から生の `claude` 呼び出しを直接動かすことは避けてください——それは `STATE.md` の更新とフェーズマニフェストを迂回します。
5. **作業の証明を要求する。** `/gsd-verify-work` を実行して、フェーズの受け入れ基準に対して UAT をユーザーに案内します。テスト、スクリーンショット、ログキャプチャ、設定差分はすべて `UAT.md` に記録され、`/clear` をまたいで永続し、検証でミスしたスコープが発見されたときに `/gsd-plan-phase --gaps` にフィードされます。
6. **レビューと出荷ゲートを通過する。** `/gsd-review` を実行して独立した AI CLI からの対立的ピアレビューを受け（モデルごとのブラインドスポットをキャッチ）、次に `/gsd-ship` で計画アーティファクトから組み立てたリッチなボディ付きで PR を開きます。どちらのゲートもリモートに何かが届く前に人間の決定を必要とします。
7. **フォローアップ作業を明示的にキャプチャする。** インラインメモには `/gsd-capture` を、将来のフェーズの価値があるアイデアには `/gsd-capture --seed` を、一貫したフォローアップグループには `/gsd-new-milestone` を使います。発見されたフォローアップからトラッカーイシューを作成するには、明示的なユーザー確認が必要です——GSD はリモートトラッカーに自動投稿しません。
PR がマージされると、ループが閉じます。PR ボディのオートクローズキーワード（`Closes #NNN` / `Fixes #NNN`）がマージ時にトラッカーイシューを閉じます。
## 安全境界
このループが安全なのは、4 つの不変条件が設計上成立するからです：
- **分離されたワークツリー。** すべてのイシューが `/gsd-workspace --new` ワークツリーで実行されるため、部分的な作業、中断された計画、探索的なコミットは `main` に触れません。`gsd-local-patches/` は、ワークツリーの手動編集をアップデートをまたいで持ち戻す必要がある場合の回復面です。
- **明示的な人間によるレビュー。** `/gsd-review` と `/gsd-ship` はどちらも人間の承認で停止します。オートマージはなく、実行からの自動 PR パスもありません。特定のリポジトリで人間ゲートを削除したい場合は、それはブランチ保護 / マージキューポリシーの決定であり、GSD があなたに代わってオプトインするものではありません。
- **自動公開投稿なし。** GSD は明示的なユーザー起動コマンドなしにトラッカーイシューを開いたり、コメントしたり、閉じたりしません。フォローアップキャプチャはデフォルトでローカルアーティファクト（メモ、シード、マイルストーン）になります；トラッカーに押し戻すことは別の手動ステップです。
- **出荷前の検証。** `/gsd-verify-work` の UAT.md は `/gsd-ship` が実行される前に証拠を記録しなければなりません。推奨される規律は、実装が正しく見えるときでも `verification_failed` をブロッカーとして扱うことです——失敗は通常フラキーなテストではなく、ミスした受け入れ基準を表面化します。
これらの不変条件のいずれかが迂回された場合（例：ワークツリーに直接 `claude` を実行する、`/gsd-verify-work` をスキップする、またはユーザー確認なしにトラッカー API を通じてイシュー作成をスクリプト化する）、このガイドの保証は適用されません。
## 非目標 {#non-goals}
このガイドは意図的に以下のいずれも提案しません。将来のコントリビューターがコードレビューで再論争しないように、ここにリストされています：
- **Symphony コードのベンダリングまたはコピーなし。** GSD は独自のプリミティブを再利用します。上記のマッピングは概念的です；Symphony 由来のソースはこのリポジトリに同梱されません。
- **常時実行デーモンなし。** GSD は GitHub や Linear をポーリングしません。マネージャーと自律ワークフローは、デーモンではなくバックグラウンドエージェントのセマンティクスを通じて並列性を処理します。
- **必須のトラッカー依存関係なし。** このループはトラッカー統合なしで機能します。「トラッカーイシュー」ステップは *人間の入力* です——URL は `CONTEXT.md` に入ります。GSD はあなたが使用するトラッカーについても、トラッカーを使用するかどうかについても意見を持ちません。
- **検証、レビュー、または人間の決定ゲートの迂回なし。** `/gsd-autonomous` を実行する場合でも、検証とレビューゲートは依然として発火します。「自律的」ラベルはフェーズからフェーズへの進行を指し、人間の承認をスキップすることではありません。
- **デフォルトのスキル / コマンド面の拡張なし。** このガイドで参照するすべてのコマンドはすでに存在します。このガイドはドキュメント面であり、機能面ではありません。
## 将来のフォローアップの可能性
このループでのメンテナーの経験がそれを正当化するなら、別の承認済み拡張として後で *最小限の* トラッカーブリッジを追加できます：
- 一つの GitHub または Linear イシューを GSD ワークスペース / フェーズにインポートする。
- `UAT.md` 証拠をソースイシューのコメントとしてエクスポートする。
- `/gsd-capture --seed` の出力からフォローアップトラッカーイシューを生成する。
これらはそれぞれ統合面と継続的なメンテナンス負担を追加するため、それぞれ独自の拡張提案になります。このガイドのスコープ外です。
## Related
- [フェーズループ](explanation/the-phase-loop.md) — discuss → plan → execute → verify → ship が繰り返すサイクルとしてどう組み合わさるか。
- [ワークスペース how-to](how-to/work-in-parallel-with-workstreams.md) — 並列ワークツリーの作成と管理のステップバイステップガイド。
- [ドキュメント索引](README.md) — GSD Core ドキュメントの完全な目次。
- [docs/USER-GUIDE.md](./USER-GUIDE.md) — 上で参照した個々のコマンドのタスク指向のウォークスルー。
- [docs/COMMANDS.md](COMMANDS.md) — `/gsd-*` コマンドの完全なリファレンス。
- [docs/FEATURES.md](FEATURES.md) — 機能レベルの能力マトリクス（ワークスペース、マネージャー、自律、検証、レビュー、出荷）。
- [docs/ARCHITECTURE.md](ARCHITECTURE.md) — フェーズアーティファクトのライフサイクルと `STATE.md` の仕組み。
Reference in New Issue View Git Blame Copy Permalink