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