ffd5370464
* 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>
12 KiB
ランタイムへの GSD Core インストール方法
GSD Core（@opengsd/gsd-core）を普段使いの AI コーディングランタイムにインストールします。このガイドでは、サポートされている各ランタイム向けの標準インストール手順と、Node.js がない環境向けの手動手順を説明します。
必要なもの: Node.js 18 以上と npm（または npx）。Node.js がない場合は Node.js なしでのインストール へ進んでください。
インストーラーが必要な理由
GSD Core は Claude Code のネイティブ frontmatter 形式でエージェントファイルとコマンドファイルを提供しています。サポートされている各ランタイムは、異なるスキーマ、ディレクトリ構成、コマンド呼び出し構文を要求します。インストーラーは必要な変換を実行します。たとえば OpenCode 向けのツールリストとカラー値の変換、Codex 向けの TOML エージェントエントリの書き込み、Gemini CLI 向けのすべてのコマンド本文をハイフン形式（/gsd-update）からコロン形式（/gsd-update）への書き換えなどです。
agents/ や commands/ からファイルを直接コピーしないでください。 そうするとこれらの変換がスキップされ、スキーマ検証エラーやコマンドの欠落が発生します。
標準インストール
任意のディレクトリからインストーラーを実行します。ランタイムの選択と、グローバル（全プロジェクト）またはローカル（このプロジェクトのみ）のどちらでインストールするかを確認するプロンプトが表示されます。
npx @opengsd/gsd-core@latest
新規インストールやランタイムの切り替え後にインストーラーを再実行する場合も、このコマンド 1 つだけで完結します。
ランタイム別のインストール手順
Claude Code
npx @opengsd/gsd-core@latest --claude --global
スキルは ~/.claude/ に配置されます。次回の Claude Code セッションからコマンドが /gsd-* スラッシュコマンドとして表示されます。反映するには Claude Code を再起動してください。
インストールディレクトリの上書き:
CLAUDE_CONFIG_DIR=~/.claude-alt npx @opengsd/gsd-core@latest --claude --global
Gemini CLI
npx @opengsd/gsd-core@latest --gemini --global
スキルは ~/.gemini/ に配置されます。インストーラーはすべてのコマンド本文を Gemini のコロン名前空間（/gsd-update、/gsd-config など）に書き換えます。インストール後は Gemini CLI を再起動してください。
インストールディレクトリの上書き:
GEMINI_CONFIG_DIR=~/.gemini-alt npx @opengsd/gsd-core@latest --gemini --global
OpenCode
npx @opengsd/gsd-core@latest --opencode --global
スキルは ~/.config/opencode/（XDG）または ~/.opencode/ に配置されます。インストーラーはエージェントの frontmatter を OpenCode のスキーマに変換します（tools: フィールドの削除、カラー値の hex 変換）。変更内容の詳細は Node.js なしでのインストール — OpenCode の変換内容 を参照してください。
インストールディレクトリの上書き:
OPENCODE_CONFIG_DIR=~/.config/opencode-alt npx @opengsd/gsd-core@latest --opencode --global
Kilo
npx @opengsd/gsd-core@latest --kilo --global
スキルは ~/.config/kilo/（XDG）または ~/.kilo/ に配置されます。OpenCode と同じフラットな Markdown コマンド形式を使用します。
インストールディレクトリの上書き:
KILO_CONFIG_DIR=~/.config/kilo-alt npx @opengsd/gsd-core@latest --kilo --global
Codex
npx @opengsd/gsd-core@latest --codex --global
スキルは ~/.codex/skills/gsd-*/SKILL.md に配置されます。エージェントは config.toml にエージェントごとの TOML エントリとして書き込まれます。インストール後は Codex を再起動（または codex --reload を実行）してください。
最低サポートバージョン: Codex CLI 0.130.0。それより古いバージョンにはスキルルートの追加スキャン処理があり、重複リストが生じることがあります。
GitHub Copilot
npx @opengsd/gsd-core@latest --copilot --global
スキルは ~/.copilot/ に配置されます。GSD はエージェント .md ファイルとリポジトリ instruction ファイルとしてインストールされます。
インストールディレクトリの上書き:
COPILOT_CONFIG_DIR=~/.copilot-alt npx @opengsd/gsd-core@latest --copilot --global
Cursor
npx @opengsd/gsd-core@latest --cursor --global
スキルは ~/.cursor/ に配置されます。GSD はスキル、エージェント、ルールの参照をインストールします。
インストールディレクトリの上書き:
CURSOR_CONFIG_DIR=~/.cursor-alt npx @opengsd/gsd-core@latest --cursor --global
Windsurf
npx @opengsd/gsd-core@latest --windsurf --global
スキルは ~/.codeium/windsurf/ に配置されます。GSD はスキル、エージェント、ワークスペースルールをインストールします。
インストールディレクトリの上書き:
WINDSURF_CONFIG_DIR=~/.codeium/windsurf-alt npx @opengsd/gsd-core@latest --windsurf --global
Cline
Cline はルールベースの統合方式を使用します。GSD はスラッシュコマンドではなく .clinerules としてインストールされます。
# グローバルインストール（全プロジェクト）
npx @opengsd/gsd-core@latest --cline --global
# ローカルインストール（このプロジェクトのみ）
npx @opengsd/gsd-core@latest --cline --local
グローバルインストールは ~/.cline/ に書き込みます。ローカルインストールは ./.cline/ に書き込みます。ルールは Cline によって自動的に読み込まれます。カスタムのスラッシュコマンドは登録されません。
CodeBuddy
npx @opengsd/gsd-core@latest --codebuddy --global
スキルは ~/.codebuddy/skills/gsd-*/SKILL.md に配置されます。
Qwen Code
Qwen Code は Claude Code 2.1.88 以降と同じオープンスキル標準を使用します。
npx @opengsd/gsd-core@latest --qwen --global
スキルは ~/.qwen/skills/gsd-*/SKILL.md に配置されます。
インストールディレクトリの上書き:
QWEN_CONFIG_DIR=~/.qwen-alt npx @opengsd/gsd-core@latest --qwen --global
Augment Code
npx @opengsd/gsd-core@latest --augment --global
スキルは ~/.augment/ に配置されます。GSD はスキルとエージェントをインストールします。フックや statusline の管理は行いません。
Antigravity
npx @opengsd/gsd-core@latest --antigravity --global
インストーラーは Antigravity の設定ディレクトリ（~/.gemini/antigravity、~/.gemini/antigravity-ide、または ~/.gemini/antigravity-cli）を自動検出します。Gemini 互換の設定ポリシーを使用します。
インストールディレクトリの上書き:
ANTIGRAVITY_CONFIG_DIR=~/.gemini/antigravity-alt npx @opengsd/gsd-core@latest --antigravity --global
Trae
npx @opengsd/gsd-core@latest --trae --global
スキルは ~/.trae/ に配置されます。GSD はスキル、エージェント、ルールの参照をインストールします。
ローカルインストールとグローバルインストール
上記の例はすべて --global を使用しており、ユーザーアカウント全体に GSD を一度インストールします。インストールを単一プロジェクトに限定するには、--global を --local に置き換えます。
npx @opengsd/gsd-core@latest --claude --local
ローカルインストールはプロジェクトルートの .claude/ ディレクトリに書き込みます。両方が存在する場合、ローカルインストールの設定がグローバルの設定より優先されます。
プレリリースエディション（Next / Nightly / Insiders / Preview）のインストール
ランタイムのプレリリースエディション（Windsurf Next、Cursor Nightly、VS Code Insiders、Codex preview チャンネルなど）は、隣接する設定ディレクトリから読み込みます。インストーラーを実行する前に対応する *_CONFIG_DIR 環境変数を設定してください。
WINDSURF_CONFIG_DIR=~/.codeium/windsurf-next npx @opengsd/gsd-core@latest --windsurf --global
インストーラーのプロンプトでは対応する安定版ランタイムを選択してください。GSD はプレリリースエディションを独立した名前付きランタイムとしては列挙していません。これらは環境変数によるベストエフォートの対応であり、リリース CI では個別にテストされていません。
Node.js なしでのインストール
npx が実行できない場合（例：Node.js がない Windows マシン）、2 つの選択肢があります。
選択肢 A — Node.js がある別のマシンを使用する。 WSL、Linux VM、CI ランナー、Docker コンテナなど、Node.js があるマシンであれば何でも使えます。そのマシンでインストーラーを実行し、出力ディレクトリをターゲットマシンにコピーします。OpenCode の場合:
npx @opengsd/gsd-core@latest --opencode --global
# その後 ~/.config/opencode/agents/ を Windows マシンにコピー
選択肢 B — ソースファイルを手動で変換する。 エージェントのソースファイルは GSD Core リポジトリの agents/ に存在し、Claude Code のネイティブ frontmatter 形式になっています。各ランタイムは異なる形式を要求します。ランタイムごとの正確なフィールド変換については、ユーザーガイドの Manual install / no-Node.js setup を参照してください。OpenCode の変換内容が詳しく説明されており、他のランタイム向けのインストーラーの convert*Frontmatter 関数も案内されています。
インストール後の作業
新しいコマンドとエージェントを反映するためにランタイムを再起動してください。その後、新規プロジェクトを開始するか既存リポジトリをオンボーディングします。
/gsd-new-project # グリーンフィールドプロジェクト
/gsd-onboard # 既存コードベース
再起動後もコマンドが見つからない場合は、インストールディレクトリがランタイムの期待する設定パスと一致しているか確認してください。最もよくある不一致については上記のプレリリースエディションのセクションを参照してください。