3bb2f8f1c5
* 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>
177 lines
7.3 KiB
Markdown
177 lines
7.3 KiB
Markdown
# トラッカーイシューから GSD Core を操作する方法
|
||
|
||
**目標:** カスタムスクリプトやトラッカー連携なしに、GSD Core に既存のコマンドのみを使って、GitHub・Linear・Jira の単一の適切にスコープされたイシューを分離されたワークスペースからマージ済み PR まで通じたパイプラインで処理する。
|
||
|
||
**前提条件:** GSD Core がインストール済みであること。イシューは明確なスコープ、観察可能な受け入れ基準、上流のブロッカーがない状態であること。
|
||
|
||
このパターンの背景にある概念と設計理由については、[イシュー駆動オーケストレーションの説明](../issue-driven-orchestration.md)を参照してください。
|
||
|
||
---
|
||
|
||
## ステップ 1: イシューをフェーズにマッピングする
|
||
|
||
トラッカーイシューを開き、`ROADMAP.md` へのマッピングを決定します。
|
||
|
||
- **イシューが既存のフェーズと一致する** → フェーズ番号をメモしてステップ 2 に進む。
|
||
- **イシューがスタンドアロンの新しい作業** → フェーズを追加する：
|
||
|
||
```bash
|
||
/gsd-phase "Description matching the issue title"
|
||
```
|
||
|
||
- **イシューが緊急で既存フェーズの間に挿入する必要がある** → 小数フェーズを挿入する：
|
||
|
||
```bash
|
||
/gsd-phase --insert 3 "Fix: description from issue"
|
||
```
|
||
|
||
トラッカーイシューの URL をコピーします。ステップ 3 で `CONTEXT.md` に貼り付けることで、コンテキスト圧縮を経ても追跡可能性が維持されます。
|
||
|
||
---
|
||
|
||
## ステップ 2: 分離されたワークスペースを作成する
|
||
|
||
すべてのイシューには独自のワークスペース（独立した `.planning/` ディレクトリを持つ git ワークツリー）を用意します。部分的な作業、中断されたプラン、探索的なコミットを `main` の外に保ちます。
|
||
|
||
```bash
|
||
/gsd-workspace --new --name my-issue-slug --repos . --strategy worktree
|
||
```
|
||
|
||
続行する前にワークスペースディレクトリに移動します。
|
||
|
||
```bash
|
||
cd ~/gsd-workspaces/my-issue-slug
|
||
```
|
||
|
||
---
|
||
|
||
## ステップ 3: フェーズを議論する
|
||
|
||
計画が始まる前に実装上の決定を固定するために discuss-phase を実行します。セッションが開いたら、トラッカーイシューの URL を議論に貼り付けて `CONTEXT.md` に記録します。
|
||
|
||
```bash
|
||
/gsd-discuss-phase N
|
||
```
|
||
|
||
GSD はイシューのスコープにある曖昧さ（エラーハンドリング、エッジケース、インターフェースコントラクト、技術選択）について質問します。回答がその後の計画を形作ります。
|
||
|
||
すべての答えがわかっていて素早く進みたい場合：
|
||
|
||
```bash
|
||
/gsd-discuss-phase N --auto
|
||
```
|
||
|
||
---
|
||
|
||
## ステップ 4: フェーズを計画する
|
||
|
||
```bash
|
||
/gsd-plan-phase N
|
||
```
|
||
|
||
GSD はリサーチエージェントを起動し、`CONTEXT.md` の決定（イシュー URL を含む）を読み込み、アトミックな `PLAN.md` ファイルを生成します。プランチェッカーが各プランを保存前に検証します。
|
||
|
||
実行前に外部 AI CLI からのピアレビューが必要な場合（重要な変更には推奨）：
|
||
|
||
```bash
|
||
/gsd-review --phase N
|
||
/gsd-plan-phase N --reviews
|
||
```
|
||
|
||
または、HIGH の懸念事項がなくなるまでプラン・レビュー・収束ループを実行するには：
|
||
|
||
```bash
|
||
/gsd-plan-review-convergence N
|
||
```
|
||
|
||
---
|
||
|
||
## ステップ 5: フェーズを実行する
|
||
|
||
インタラクティブなフェーズ単位の実行の場合：
|
||
|
||
```bash
|
||
/gsd-execute-phase N
|
||
```
|
||
|
||
すべての残りのフェーズをハンズオフで実行する場合：
|
||
|
||
```bash
|
||
/gsd-autonomous
|
||
```
|
||
|
||
進捗を監視しながらフェーズ全体で作業を dispatch できるインタラクティブなダッシュボードの場合：
|
||
|
||
```bash
|
||
/gsd-manager
|
||
```
|
||
|
||
3 つのアプローチすべてで `STATE.md` を更新し、各タスクをアトミックにコミットし、フェーズ後の検証を実行します。
|
||
|
||
---
|
||
|
||
## ステップ 6: 作業を検証する
|
||
|
||
```bash
|
||
/gsd-verify-work N
|
||
```
|
||
|
||
GSD は（トラッカーイシューを反映した）フェーズゴールからの受け入れ基準を 1 つずつ確認します。何かが失敗した場合、GSD は根本原因を診断して修正プランを作成します。すべてのチェックが通るまで execute と verify を繰り返します。
|
||
|
||
コードが正しく見えても `verification_failed` はブロッカーとして扱ってください。失敗は通常、元のイシューからの見落とされた受け入れ基準を示しています。
|
||
|
||
---
|
||
|
||
## ステップ 7: レビューとリリース
|
||
|
||
PR を開く前にコードレビューを実行します。
|
||
|
||
```bash
|
||
/gsd-code-review N
|
||
/gsd-code-review N --fix
|
||
```
|
||
|
||
次に PR を作成します。
|
||
|
||
```bash
|
||
/gsd-ship N
|
||
```
|
||
|
||
GSD は計画成果物（フェーズゴール、変更概要、対応した要件、検証ステータス、主要な決定）から PR ボディを組み立てます。PR がマージされた時にトラッカーイシューが自動的にクローズされるよう、PR ボディに `Closes #NNN` または `Fixes #NNN` を含めます（または `/gsd-config` で設定）。
|
||
|
||
---
|
||
|
||
## ステップ 8: フォローアップ作業を記録する
|
||
|
||
イシューを進める中で関連する作業が見つかることがよくあります。コンテキストを失わずに記録します。
|
||
|
||
```bash
|
||
/gsd-capture "Follow-up: description of discovered work" # Todo として追加
|
||
/gsd-capture --seed "Idea worth a future phase" # 次のマイルストーン用に保存
|
||
/gsd-capture --backlog "Not urgent but worth tracking" # バックログに保存
|
||
```
|
||
|
||
GSD はトラッカーに自動的に投稿しません。記録されたフォローアップからトラッカーイシューを作成するのは手動の別ステップです。これにより人間のレビューをループに保ちます。
|
||
|
||
---
|
||
|
||
## 条件分岐
|
||
|
||
| 状況 | 対応 |
|
||
|-----------|-----------|
|
||
| イシューが非常に小さい（タイポ、設定変更） | ワークスペース + discuss + plan をスキップして `/gsd-quick` を使用する |
|
||
| イシューに複数の独立したサブタスクがある | `/gsd-manager` を使ってプラン全体で並行実行する |
|
||
| イシューが別のイシューにブロックされている | 上流のブロッカーが解決されるまで開始しない；GSD には自動的な依存ポーラーがない |
|
||
| 実行中にイシューのスコープが想定より大きくなった | 停止し `/gsd-phase --insert N` でサブフェーズを追加して続行する |
|
||
| インタラクティブな議論をスキップしたい | `/gsd-discuss-phase` に `--auto` フラグを使用するか、プロジェクト全体の自動化のために `workflow.skip_discuss: true` を設定する |
|
||
| 複数のイシューが一貫したリリースを形成する | `/gsd-new-milestone` でグループ化し `/gsd-autonomous` で順番に実行する |
|
||
|
||
---
|
||
|
||
## Related
|
||
|
||
- [イシュー駆動オーケストレーションの説明](../issue-driven-orchestration.md)
|
||
- [ワークスペースで作業を分離する](isolate-work-with-workspaces.md)
|
||
- [検証とリリース](verify-and-ship.md)
|
||
- [ドキュメント一覧](../README.md)
|