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>
5.9 KiB
フェーズの検証とシッピング方法
目的: 実行済みの成果物をユーザー受け入れテストに通し、失敗を診断・修正してから、自動生成された本文でプルリクエストを作成します。
前提条件: フェーズが実行済みで SUMMARY.md ファイルが存在すること。実行がまだ完了していない場合は フェーズの実行 を参照してください。
ユーザー受け入れテストを実行する
/gsd-verify-work 1
GSD はフェーズの SUMMARY.md ファイルを読み込み、ユーザーが観察できる成果物を抽出して、それらを一つずつ確認します。各チェックポイントで、起こるべきことを提示し、実際にそうなっているかを尋ねます。
yes/y/ 空白 → 合格、次のテストへ- それ以外 → 問題として記録され、あなたの説明から重要度が推定されます
重要度を分類する必要はありません — GSD があなたの言葉から推定します（「クラッシュする」→ ブロッカー、「動かない」→ メジャー、「見た目がおかしい」→ コスメティック）。
進捗は .planning/phases/01-<name>/01-UAT.md に書き込まれ、/clear 後も保持されます。セッションが中断された場合は /gsd-verify-work 1 を再実行すると、最後のチェックポイントから再開するかどうか確認されます。
失敗が見つかった場合: 自動診断と修正プランニング
テストで問題が報告された場合、GSD は自動的に次を実行します:
- 根本原因を診断 — 問題ごとに並列デバッグエージェントを起動し、
UAT.mdに根本原因を追記します。 - ギャップ修正をプランニング —
gsd-plannerをギャップ修正モードで起動し、（診断を含む）UAT.mdを読み込んで新しいPLAN.mdファイルを書き込みます。 - 修正プランを検証 —
gsd-plan-checkerを起動してプランが実行可能かを確認します。問題があれば、プランナーとチェッカーが最大 3 回反復します。 - 次のステップを提示 — プランがチェッカーを通過すると:
Plans verified and ready for execution.
`/clear` then `/gsd-execute-phase 1 --gaps-only`
提示されたコマンドを実行して修正を適用し、/gsd-verify-work 1 を再実行してすべてが合格することを確認してください。
すべてのテストが合格した場合: フェーズをシップする
すべての UAT テストが合格した場合（または最初の実行で問題が見つからなかった場合）、フェーズは ROADMAP.md と STATE.md で自動的に完了としてマークされます。
/gsd-ship 1
GSD はプリフライトチェック（検証状態、クリーンなワーキングツリー、ブランチ、リモート、gh CLI 認証）を実行し、ブランチをプッシュして PR を作成します:
/gsd-ship 1 # レビュー準備完了の PR
/gsd-ship 1 --draft # ドラフト PR — 後続フェーズが続く場合に便利
PR の本文はプランニング成果物から自動的に組み立てられます:
ROADMAP.mdからのフェーズ目標SUMMARY.mdファイルとその主要ファイルからのプランごとのサマリー- 対応した要件（REQ-ID）
VERIFICATION.mdからの検証状態STATE.mdからの主要な決定事項
本文を手動で書く必要はありません。
オプション: シッピング前後のコードレビュー
/gsd-ship はコードレビューを自動的に実行しませんが、任意のタイミングで挿入できます:
検証前（UAT 前に問題を検出）:
/gsd-code-review 1 # 標準レビュー
/gsd-code-review 1 --fix # レビュー後に Critical + Warning の発見事項を自動修正
PR オープン後（マージ前に品質をゲート）:
/gsd-code-review 1 --depth=deep # インポートグラフを含むクロスファイル分析
サイクルの早い段階でのプランレビューに Gemini、Codex、その他のレビュアーを設定するには クロス AI レビューの設定 を参照してください。
オプション: クリーンな PR ブランチを作成する
ブランチにレビュアーに見せたくない .planning/ のコミットが含まれている場合:
/gsd-pr-branch # main に対してフィルタリング
/gsd-pr-branch develop # develop に対してフィルタリング
/gsd-pr-branch はコードの変更のみを含む新しいブランチを作成します。プランニング成果物のコミットは除外されます。チームのレビューポリシーでプランニングのノイズを除外する場合は、/gsd-ship の前にこれを実行してください。
マイルストーンのクローズ
これがマイルストーンの最後のフェーズだった場合は、マイルストーンの監査とアーカイブを実行します:
/gsd-audit-milestone # すべての要件がシップされたかを確認
/gsd-complete-milestone # アーカイブ、git タグの作成
/gsd-complete-milestone は PR マージ後の自然な次のステップです。検証とシッピングがプロジェクト全体のライフサイクルにどう組み込まれるかについては フェーズループ を参照してください。