* fix(#2903): use the command form that actually works in reader-facing docs Docs told readers to type the colon form, which no runtime registers -- 18 of 19 runtimes use slash-hyphen and the 19th uses shell-var -- so anyone copying an example got an unrecognized command. Swept 178 occurrences across 53 files, locale mirrors included so they do not re-diverge from English. The colon form is a source-authoring token, not a user-facing one: install-time converters key on it to produce the hyphen form runtimes actually register. So the sweep is scoped, and three things are deliberately left alone: - ADRs, which are a historical record; editing their prose falsifies what was written at the time. - The legacy release-notes archive, pending a maintainer decision on whether it follows the same historical carve-out. Excluding it keeps a later reversal additive rather than a revert. - Source artifacts under commands, workflows and agents, where the colon form is load-bearing. Rewriting those would break the installed-skill guarantee across every runtime -- the single largest hazard here. The plugin namespace form is a real, separate token and survives untouched. Adds a lint enforcing exactly that boundary, since the correct form genuinely differs by directory and nothing previously caught the drift. Also fixes a hardcoded colon form in the capability-matrix generator. The sweep alone would have left the generated matrix disagreeing with the template that produces it, so the fix is at the source and the output regenerated. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(#2903): stop the sweep misquoting source frontmatter Adversarial review caught three lines where the sweep rewrote a citation of the literal YAML name: key from a source command file. That key genuinely is the colon form -- this change's own carve-out logic says source-authoring tokens keep it -- so the docs ended up misquoting the real files. One of the three is an acceptance-checklist assertion, which the sweep turned into a false statement. Restored the three citations to match their sources verbatim, surgically: where a line carried both a name: citation and a real reader-facing slash command, only the citation reverted and the command stayed corrected. The guard needed the same distinction, or it would have flagged the restoration and reddened the build: a gsd:<cmd> token preceded by name: is a citation of a source token and is now permitted. The exemption is deliberately narrow -- a bare gsd:<cmd> anywhere else still fails -- with a test pinning that narrowness. Also makes the detection case-insensitive. Review found /GSD:next slipped through silently; no such casing exists in the tree today, so this closes a latent gap rather than fixing a live one. Swept the whole tree for further corrupted citations: none beyond the three. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(#2903): retire the stale-next invariant and sweep next like every other command Maintainer decision on a genuine conflict between two contracts. Invariant #3054 banned the literal /gsd-next from user-facing docs because it named a retired workflow-advance command. But commands/gsd/next.md is a live command -- the state-aware smart-entry launcher -- and this issue requires docs to use the hyphen form every runtime actually registers. Both could not hold for this one command, so docs had been sidestepping the ban by keeping the colon form, which is exactly the defect this issue exists to remove. FEATURES.md already recorded the reassignment: the hyphen form "is not the retired workflow-advance command; it is reserved for the state-aware smart-entry launcher. Workflow advancement remains under /gsd-progress --next." With that reassignment the invariant's premise is obsolete and the guard now contradicts the documented command form, so it is retired with a comment recording why rather than deleted silently. next is now swept like every other command, and the earlier exemption added to the new guard is removed so nothing is special-cased. Four citations of the literal name: frontmatter key stay in colon form, because the source file really does carry name: gsd:next and a doc quoting it must reproduce it verbatim. Two of those lines were reworded to say which side is the frontmatter key and which is the slash command, since they previously conflated the two. Verified the retired scan would now genuinely fail against this tree -- the conflict was real and resolved, not dodged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * chore(#2903): backfill changeset pr number Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
GSD Core ドキュメント
ドキュメントは 4 つの象限で構成されています。チュートリアルは実践で学ぶ、ハウツーガイドは特定のタスクを解決する、リファレンスは信頼できる情報を示す、解説はコンセプトと設計上の決定を探求する。
言語バージョン: English · Português (pt-BR) · 日本語 · 简体中文 · 한국어
チュートリアル
- はじめてのプロジェクト — インストールから最初のフェーズ出荷まで、確実な一本道
- 既存コードベースのオンボーディング — ブラウンフィールドのリポジトリに GSD Core を導入する
How-to guides
- ランタイムへのインストール — サポートされる全 16 ランタイムのランタイム別インストール手順
- フェーズを議論する — 計画を始める前に実装上の決定事項を記録する
- フェーズを計画する — リサーチを実行し、作業を分解し、計画の品質を検証する
- フェーズを実行する — 新鮮なコンテキストのサブエージェントで並列ウェーブとして計画を実行する
- 検証と出荷 — 完成した作業を確認し、障害を診断し、PR を作成する
- フェーズを自律的に実行する — 無人フェーズ実行に自律モードを使用する
- クイックおよびファストタスクを処理する — フェーズループ外のアドホック作業に
/gsd-quickと/gsd-fastを使用する - モデルプロファイルを設定する — クオリティ・バランス・バジェットのモデルティア間を切り替える
- クロス AI レビューをセットアップする — プライマリエージェントが生成したコードをレビューする 2 番目の AI を設定する
- ワークストリームで並列作業する — ワークストリームを使って独立した作業ラインを同時に実行する
- ワークスペースで作業を隔離する — ワークスペースを使って実験的またはリスクのある変更をサンドボックス化する
- 失敗した実行をデバッグする — 壊れたまたは不完全なフェーズ実行を診断・回復する
- スパイクとスケッチ — 計画を確定する前の探索的作業に
/gsd-spikeと/gsd-sketchを使用する - UI フェーズを設計する — フロントエンドおよびビジュアル作業に UI フェーズループを使用する
- トラッカーイシューから GSD を動かす — GitHub、Linear、または Jira のイシューからフェーズを開始する
- GSD 2 から移行する — 既存の GSD 2 プロジェクトを GSD Core にアップグレードする
- GSD をアップデートする — インストーラーを再実行して最新リリースを取得する
- 回復とトラブルシューティング — よくある問題を修正し、コンテキストを再構築し、アンインストールする
リファレンス
- コマンド — フラグと例を含むすべてのコマンド
- 設定 — 完全な設定スキーマ、モデルプロファイル、Git ブランチ戦略
- CLI ツール — ワークフローとエージェント向け
gsd-tools.cjsプログラマティック API - 機能 — 完全な機能インデックス
- インベントリ — インストール済みスキルとサーフェスマップ
- STATE.md スキーマ —
.planning/STATE.mdのフィールド別リファレンス - CONTEXT.md スキーマ —
.planning/phases/<N>/CONTEXT.mdのフィールド別リファレンス - PLAN.md スキーマ —
.planning/phases/<N>/PLAN.mdのフィールド別リファレンス - 計画アーティファクト — すべての
.planning/ファイルとその役割
解説
- コンテキストエンジニアリング — コンテキストの腐敗がどのように形成され、GSD Core がどのように防ぐか
- フェーズループ — Discuss → Plan → Execute → Verify → Ship サイクルの設計理念
- マルチエージェントオーケストレーション — サブエージェントがどのように生成・スコープ設定・調整されるか
- セキュリティモデル — 信頼境界、パーミッション、安全な自動化
- アーキテクチャ — システムアーキテクチャ、エージェントモデル、データフロー
- ディスカスモード —
/gsd-discuss-phaseの assumptions モードと interview モード - コンテキストモニタリング — コンテキストウィンドウ監視フックのアーキテクチャ
- イシュー駆動オーケストレーション — 既存のプリミティブを使ってトラッカーイシューから GSD を動かすレシピ
Related
- ルート README — ランディングページ、クイックスタート、ドキュメント概要
- 変更履歴 — リリース履歴