Files

Tom Boucher 5d4c98cde7 chore(#4729 ): guard the retired-runtime name, and finish the locale residue (#4753 )

* chore(#4729): guard the retired-runtime name, and finish the locale residue

Phase 5 of 5 on epic #4709, and the phase that closes it. Two parts, one
concern: make the tree clean, and keep it clean. The guard is inert until the
tree is clean, and shipping the cleanup without the guard is the
one-bug-at-a-time pattern this epic exists to end.

WHY A GUARD, AND WHY LAST

Nothing in CI answered "does any shipped surface still present a retired
runtime as live?", and the two gates that look like they should cannot.
checkReviewerDocsParity is one-directional: it asserts the PRESENCE of every
declared reviewer flag and never the ABSENCE of a retired one, so in #4716 it
reported 0 violations while all four locale mirrors still documented --gemini
as a live reviewer flag, with usage examples. And
tests/gemini-runtime-removed.test.cjs is scoped by construction - its own
docblock limits it to the installer CLI contract and the runtime-name-policy
exports; it never reads docs/**, gsd-core/workflows/**, commands/** or
agents/**. Every extension to it during this epic was a hand-added assertion
for a surface somebody had already noticed.

A guard written earlier would have red-flagged the very references phases
1b-4b were removing, which is why it lands last.

PART A - THE RESIDUE, INCLUDING WORK I SHIPPED INCOMPLETE

Each site was judged against its ENGLISH counterpart, not on its own:

  README.{ja-JP,ko-KR,pt-BR,zh-CN}.md :9 :24 :46  English README.md has ZERO
                                                  occurrences -> substituted
                                                  "Antigravity CLI, Kimi CLI"
  how-to/execute-a-phase.md:88  x4 locales        fixed in #4728 -> substitute
  how-to/verify-and-ship.md:89  x4 locales        fixed in #4728 -> substitute
  FEATURES.md cross-AI CLI list                   :1419 no Gemini -> DELETE
  FEATURES.md REQ-MULTI-RT-01                     :1709 -> substitute
  FEATURES.md REQ-SKILLS-03                       :1952 -> rewrite
  FEATURES.md REQ-QUOTA-02                        :3256 deleted upstream -> delete
  VERSIONING.md:133                               stale manifest -> see below

The twelve README occurrences were an adversarial reviewer's BLOCKER, and the
reason they survived my own sweep is structural: root-level *.md was outside
the guard's scan set, so the repo's most-read runtime-advertising surface was
invisible to the guard meant to police it. :46 is a live installer-runtime
claim - it tells the reader the installer will offer a runtime that no longer
exists. Checked for the duplicate-name trap before substituting: neither
Antigravity nor Kimi appears anywhere in those four files.

Two of these are mine to own: I fixed the ENGLISH execute-a-phase.md and
verify-and-ship.md in #4728 and left all four mirrors behind. Unfinished work,
not a deferral.

Two more show why "substitute Gemini -> Antigravity" is the wrong default: in
the cross-AI list and REQ-QUOTA-02 English DELETES the name, because
Antigravity was already in the list or the classifier had dropped it.
Substituting would have duplicated a name - the identical trap
ARCHITECTURE.md:24 set in #4728, where English holds Kimi CLI in that slot.

VERSIONING.md:133 is a different and worse defect than translation lag. Under
"Manifest Version Sync" it listed gemini-extension.json as a version-synced
manifest. That file is ABSENT from the repo, and
scripts/sync-manifest-versions.cjs says so in its own comment - "#1928:
gemini-extension.json was removed with the gemini runtime ... it is no longer
a registered manifest" - while VERSIONED_MANIFESTS holds plugin.json,
marketplace.json and vscode/package.json. So the doc named a manifest that
does not exist AND omitted the one that replaced it. Both fixed, verified
against the owning code rather than inferred from the name. The replacement
bullet cites #1942, the issue that actually registered vscode/package.json,
matching the convention of its neighbours.

pt-BR/FEATURES.md is a 77-line stub genuinely lacking two sites, and ko-KR has
no REQ-QUOTA-02 line. Skipped and recorded, never invented.

PART B - THE GUARD

scripts/lint-retired-runtime-name.cjs, modelled on
scripts/lint-legacy-dir-name.cjs - the repo's own precedent for this problem
shape (forbid a retired token, allowlist frozen content, self-exempt via a
split literal, a REPO_ROOT test seam, lib/cli-exit.cjs, exit 0/1).

Case sensitivity IS the mechanism, not an accident. The naive guard - "the
string gemini must not appear" - is WRONG, not merely noisy: that string is
load-bearing across Antigravity's real on-disk contract. A case-sensitive,
standalone, capitalised name works because every legitimate reference is
spelled differently and therefore cannot match: lowercase config homes
(~/.gemini/antigravity, ~/.gemini/config, #3738), lowercase hyphenated model
ids (gemini-2.5-flash-lite), uppercase env vars (GEMINI_API_KEY), and
GEMINI.md. Table-driven, so the next retired runtime costs one row.

THE ALLOWLIST IS THE ENTIRE RISK SURFACE, so it is three tiers, not one. Two
rounds of isolated adversarial review reshaped it; both are recorded in
.gsd/bug/chore-4729-gemini-drift-guard/60-review.json.

ROUND 2 FOUND ONE ROOT CAUSE BEHIND TWO SEPARATE HOLES, and it was mine: both
Tier-1 rules treated the ABSENCE of a runtime word as a GRANT. A veto list can
never be complete, so "no runtime word found" silently exempted every phrasing
nobody had enumerated. Demonstrated: `The installer now offers Gemini 3.`,
`Supported agents include Gemini 3, Kimi, and Cursor.` and three more exited 0,
as did `Suportamos Gemini, no estilo padrao, como runtime de instalacao.` and
`Gemini 兼容，并且是受支持的运行时之一。`, both of which literally contain `runtime`
or `运行时`. The fix was to stop enumerating exceptions and invert the evidence
direction:

  Tier 1(a) - the hook DIALECT Antigravity inherits. Position is
  language-dependent and MEASURED: en Gemini-style/-compatible, ja Gemini
  スタイル, ko Gemini 스타일/호환, zh Gemini 风格 / 与 Gemini 兼容的, pt "no estilo
  Gemini" / "compatível com Gemini" where the qualifier PRECEDES the name. The
  marker must now form an ADJACENT COMPOUND with the name, not merely sit in a
  +/-24-character window - that window let `| Antigravity | Gemini-style hooks
  | Gemini support is live |` exit 0, one legitimate reference licensing a
  fresh live claim 21 characters later. The runtime-word veto is now
  LINE-GLOBAL. Ten real lines legitimately pair a dialect compound with a
  runtime word (`~/.gemini/antigravity-cli` in a table cell, "runtime files"
  in the same sentence); each is an explicit pin rather than a reason to
  loosen the veto for everyone. Measured: widening it surfaced exactly those
  ten and no others.

  Tier 1(b) - the provider/model axis. A version optionally followed by a
  qualifier, including full-width digits and CJK punctuation, AND positive
  model-axis evidence on the line, AND no runtime word. The positive
  requirement is the part that matters: all eight real model-axis lines in the
  repo name a model explicitly, so requiring it costs nothing on the real tree
  while flagging every laundering attempt. It is also the honest resolution of
  the agent/target tension below - rather than guess at an exhaustive veto
  list, stop treating an empty veto as evidence.

  Tier 2 - PINNED OCCURRENCES, now SPAN-SCOPED. A pin excuses only a match
  falling INSIDE an occurrence of its own snippet. Line-level containment let
  `Known provider menu update: Gemini CLI is once again a selectable GSD
  runtime.` and `Install target: Google (Gemini) - choose Gemini CLI as your
  GSD runtime.` both exit 0, because a short snippet elsewhere on the line
  pre-approved a brand-new claim. Span scoping makes short snippets safe:
  `Google (Gemini)` can only ever excuse the match inside those 15 characters.
  A LOAD-TIME validator now requires every pin to contain a retired name, and
  it immediately caught five of MY OWN pins whose snippets sat BESIDE the name
  rather than covering it - each would have shipped permanently inert and
  permanently reported stale. All pins were then reconciled in one pass.

  A pin is also marked used by PRESENCE on the line now, rather than only on
  the Tier-2 branch. Previously a pinned line that a general rule also matched
  never marked its pin used, producing a provably FALSE "no line matches
  pinned snippet" whose printed remedy told the maintainer to delete a pin
  that was still needed.

  Tier 3 - blanket trust, and a new occurrence inside it IS invisible.
  CHANGELOG.md and `.changeset/` - the rendered changelog and its source, one
  surface - plus six append-only directories. All 21 `.changeset/` hits were
  measured to be fragments DESCRIBING the retirement or a fix to it, 464 of
  them under archived/; a fragment can only describe what already shipped and
  is deleted at release, so pinning them would be friction with no signal. The
  cost is stated in the guard's own header rather than hidden.

THE SCAN SET IS NOW EVERY TRACKED *.md FILE (1165 read). The original prefix
list left `.github/`, `.changeset/`, `capabilities/`, `playbooks/` and
`references/` invisible - and `.changeset/*.md` renders into CHANGELOG.md, so a
live claim introduced there was invisible at BOTH ends.

The escape hatch must now carry a justification
(`gsd-allow-retired-runtime-name: <reason>`). A bare marker is rejected: it is
checked first, excuses the whole line, and the failure message advertises it,
so an unexplained one is indistinguishable from a silenced defect.

Plus an anti-vacuity floor counting files actually READ, not files listed - a
candidate count stays healthy-looking even if every read failed.

A FALSE NEGATIVE I INTRODUCED, AND CLOSED

The model-display escape began as a blanket /^ \d/ - "space then a digit" -
which also matched "Install for Gemini 2.5 CLI as a supported runtime.",
laundering a genuine stale-runtime claim through an attached version number.

That was the THIRD appearance of one failure shape in this epic: an exclusion
added to suppress false positives creating a false negative. #4716's sweep
excluded lines matching gemini-[0-9] to spare Google's model ids, and thereby
hid a stale review.models.gemini row whose example value was "gemini-2.5-pro"
ON THE SAME LINE. Round 2 then produced the FOURTH and FIFTH instances, which
is why the fix this time was to invert the rule's evidence direction rather
than to enumerate more exceptions.

The veto is word-anchored for Latin terms - unanchored, case-insensitive "CLI"
matched inside "client" and would have vetoed legitimate model lists - and raw
for CJK terms, where \b is ASCII-word-based and would never fire beside an
ideograph, so anchoring them would silently disable the veto in ja/ko/zh.
"agent" and "target" were deliberately left OUT: both occur throughout
ordinary prose ("AI coding agents (Claude Code, Codex, Gemini 2.5 Pro)"), so
vetoing on them would red correct content instead of catching runtime claims.
The reasoning is in the guard's comment, not just the omission - and Tier
1(b)'s positive-evidence requirement is what makes that omission safe, since
the rule no longer depends on the veto list being complete.

COVERAGE

tests/lint-retired-runtime-name.test.cjs drives the guard through its
GSD_LINT_RETIRED_RUNTIME_REPO_ROOT seam against fixture repos, mirroring
tests/lint-legacy-dir-name.test.cjs. A guard never observed failing is not a
guard, and this epic already shipped one that was vacuous for 2 of its 5
files, so properties are paired against BOTH failure modes - too broad
silently absorbs a future defect, too narrow reds on legitimate content. Floor
boundaries are covered at 149/150/151.

The round-2 reviewer's sharpest point was about that claim, and it was right:
the first matrix's pairing was "true of the properties chosen, not of the
predicate's actual surface" - not one of its twenty properties could see the
dialect adjacency hole, a non-adjacent runtime word, pin shadowing, or an
over-broad pin colliding with a new line. Every one of those is now a
committed regression using the reviewer's own attack line verbatim, and the
local fixture harness went from 14 cases to 35 (PASS=35 FAIL=0).

That harness earned a finding of its own. Its first run reported PASS=2
FAIL=12 with BOTH passes VACUOUS: `git add` has no -q flag on this build, so
nothing staged, every fixture hit the empty-walk error path, and the two
checks that assert an ABSENCE passed off that error path rather than off real
guard logic. A staging failure is now fatal and every absence-asserting check
first proves the walk ran and the expected violation was flagged. Later, one
case failed because its fixture supplied only one of a pinned file's two
approved lines, so the stale-pin check fired correctly - the expectation was
wrong, not the guard. Telling those two apart is the whole value of running a
matrix rather than reasoning about one.

On the two orthogonal reviews: the isolated adversarial pass executed a great
deal of code, across two rounds, against its own fixture repos. The security
pass did NOT - it self-discloses that it verified by reading only, because
node --test is hard-blocked here. Saying so plainly, because "two orthogonal
reviews" without that caveat overstates what the second one established. It
also raised, and I cleared by measurement, a concern that importing
escapeRegex from a gitignored build artifact would break lint:ci on an unbuilt
clone: six other tracked scripts already require that exact path, three of
them already in lint:ci, and .github/workflows/test.yml:192-193 runs
`npm run build:lib` immediately before it for exactly this reason.

Part A has no new test deliberately - those edits are covered by the guard
itself inside lint:ci, and a separate per-locale assertion would duplicate it
and then drift from it. The one exception is the root README case, which IS
pinned: that residue was invisible to the guard rather than merely unasserted,
so the fix is a scan-set change and needs its own regression test.

No mode-bit read-failure fixture was added on purpose: the benches run as
root, where chmod-based IO injection is vacuous, so such a test would assert
nothing.

The test's fixture helpers write throwaway docs/ paths, which trips
lint-docs-guard-registration's reader-name heuristic. Resolved the way that
lint documents - a header `// docs-guard-exempt:` marker plus a baseline entry
- because the fixtures only WRITE scratch data and never read shipped docs;
the baseline was re-confirmed, not merely extended, each time locale and
adversarial fixtures were added. scripts/lib/macos-conformance-tier.generated.cjs
regenerated through its own --write path, since a new test file changes the
count lint:generated-sync reads.

Fixes #4729

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* chore(#4729): backfill changeset PR number (#4753)

---------

Co-authored-by: sim <sim@local>
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>

2026-09-14 20:50:26 -04:00

195 KiB

Raw Blame History

GSD 機能リファレンス

全機能と要件の完全なドキュメントです。アーキテクチャの詳細についてはアーキテクチャを、コマンド構文についてはコマンドリファレンスをご覧ください。

コア機能
プランニング機能
品質保証機能
コンテキストエンジニアリング機能
ブラウンフィールド機能
- コードベースマッピング
- 既存コードベースオンボーディング
ユーティリティ機能
インフラストラクチャ機能
v1.27 の機能
v1.28 の機能
v1.29 の機能
- Windsurf ランタイムサポート
- 国際化ドキュメント
v1.31 の機能
v1.32 の機能
v1.34.0 の機能
v1.35.0 の機能
v1.36.0 の機能
v1.37.0 の機能
v1.40.0 の機能
v1.41.0 の機能
v1.42.1 の機能

コア機能

1. プロジェクト初期化

コマンド: /gsd-new-project [--auto @file.md]

目的: ユーザーのアイデアを、リサーチ、スコープ化された要件、フェーズ分けされたロードマップを持つ完全に構造化されたプロジェクトに変換します。

要件:

REQ-INIT-01: システムはプロジェクトスコープが完全に理解されるまで適応的な質問を実施しなければならない
REQ-INIT-02: システムはドメインエコシステムを調査するために並列リサーチエージェントを起動しなければならない
REQ-INIT-03: システムは要件を v1（必須）、v2（将来）、スコープ外のカテゴリに分類しなければならない
REQ-INIT-04: システムは要件トレーサビリティ付きのフェーズ分けされたロードマップを生成しなければならない
REQ-INIT-05: システムは続行前にロードマップのユーザー承認を要求しなければならない
REQ-INIT-06: .planning/PROJECT.md が既に存在する場合、システムは再初期化を防止しなければならない
REQ-INIT-07: システムは --auto @file.md フラグをサポートし、インタラクティブな質問をスキップしてドキュメントから情報を抽出しなければならない

生成物:

成果物	説明
`PROJECT.md`	プロジェクトビジョン、制約、技術的決定、発展ルール
`REQUIREMENTS.md`	一意の ID（REQ-XX）付きのスコープ化された要件
`ROADMAP.md`	ステータス追跡と要件マッピング付きのフェーズ分割
`STATE.md`	ポジション、決定事項、メトリクスを含む初期プロジェクト状態
`config.json`	ワークフロー設定
`research/SUMMARY.md`	統合されたドメインリサーチ
`research/STACK.md`	技術スタック調査
`research/FEATURES.md`	機能実装パターン
`research/ARCHITECTURE.md`	アーキテクチャパターンとトレードオフ
`research/PITFALLS.md`	よくある失敗パターンと対策

プロセス:

質問 — 「ドリーム抽出」の哲学に基づく適応的な質問（要件収集ではなく）
リサーチ — 4つの並列リサーチャーエージェントがスタック、機能、アーキテクチャ、落とし穴を調査
統合 — リサーチシンセサイザーが調査結果を SUMMARY.md に統合
要件 — ユーザーの回答とリサーチから要件を抽出し、スコープ別に分類
ロードマップ — 要件にマッピングされたフェーズ分割、粒度設定によりフェーズ数を制御

機能要件:

質問は検出されたプロジェクトタイプ（Web アプリ、CLI、モバイル、API など）に応じて適応する
リサーチエージェントは最新のエコシステム情報を取得するための Web 検索機能を持つ
粒度設定によりフェーズ数を制御: coarse（3-5）、standard（5-8）、fine（8-12）
--auto モードではインタラクティブな質問なしで提供されたドキュメントからすべての情報を抽出
既存のコードベースコンテキスト（/gsd-map-codebase から取得）がある場合は読み込む

2. フェーズディスカッション

コマンド: /gsd-discuss-phase [N] [--auto] [--batch]

目的: リサーチとプランニング開始前に、ユーザーの実装に関する要望や決定事項を収集します。AI が推測する原因となるグレーゾーンを排除します。

要件:

REQ-DISC-01: システムはフェーズのスコープを分析し、決定が必要な領域（グレーゾーン）を特定しなければならない
REQ-DISC-02: システムはグレーゾーンをタイプ別に分類しなければならない（ビジュアル、API、コンテンツ、構成など）
REQ-DISC-03: システムは過去の CONTEXT.md ファイルで既に回答済みの質問のみを除外しなければならない
REQ-DISC-04: システムは決定事項を {phase}-CONTEXT.md に正規参照付きで永続化しなければならない
REQ-DISC-05: システムは推奨デフォルトを自動選択する --auto フラグをサポートしなければならない
REQ-DISC-06: システムはグループ化された質問取り込みのための --batch フラグをサポートしなければならない
REQ-DISC-07: システムはグレーゾーンを特定する前に関連ソースファイルをスカウトしなければならない（コード認識型ディスカッション）
REQ-DISC-08: USER-PROFILE.md が非技術的なオーナーを示す場合（learning_style: guided、frustration_triggers にジャーゴン、または高レベルの説明深度）、システムはグレーエリアの言語を製品アウトカム用語に適応しなければならない
REQ-DISC-09: REQ-DISC-08 が適用される場合、advisor_research の根拠段落は平易な言語で書き直されなければならない — 同じ決定、翻訳されたフレーミング

生成物: {padded_phase}-CONTEXT.md — リサーチとプランニングに反映されるユーザーの要望

グレーゾーンカテゴリ:

カテゴリ	決定事項の例
ビジュアル機能	レイアウト、密度、インタラクション、空状態
API/CLI	レスポンス形式、フラグ、エラーハンドリング、詳細度
コンテンツシステム	構造、トーン、深さ、フロー
構成	グルーピング基準、命名、重複、例外

3. UI デザインコントラクト

コマンド: /gsd-ui-phase [N]

目的: プランニング前にデザインの決定事項を確定し、フェーズ内のすべてのコンポーネントが一貫したビジュアル基準を共有できるようにします。

要件:

REQ-UI-01: システムは既存のデザインシステムの状態を検出しなければならない（shadcn の components.json、Tailwind 設定、トークン）
REQ-UI-02: システムは未回答のデザインコントラクトの質問のみを行わなければならない
REQ-UI-03: システムは7つの次元（コピーライティング、ビジュアル、カラー、タイポグラフィ、スペーシング、レジストリセーフティ、インベントリプロビナンス）に対してバリデーションしなければならない
REQ-UI-04: バリデーションが BLOCKED を返した場合、システムはリビジョンループに入らなければならない（最大2回の反復）
REQ-UI-05: components.json のない React/Next.js/Vite プロジェクトに対して、システムは shadcn の初期化を提案しなければならない
REQ-UI-06: システムはサードパーティの shadcn レジストリに対してレジストリセーフティゲートを適用しなければならない

生成物: {padded_phase}-UI-SPEC.md — エグゼキューターが参照するデザインコントラクト

7つのバリデーション次元:

コピーライティング — CTA ラベル、空状態、エラーメッセージ
ビジュアル — フォーカルポイント、視覚的階層構造、アイコンのアクセシビリティ
カラー — アクセントカラーの使用規律、60/30/10 準拠
タイポグラフィ — フォントサイズ/ウェイトの制約遵守
スペーシング — グリッド配置、トークンの一貫性
レジストリセーフティ — サードパーティコンポーネントの検査要件
インベントリプロビナンス — コンポーネントインベントリがインストール済みのデザインシステムから列挙されたものであり、記憶に頼っていないこと

shadcn 連携:

React/Next.js/Vite プロジェクトで components.json が欠落していることを検出
ユーザーを ui.shadcn.com/create のプリセット設定にガイド
プリセット文字列はフェーズ間で再現可能なプランニング成果物になる
セーフティゲートにより、サードパーティコンポーネント使用前に npx shadcn view と npx shadcn diff が必要

4. フェーズプランニング

コマンド: /gsd-plan-phase [N] [--auto] [--skip-research] [--skip-verify]

目的: 実装ドメインをリサーチし、検証済みのアトミックな実行プランを作成します。

要件:

REQ-PLAN-01: システムは実装アプローチを調査するフェーズリサーチャーを起動しなければならない
REQ-PLAN-02: システムはそれぞれ2〜3タスクのプランを作成しなければならず、各タスクは1つのコンテキストウィンドウに収まるサイズとする
REQ-PLAN-03: システムはプランを XML で構造化しなければならない。<task> 要素には name、files、action、verify、done フィールドを含む
REQ-PLAN-04: システムはすべてのプランに read_first と acceptance_criteria セクションを含めなければならない
REQ-PLAN-05: --skip-verify が設定されていない限り、システムはプランチェッカー検証ループ（最大3回の反復）を実行しなければならない
REQ-PLAN-06: システムはリサーチフェーズをバイパスする --skip-research フラグをサポートしなければならない
REQ-PLAN-07: フロントエンドフェーズが検出され UI-SPEC.md が存在しない場合、システムはユーザーに /gsd-ui-phase の実行を促さなければならない（UI セーフティゲート）
REQ-PLAN-08: workflow.nyquist_validation が有効な場合、システムは Nyquist バリデーションマッピングを含めなければならない
REQ-PLAN-09: プランニング完了前に、すべてのフェーズ要件が少なくとも1つのプランでカバーされていることをシステムは検証しなければならない（要件カバレッジゲート）

生成物:

成果物	説明
`{phase}-RESEARCH.md`	エコシステムリサーチの結果
`{phase}-{N}-PLAN.md`	アトミックな実行プラン（各2〜3タスク）
`{phase}-VALIDATION.md`	テストカバレッジマッピング（Nyquist レイヤー）

プラン構造（XML）:

<task type="auto">
  <name>Create login endpoint</name>
  <files>src/app/api/auth/login/route.ts</files>
  <action>
    Use jose for JWT. Validate credentials against users table.
    Return httpOnly cookie on success.
  </action>
  <verify>curl -X POST localhost:3000/api/auth/login returns 200 + Set-Cookie</verify>
  <done>Valid credentials return cookie, invalid return 401</done>
</task>

プランチェッカー検証（8つの次元）:

要件カバレッジ — プランがすべてのフェーズ要件に対応しているか
タスクのアトミック性 — 各タスクが独立してコミット可能か
依存関係の順序 — タスクが正しい順序で並んでいるか
ファイルスコープ — プラン間で過度なファイルの重複がないか
検証コマンド — 各タスクにテスト可能な完了基準があるか
コンテキストフィット — タスクが1つのコンテキストウィンドウに収まるか
ギャップ検出 — 実装ステップに欠落がないか
Nyquist 準拠 — タスクに自動化された検証コマンドがあるか（有効時）

5. フェーズ実行

コマンド: /gsd-execute-phase <N>

目的: ウェーブベースの並列化を使用して、フェーズ内のすべてのプランを実行します。各エグゼキューターにはフレッシュなコンテキストウィンドウが割り当てられます。

要件:

REQ-EXEC-01: システムはプランの依存関係を分析し、実行ウェーブにグループ化しなければならない
REQ-EXEC-02: システムは各ウェーブ内で独立したプランを並列実行しなければならない
REQ-EXEC-03: システムは各エグゼキューターにフレッシュなコンテキストウィンドウ（200K トークン）を付与しなければならない
REQ-EXEC-04: システムはタスクごとにアトミックな git コミットを生成しなければならない
REQ-EXEC-05: システムは完了した各プランに対して SUMMARY.md を生成しなければならない
REQ-EXEC-06: システムはフェーズ目標が達成されたかを確認する実行後検証を実行しなければならない
REQ-EXEC-07: システムは git ブランチ戦略（none、phase、milestone）をサポートしなければならない
REQ-EXEC-08: タスク検証失敗時、システムはノードリペアオペレーターを呼び出さなければならない（有効時）
REQ-EXEC-09: システムはクロスフェーズ回帰を検出するため、検証前に過去のフェーズのテストスイートを実行しなければならない

生成物:

成果物	説明
`{phase}-{N}-SUMMARY.md`	プランごとの実行結果
`{phase}-VERIFICATION.md`	実行後検証レポート
Git コミット	タスクごとのアトミックなコミット

ウェーブ実行:

依存関係のないプラン → ウェーブ 1（並列）
ウェーブ 1 に依存するプラン → ウェーブ 2（並列、ウェーブ 1 完了を待機）
すべてのプランが完了するまで継続
ファイル競合がある場合、同一ウェーブ内で順次実行を強制

エグゼキューターの機能:

完全なタスク指示を含む PLAN.md を読み取り
PROJECT.md、STATE.md、CONTEXT.md、RESEARCH.md にアクセス可能
構造化されたコミットメッセージで各タスクをアトミックにコミット
並列実行中のビルドロック競合を回避するため、コミット時に --no-verify を使用
チェックポイントタイプに対応: auto、checkpoint:human-verify、checkpoint:decision、checkpoint:human-action
プランからの逸脱を SUMMARY.md に報告

並列安全性:

pre-commit フック: 並列エージェントではスキップ（--no-verify）、各ウェーブ後にオーケストレーターが一度実行
STATE.md ロック: ファイルレベルのロックファイルにより、エージェント間の同時書き込みによるデータ破損を防止

6. 作業検証

コマンド: /gsd-verify-work [N]

目的: ユーザー受け入れテスト — 各成果物のテストをユーザーに順に案内し、失敗を自動診断します。

要件:

REQ-VERIFY-01: システムはフェーズからテスト可能な成果物を抽出しなければならない
REQ-VERIFY-02: システムは成果物をユーザー確認のために1つずつ提示しなければならない
REQ-VERIFY-03: システムは失敗を自動診断するためにデバッグエージェントを起動しなければならない
REQ-VERIFY-04: システムは特定された問題に対する修正プランを作成しなければならない
REQ-VERIFY-05: サーバー/データベース/シード/スタートアップファイルを変更するフェーズに対して、システムはコールドスタートスモークテストを注入しなければならない
REQ-VERIFY-06: システムは合否結果を含む UAT.md を生成しなければならない

生成物: {phase}-UAT.md — ユーザー受け入れテスト結果、問題が見つかった場合は修正プランも含む

6.5. Ship

コマンド: /gsd-ship [N] [--draft]

目的: ローカル完了からマージ済み PR への橋渡し。検証通過後、ブランチをプッシュし、プランニング成果物から自動生成された本文で PR を作成します。オプションでレビューをトリガーし、STATE.md で追跡します。

要件:

REQ-SHIP-01: システムはシッピング前にフェーズが検証を通過していることを確認しなければならない
REQ-SHIP-02: システムは gh CLI を使用してブランチをプッシュし PR を作成しなければならない
REQ-SHIP-03: システムは SUMMARY.md、VERIFICATION.md、REQUIREMENTS.md から PR 本文を自動生成しなければならない
REQ-SHIP-04: システムは STATE.md をシッピングステータスと PR 番号で更新しなければならない
REQ-SHIP-05: システムはドラフト PR のための --draft フラグをサポートしなければならない
REQ-SHIP-06: システムは ship.pr_body_sections で設定された追記専用プロジェクト PR ボディセクションをサポートしなければならない

前提条件: フェーズ検証済み、gh CLI がインストール・認証済み、フィーチャーブランチで作業中

生成物: リッチな本文を持つ GitHub PR、STATE.md の更新

7. UI レビュー

コマンド: /gsd-ui-review [N]

目的: 実装済みフロントエンドコードに対する遡及的な6本柱のビジュアル監査。任意のプロジェクトでスタンドアロンで動作します。

要件:

REQ-UIREVIEW-01: システムは6つの柱それぞれを1〜4のスケールで評価しなければならない
REQ-UIREVIEW-02: システムは Playwright CLI を使用して .planning/ui-reviews/ にスクリーンショットをキャプチャしなければならない
REQ-UIREVIEW-03: システムはスクリーンショットディレクトリ用の .gitignore を作成しなければならない
REQ-UIREVIEW-04: システムは優先度の高い修正トップ3を特定しなければならない
REQ-UIREVIEW-05: システムは（UI-SPEC.md なしで）抽象的な品質基準を使用してスタンドアロンで動作しなければならない

6つの監査柱（1〜4で評価）:

コピーライティング — CTA ラベル、空状態、エラー状態
ビジュアル — フォーカルポイント、視覚的階層構造、アイコンのアクセシビリティ
カラー — アクセントカラーの使用規律、60/30/10 準拠
タイポグラフィ — フォントサイズ/ウェイトの制約遵守
スペーシング — グリッド配置、トークンの一貫性
エクスペリエンスデザイン — ローディング/エラー/空状態のカバレッジ

生成物: {padded_phase}-UI-REVIEW.md — スコアと優先度付き修正リスト

8. マイルストーン管理

コマンド: /gsd-audit-milestone、/gsd-complete-milestone、/gsd-new-milestone [name]

目的: マイルストーンの完了を検証し、アーカイブし、リリースにタグを付け、次の開発サイクルを開始します。

要件:

REQ-MILE-01: 監査はすべてのマイルストーン要件が満たされていることを検証しなければならない
REQ-MILE-02: 監査はスタブ、プレースホルダー実装、未テストコードを検出しなければならない
REQ-MILE-03: 監査はフェーズ間の Nyquist バリデーション準拠をチェックしなければならない
REQ-MILE-04: 完了時にマイルストーンデータを MILESTONES.md にアーカイブしなければならない
REQ-MILE-05: 完了時にリリース用の git タグ作成を提案しなければならない
REQ-MILE-06: 完了時にブランチ戦略に応じてスカッシュマージまたは履歴付きマージを提案しなければならない
REQ-MILE-07: 完了時に UI レビューのスクリーンショットをクリーンアップしなければならない
REQ-MILE-08: 新しいマイルストーンは new-project と同じフロー（質問 → リサーチ → 要件 → ロードマップ）に従わなければならない
REQ-MILE-09: 新しいマイルストーンは既存のワークフロー設定をリセットしてはならない

プランニング機能

9. フェーズ管理

コマンド: /gsd-phase、/gsd-phase --insert [N]、/gsd-phase --remove [N]

目的: 開発中のロードマップの動的な変更。

要件:

REQ-PHASE-01: 追加は現在のロードマップの末尾に新しいフェーズを追加しなければならない
REQ-PHASE-02: 挿入は既存フェーズ間に小数番号（例: 3.1）を使用しなければならない
REQ-PHASE-03: 削除は後続のすべてのフェーズを再番号付けしなければならない
REQ-PHASE-04: 削除は既に実行されたフェーズの削除を防止しなければならない
REQ-PHASE-05: すべての操作は ROADMAP.md を更新し、フェーズディレクトリを作成/削除しなければならない

10. Quick モード

コマンド: /gsd-quick [--full] [--discuss] [--research]

目的: GSD の保証を維持しながら、より高速なパスでアドホックなタスクを実行します。

要件:

REQ-QUICK-01: システムは自由形式のタスク説明を受け付けなければならない
REQ-QUICK-02: システムはフルワークフローと同じプランナー＋エグゼキューターエージェントを使用しなければならない
REQ-QUICK-03: システムはデフォルトでリサーチ、プランチェッカー、検証をスキップしなければならない
REQ-QUICK-04: --full フラグはプランチェック（最大2回の反復）と実行後検証を有効にしなければならない
REQ-QUICK-05: --discuss フラグは軽量なプランニング前ディスカッションを実行しなければならない
REQ-QUICK-06: --research フラグはプランニング前にフォーカスされたリサーチエージェントを起動しなければならない
REQ-QUICK-07: フラグは組み合わせ可能でなければならない（--discuss --research --full）
REQ-QUICK-08: システムは Quick タスクを .planning/quick/YYMMDD-xxx-slug/ で追跡しなければならない
REQ-QUICK-09: システムは Quick タスク実行時にアトミックなコミットを生成しなければならない

11. 自律モード

コマンド: /gsd-autonomous [--from N]

目的: 残りのすべてのフェーズを自律的に実行します — フェーズごとにディスカッション → プラン → 実行を行います。

要件:

REQ-AUTO-01: システムはロードマップの順序で未完了のすべてのフェーズを反復処理しなければならない
REQ-AUTO-02: システムは各フェーズに対してディスカッション → プラン → 実行を実行しなければならない
REQ-AUTO-03: システムは明示的なユーザー判断が必要な場面（グレーゾーンの承認、ブロッカー、バリデーション）で一時停止しなければならない
REQ-AUTO-04: システムは各フェーズ後に ROADMAP.md を再読み込みし、動的に挿入されたフェーズを検出しなければならない
REQ-AUTO-05: --from N フラグは特定のフェーズ番号から開始しなければならない

12. フリーフォームルーティング

コマンド: /gsd-fast

目的: 自由形式のテキストを分析し、適切な GSD コマンドにルーティングします。

要件:

REQ-DO-01: システムは自然言語入力からユーザーの意図を解析しなければならない
REQ-DO-02: システムは意図を最も適切な GSD コマンドにマッピングしなければならない
REQ-DO-03: システムは実行前にルーティング結果をユーザーに確認しなければならない
REQ-DO-04: システムはプロジェクト既存 vs プロジェクト未作成のコンテキストを区別して処理しなければならない

13. ノートキャプチャ

コマンド: /gsd-capture

目的: ワークフローを中断することなくアイデアを記録する、摩擦ゼロのメモ機能。タイムスタンプ付きメモの追加、全メモの一覧表示、または構造化された Todo へのプロモーションが可能です。

要件:

REQ-NOTE-01: システムは1回の Write 呼び出しでタイムスタンプ付きメモファイルを保存しなければならない
REQ-NOTE-02: システムはプロジェクトスコープとグローバルスコープからすべてのメモを表示する list サブコマンドをサポートしなければならない
REQ-NOTE-03: システムはメモを構造化された Todo に変換する promote N サブコマンドをサポートしなければならない
REQ-NOTE-04: システムはグローバルスコープ操作のための --global フラグをサポートしなければならない
REQ-NOTE-05: システムは Task、AskUserQuestion、Bash を使用してはならない — インラインでのみ実行

14. 自動進行（Next）

コマンド: /gsd-progress --next

目的: 現在のプロジェクト状態を自動検出し、次の論理的なワークフローステップに進めます。どのフェーズ/ステップにいるかを覚えておく必要がなくなります。

要件:

REQ-NEXT-01: システムは STATE.md、ROADMAP.md、フェーズディレクトリを読み取り、現在のポジションを判定しなければならない
REQ-NEXT-02: システムはディスカッション、プラン、実行、検証のいずれが必要かを検出しなければならない
REQ-NEXT-03: システムは適切なコマンドを自動的に呼び出さなければならない
REQ-NEXT-04: プロジェクトが存在しない場合、システムは /gsd-new-project を提案しなければならない
REQ-NEXT-05: すべてのフェーズが完了している場合、システムは /gsd-complete-milestone を提案しなければならない

状態検出ロジック:

状態	アクション
`.planning/` ディレクトリなし	`/gsd-new-project` を提案
フェーズに CONTEXT.md がない	`/gsd-discuss-phase` を実行
フェーズに PLAN.md ファイルがない	`/gsd-plan-phase` を実行
プランはあるが SUMMARY.md がない	`/gsd-execute-phase` を実行
実行済みだが VERIFICATION.md がない	`/gsd-verify-work` を実行
すべてのフェーズが完了	`/gsd-complete-milestone` を提案

品質保証機能

15. Nyquist バリデーション

目的: コード記述前に、フェーズ要件に対する自動テストカバレッジをマッピングします。Nyquist サンプリング定理にちなんで命名 — すべての要件に対してフィードバック信号が存在することを保証します。

要件:

REQ-NYQ-01: システムは plan-phase リサーチ中に既存のテストインフラを検出しなければならない
REQ-NYQ-02: システムは各要件を特定のテストコマンドにマッピングしなければならない
REQ-NYQ-03: システムはウェーブ 0 タスク（実装前に必要なテストスキャフォールディング）を特定しなければならない
REQ-NYQ-04: プランチェッカーは Nyquist 準拠を8番目の検証次元として適用しなければならない
REQ-NYQ-05: システムは /gsd-validate-phase による遡及的バリデーションをサポートしなければならない
REQ-NYQ-06: システムは workflow.nyquist_validation: false で無効化可能でなければならない

生成物: {phase}-VALIDATION.md — テストカバレッジコントラクト

遡及的バリデーション（/gsd-validate-phase [N]）:

実装をスキャンし、要件をテストにマッピング
自動検証がない要件のギャップを特定
テストを生成するオーディターを起動（最大3回試行）
実装コードは決して変更しない — テストファイルと VALIDATION.md のみ
実装バグはユーザーが対処すべきエスカレーションとしてフラグ付け

16. プランチェック

目的: プランがフェーズ目標を達成するかを、実行前にゴールバックワード方式で検証します。

要件:

REQ-PLANCK-01: システムは8つの品質次元に対してプランを検証しなければならない
REQ-PLANCK-02: システムはプランが合格するまで最大3回の反復をループしなければならない
REQ-PLANCK-03: システムは失敗に対して具体的かつ実行可能なフィードバックを提供しなければならない
REQ-PLANCK-04: システムは workflow.plan_check: false で無効化可能でなければならない

17. 実行後検証

目的: コードベースがフェーズの約束を達成しているかを自動チェックします。

要件:

REQ-POSTVER-01: システムはタスク完了だけでなく、フェーズ目標に対してチェックしなければならない
REQ-POSTVER-02: システムは合否分析を含む VERIFICATION.md を生成しなければならない
REQ-POSTVER-03: システムは /gsd-verify-work が対処すべき問題をログに記録しなければならない
REQ-POSTVER-04: システムは workflow.verifier: false で無効化可能でなければならない

18. ノードリペア

目的: 実行中にタスク検証が失敗した場合の自律的な回復。

要件:

REQ-REPAIR-01: システムは失敗を分析し、RETRY、DECOMPOSE、PRUNE のいずれかの戦略を選択しなければならない
REQ-REPAIR-02: RETRY は具体的な調整を加えて再試行しなければならない
REQ-REPAIR-03: DECOMPOSE はタスクをより小さな検証可能なサブステップに分解しなければならない
REQ-REPAIR-04: PRUNE は達成不可能なタスクを削除し、ユーザーにエスカレーションしなければならない
REQ-REPAIR-05: システムはリペア予算を尊重しなければならない（デフォルト: タスクあたり2回の試行）
REQ-REPAIR-06: システムは workflow.node_repair_budget と workflow.node_repair で設定可能でなければならない

19. ヘルスバリデーション

コマンド: /gsd-health [--repair]

目的: .planning/ ディレクトリの整合性を検証し、問題を自動修復します。

要件:

REQ-HEALTH-01: システムは必須ファイルの欠落をチェックしなければならない
REQ-HEALTH-02: システムは設定の一貫性を検証しなければならない
REQ-HEALTH-03: システムはサマリーのない孤立したプランを検出しなければならない
REQ-HEALTH-04: システムはフェーズ番号とロードマップの同期をチェックしなければならない
REQ-HEALTH-05: --repair フラグは回復可能な問題を自動修正しなければならない

20. クロスフェーズ回帰ゲート

目的: 実行後に過去のフェーズのテストスイートを実行することで、フェーズ間での回帰の蓄積を防止します。

要件:

REQ-REGR-01: システムはフェーズ実行後に、完了済みの過去のすべてのフェーズのテストスイートを実行しなければならない
REQ-REGR-02: システムはテスト失敗をクロスフェーズ回帰として報告しなければならない
REQ-REGR-03: 回帰は実行後検証の前に表面化されなければならない
REQ-REGR-04: システムはどの過去フェーズのテストが壊れたかを特定しなければならない

実行タイミング: /gsd-execute-phase の検証ステップの前に自動実行されます。

21. 要件カバレッジゲート

目的: プランニング完了前に、すべてのフェーズ要件が少なくとも1つのプランでカバーされていることを保証します。

要件:

REQ-COVGATE-01: システムは ROADMAP.md からフェーズに割り当てられたすべての要件 ID を抽出しなければならない
REQ-COVGATE-02: システムは各要件が少なくとも1つの PLAN.md に含まれていることを検証しなければならない
REQ-COVGATE-03: カバーされていない要件はプランニング完了をブロックしなければならない
REQ-COVGATE-04: システムはどの特定の要件にプランカバレッジがないかを報告しなければならない

実行タイミング: /gsd-plan-phase の末尾、プランチェッカーループの後に自動実行されます。

コンテキストエンジニアリング機能

22. コンテキストウィンドウ監視

目的: コンテキストが不足し始めた際にユーザーとエージェントの両方にアラートを出し、コンテキストの劣化を防止します。

要件:

REQ-CTX-01: ステータスラインはユーザーにコンテキスト使用率をパーセンテージで表示しなければならない
REQ-CTX-02: コンテキストモニターは残量 35% 以下で（WARNING）エージェント向け警告を注入しなければならない
REQ-CTX-03: コンテキストモニターは残量 25% 以下で（CRITICAL）エージェント向け警告を注入しなければならない
REQ-CTX-04: 警告はデバウンスされなければならない（繰り返し警告間に5回のツール使用）
REQ-CTX-05: 重大度のエスカレーション（WARNING→CRITICAL）はデバウンスをバイパスしなければならない
REQ-CTX-06: コンテキストモニターは GSD アクティブ vs 非 GSD アクティブプロジェクトを区別しなければならない
REQ-CTX-07: 警告はアドバイザリーであり、ユーザーの意向を上書きする命令的なコマンドであってはならない
REQ-CTX-08: すべてのフックはサイレントに失敗し、ツール実行をブロックしてはならない

アーキテクチャ: 2部構成のブリッジシステム:

ステータスラインがメトリクスを /tmp/claude-ctx-{session}.json に書き込み
コンテキストモニターがメトリクスを読み取り、additionalContext 警告を注入

23. セッション管理

コマンド: /gsd-pause-work、/gsd-resume-work、/gsd-progress

目的: コンテキストリセットやセッション間でのプロジェクトの継続性を維持します。

要件:

REQ-SESSION-01: 一時停止は現在のポジションと次のステップを continue-here.md と構造化された HANDOFF.json に保存しなければならない
REQ-SESSION-02: 再開は HANDOFF.json（優先）または状態ファイル（フォールバック）から完全なプロジェクトコンテキストを復元しなければならない
REQ-SESSION-03: 進捗は現在のポジション、次のアクション、全体の完了状況を表示しなければならない
REQ-SESSION-04: 進捗はすべての状態ファイル（STATE.md、ROADMAP.md、フェーズディレクトリ）を読み取らなければならない
REQ-SESSION-05: すべてのセッション操作は /clear（コンテキストリセット）後も動作しなければならない
REQ-SESSION-06: HANDOFF.json にはブロッカー、保留中の人的アクション、進行中のタスク状態を含めなければならない
REQ-SESSION-07: 再開時にセッション開始直後に人的アクションとブロッカーを即座に表面化しなければならない

24. セッションレポート

コマンド: /gsd-pause-work --report

目的: 実施した作業、達成した成果、推定リソース使用量をキャプチャした、構造化されたセッション後のサマリードキュメントを生成します。

要件:

REQ-REPORT-01: システムは STATE.md、git log、プラン/サマリーファイルからデータを収集しなければならない
REQ-REPORT-02: システムは行ったコミット、実行したプラン、進行したフェーズを含めなければならない
REQ-REPORT-03: システムはセッションアクティビティに基づいてトークン使用量とコストを推定しなければならない
REQ-REPORT-04: システムはアクティブなブロッカーと行った決定事項を含めなければならない
REQ-REPORT-05: システムは次のステップを推奨しなければならない

生成物: .planning/reports/SESSION_REPORT.md

レポートセクション:

セッション概要（期間、マイルストーン、フェーズ）
実施した作業（コミット、プラン、フェーズ）
成果と成果物
ブロッカーと決定事項
リソース推定（トークン、コスト）
次のステップの推奨

25. マルチエージェントオーケストレーション

目的: 各タスクにフレッシュなコンテキストウィンドウを持つ専門エージェントを調整します。

要件:

REQ-ORCH-01: 各エージェントはフレッシュなコンテキストウィンドウを受け取らなければならない
REQ-ORCH-02: オーケストレーターは軽量でなければならない — エージェントを起動し、結果を収集し、次にルーティング
REQ-ORCH-03: コンテキストペイロードには関連するすべてのプロジェクト成果物を含めなければならない
REQ-ORCH-04: 並列エージェントは真に独立でなければならない（共有可変状態なし）
REQ-ORCH-05: エージェントの結果はオーケストレーターが処理する前にディスクに書き込まれなければならない
REQ-ORCH-06: 失敗したエージェントは検出されなければならない（実際の出力 vs 報告された失敗をスポットチェック）

26. モデルプロファイル

コマンド: /gsd-config --profile <quality|balanced|budget|inherit>

目的: 各エージェントが使用する AI モデルを制御し、品質とコストのバランスを取ります。

要件:

REQ-MODEL-01: システムは4つのプロファイルをサポートしなければならない: quality、balanced、budget、inherit
REQ-MODEL-02: 各プロファイルはエージェントごとのモデルティアを定義しなければならない（プロファイルテーブル参照）
REQ-MODEL-03: エージェントごとのオーバーライドはプロファイルより優先されなければならない
REQ-MODEL-04: inherit プロファイルはランタイムの現在のモデル選択に従わなければならない
REQ-MODEL-04a: 非 Anthropic プロバイダー（OpenRouter、ローカルモデル）を使用する場合、予期しない API コストを避けるために inherit プロファイルを使用しなければならない
REQ-MODEL-05: プロファイル切り替えはプログラマティックでなければならない（スクリプト、LLM 駆動ではない）
REQ-MODEL-06: モデル解決はオーケストレーションごとに1回のみ実行し、スポーンごとに実行してはならない

プロファイル割り当て:

エージェント	`quality`	`balanced`	`budget`	`inherit`
gsd-planner	Opus	Opus	Sonnet	Inherit
gsd-roadmapper	Opus	Sonnet	Sonnet	Inherit
gsd-executor	Opus	Sonnet	Sonnet	Inherit
gsd-phase-researcher	Opus	Sonnet	Haiku	Inherit
gsd-project-researcher	Opus	Sonnet	Haiku	Inherit
gsd-research-synthesizer	Sonnet	Sonnet	Haiku	Inherit
gsd-debugger	Opus	Sonnet	Sonnet	Inherit
gsd-codebase-mapper	Sonnet	Haiku	Haiku	Inherit
gsd-verifier	Sonnet	Sonnet	Haiku	Inherit
gsd-plan-checker	Sonnet	Sonnet	Haiku	Inherit
gsd-integration-checker	Sonnet	Sonnet	Haiku	Inherit
gsd-nyquist-auditor	Sonnet	Sonnet	Haiku	Inherit

ブラウンフィールド機能

27. コードベースマッピング

コマンド: /gsd-map-codebase [area]

目的: 新しいプロジェクトを開始する前、または /gsd-onboard からのマッピングハンドオフとして既存のコードベースを分析し、GSD が既存の構成を理解できるようにします。

要件:

REQ-MAP-01: システムは各分析領域に対して並列マッパーエージェントを起動しなければならない
REQ-MAP-02: システムは .planning/codebase/ に構造化されたドキュメントを生成しなければならない
REQ-MAP-03: システムは技術スタック、アーキテクチャパターン、コーディング規約、懸念事項を検出しなければならない
REQ-MAP-04: 後続の /gsd-new-project はコードベースマッピングを読み込み、追加する内容に焦点を当てた質問を行わなければならない
REQ-MAP-05: オプションの [area] 引数はマッピングを特定の領域にスコープしなければならない

生成物:

ドキュメント	内容
`STACK.md`	言語、フレームワーク、データベース、インフラストラクチャ
`ARCHITECTURE.md`	パターン、レイヤー、データフロー、境界
`CONVENTIONS.md`	命名、ファイル構成、コードスタイル、テストパターン
`CONCERNS.md`	技術的負債、セキュリティ問題、パフォーマンスボトルネック
`STRUCTURE.md`	ディレクトリレイアウトとファイル構成
`TESTING.md`	テストインフラ、カバレッジ、パターン
`INTEGRATIONS.md`	外部サービス、API、サードパーティ依存関係

増分リマップ — --paths (#2003): マッパーはオプションの --paths <p1,p2,...> スコープヒントを受け付けます。指定した場合、ツリー全体をスキャンする代わりに、リストされたリポジトリ相対プレフィックスに探索を制限します。これはフェーズが実際に変更したサブツリーのみを更新するために、実行後コードベースドリフトゲートが使用するパスウェイです。各生成ドキュメントはその YAML フロントマターに last_mapped_commit を持ち、ドリフトを HEAD ではなくマッピング時点と照らし合わせて計測できます。

27b. 既存コードベースオンボーディング

コマンド: /gsd-onboard [--fast] [--text]

目的: 既存リポジトリの初回セットアップを案内し、brownfield 状態を確認してコードベースマッピング、docs 取り込み、プロジェクト初期化へ安全にハンドオフします。

要件:

REQ-ONBOARD-01: 既存コード、package manifest、計画ドキュメント、部分的な .planning/、コードベースマップの不足を検出する。
REQ-ONBOARD-02: 必要な .planning/codebase/ マップファイルがない brownfield では /gsd-map-codebase または /gsd-map-codebase --fast へハンドオフする。fast マップの readiness は部分的であり、/gsd-new-project に十分として扱ってはならない。
REQ-ONBOARD-03: ADR/PRD/SPEC/RFC 候補があり project がない場合、/gsd-new-project の前に /gsd-ingest-docs を提示する。
REQ-ONBOARD-04: PROJECT.md、REQUIREMENTS.md、ROADMAP.md、STATE.md が揃うまで完了扱いにしない。
REQ-ONBOARD-05: project setup 後にのみ .planning/onboarding/SUMMARY.md を作成または確認する。
REQ-ONBOARD-06: 対話型メニューがない runtime 向けに、--text で番号付きプレーンテキスト gate をサポートする。

生成物:

Artifact	説明
`.planning/codebase/`	`/gsd-map-codebase` handoff が生成するコードベースマップ
`.planning/PROJECT.md`, `REQUIREMENTS.md`, `ROADMAP.md`, `STATE.md`	`/gsd-new-project` または `/gsd-ingest-docs` が生成する planning setup
`.planning/onboarding/SUMMARY.md`	Onboarding status、artifact index、next-command summary

27a. 実行後コードベースドリフト検出

導入: #2003 トリガー: すべての /gsd-execute-phase 終了時に自動実行 設定:

workflow.drift_threshold（整数、デフォルト 3）— ゲートが動作するまでに必要な最小新規構造要素数。
workflow.drift_action（warn | auto-remap、デフォルト warn）— 警告のみ、または影響を受けたサブツリーにスコープした --paths で gsd-codebase-mapper をスポーン。

ドリフトとしてカウントされるもの:

マッピングされたパス外の新規ディレクトリ
(packages|apps)/*/src/index.* の新規バレルエクスポート
新規マイグレーションファイル（supabase/prisma/drizzle/src/migrations/…）
routes/ または api/ 下の新規ルートモジュール

非ブロッキング保証: 内部障害（STRUCTURE.md の欠如、git エラー、マッパースポーン失敗）は 1 行をログに記録し、フェーズは継続します。ドリフト検出が検証を失敗させることはありません。

要件:

REQ-DRIFT-01: システムは git diff --name-status last_mapped_commit..HEAD から 4 つのドリフトカテゴリを検出しなければならない
REQ-DRIFT-02: アクションは要素数が workflow.drift_threshold 以上の場合のみ発動する
REQ-DRIFT-03: warn アクションはエージェントをスポーンしてはならない
REQ-DRIFT-04: auto-remap アクションはサニタイズされた --paths をマッパーに渡さなければならない
REQ-DRIFT-05: 検出/リマップの失敗は /gsd-execute-phase に対して非ブロッキングでなければならない
REQ-DRIFT-06: last_mapped_commit は各 .planning/codebase/*.md ファイルの YAML フロントマターを通じてラウンドトリップしなければならない

ユーティリティ機能

28. デバッグシステム

コマンド: /gsd-debug [description]

目的: コンテキストリセットを超えて持続する状態を持つ、体系的なデバッグ。

要件:

REQ-DEBUG-01: システムは .planning/debug/ にデバッグセッションファイルを作成しなければならない
REQ-DEBUG-02: システムは仮説、証拠、排除された理論を追跡しなければならない
REQ-DEBUG-03: システムはコンテキストリセット後もデバッグが継続するよう状態を永続化しなければならない
REQ-DEBUG-04: システムは解決済みとマークする前に人的検証を要求しなければならない
REQ-DEBUG-05: 解決済みセッションは .planning/debug/knowledge-base.md に追記されなければならない
REQ-DEBUG-06: ナレッジベースは再調査を防止するために新しいデバッグセッション時に参照されなければならない

デバッグセッションの状態: gathering → investigating → fixing → verifying → awaiting_human_verify → resolved

29. Todo 管理

コマンド: /gsd-capture [desc]、/gsd-capture --list

目的: セッション中にアイデアやタスクをキャプチャし、後で作業できるようにします。

要件:

REQ-TODO-01: システムは現在の会話コンテキストから Todo をキャプチャしなければならない
REQ-TODO-02: Todo は .planning/todos/pending/ に保存されなければならない
REQ-TODO-03: 完了した Todo は .planning/todos/completed/ に移動されなければならない
REQ-TODO-04: check-todos は保留中のすべてのアイテムを一覧表示し、作業するアイテムを選択できなければならない

30. 統計ダッシュボード

コマンド: /gsd-stats

目的: プロジェクトメトリクスを表示します — フェーズ、プラン、要件、git 履歴、タイムライン。

要件:

REQ-STATS-01: システムはフェーズ/プランの完了数を表示しなければならない
REQ-STATS-02: システムは要件カバレッジを表示しなければならない
REQ-STATS-03: システムは git コミットメトリクスを表示しなければならない
REQ-STATS-04: システムは複数の出力形式（json、table、bar）をサポートしなければならない

31. アップデートシステム

コマンド: /gsd-update

目的: GSD を最新バージョンに更新し、チェンジログのプレビューを表示します。

要件:

REQ-UPDATE-01: システムは npm 経由で新しいバージョンをチェックしなければならない
REQ-UPDATE-02: システムは更新前に新しいバージョンのチェンジログを表示しなければならない
REQ-UPDATE-03: システムはランタイムを認識し、正しいディレクトリを対象としなければならない
REQ-UPDATE-04: システムはローカルで変更されたファイルを gsd-local-patches/ にバックアップしなければならない
REQ-UPDATE-05: /gsd-update --reapply は更新後にローカルの変更を復元しなければならない

32. 設定管理

コマンド: /gsd-settings

目的: ワークフロートグルとモデルプロファイルのインタラクティブな設定。

要件:

REQ-SETTINGS-01: システムは現在の設定をトグルオプション付きで表示しなければならない
REQ-SETTINGS-02: システムは .planning/config.json を更新しなければならない
REQ-SETTINGS-03: システムはグローバルデフォルト（~/.gsd/defaults.json）としての保存をサポートしなければならない

設定可能な項目:

設定	型	デフォルト	説明
`mode`	enum	`interactive`	`interactive` または `yolo`（自動承認）
`granularity`	enum	`standard`	`coarse`、`standard`、または `fine`
`model_profile`	enum	`balanced`	`quality`、`balanced`、`budget`、または `inherit`
`workflow.research`	boolean	`true`	プランニング前のドメインリサーチ
`workflow.plan_check`	boolean	`true`	プラン検証ループ
`workflow.verifier`	boolean	`true`	実行後検証
`workflow.auto_advance`	boolean	`false`	ディスカッション→プラン→実行の自動チェーン
`workflow.nyquist_validation`	boolean	`true`	Nyquist テストカバレッジマッピング
`workflow.ui_phase`	boolean	`true`	UI デザインコントラクト生成
`workflow.ui_safety_gate`	boolean	`true`	フロントエンドフェーズで ui-phase を促す
`workflow.node_repair`	boolean	`true`	自律的なタスクリペア
`workflow.node_repair_budget`	number	`2`	タスクあたりの最大リペア試行回数
`planning.commit_docs`	boolean	`true`	`.planning/` ファイルを git にコミット
`planning.search_gitignored`	boolean	`false`	gitignore されたファイルを検索に含める
`parallelization.enabled`	boolean	`true`	独立したプランを同時実行
`git.branching_strategy`	enum	`none`	`none`、`phase`、または `milestone`

33. テスト生成

コマンド: /gsd-add-tests [N]

目的: 完了したフェーズに対して、UAT 基準と実装に基づいてテストを生成します。

要件:

REQ-TEST-01: システムは完了したフェーズの実装を分析しなければならない
REQ-TEST-02: システムは UAT 基準と受け入れ基準に基づいてテストを生成しなければならない
REQ-TEST-03: システムは既存のテストインフラパターンを使用しなければならない

インフラストラクチャ機能

34. Git 連携

目的: アトミックなコミット、ブランチ戦略、クリーンな履歴管理。

要件:

REQ-GIT-01: 各タスクは独自のアトミックなコミットを持たなければならない
REQ-GIT-02: コミットメッセージは構造化されたフォーマットに従わなければならない: type(scope): description
REQ-GIT-03: システムは3つのブランチ戦略をサポートしなければならない: none、phase、milestone
REQ-GIT-04: phase 戦略はフェーズごとに1つのブランチを作成しなければならない
REQ-GIT-05: milestone 戦略はマイルストーンごとに1つのブランチを作成しなければならない
REQ-GIT-06: complete-milestone はスカッシュマージ（推奨）または履歴付きマージを提案しなければならない
REQ-GIT-07: システムは .planning/ ファイルに対して commit_docs 設定を尊重しなければならない
REQ-GIT-08: システムは .gitignore の .planning/ を自動検出し、コミットをスキップしなければならない

コミットフォーマット:

type(phase-plan): description

# Examples:
docs(08-02): complete user registration plan
feat(08-02): add email confirmation flow
fix(03-01): correct auth token expiry

35. CLI ツール

目的: ワークフローとエージェント向けのプログラマティックユーティリティ。反復的なインライン bash パターンを置き換えます。

要件:

REQ-CLI-01: システムは状態、設定、フェーズ、ロードマップ操作のためのアトミックなコマンドを提供しなければならない
REQ-CLI-02: システムは各ワークフローのすべてのコンテキストを読み込む複合 init コマンドを提供しなければならない
REQ-CLI-03: システムは機械可読な出力のための --raw フラグをサポートしなければならない
REQ-CLI-04: システムはサンドボックス化されたサブエージェント操作のための --cwd フラグをサポートしなければならない
REQ-CLI-05: すべての操作は Windows でスラッシュパスを使用しなければならない

コマンドカテゴリ: State（11サブコマンド）、Phase（5）、Roadmap（3）、Verify（8）、Template（2）、Frontmatter（4）、Scaffold（4）、Init（12）、Validate（2）、Progress、Stats、Todo

36. マルチランタイムサポート

目的: 複数の AI コーディングエージェントランタイムで GSD を実行します。

要件:

REQ-RUNTIME-01: システムは Claude Code、OpenCode、Kilo、Codex、Copilot、Antigravity をサポートしなければならない
REQ-RUNTIME-02: インストーラーはランタイムごとにコンテンツを変換しなければならない（ツール名、パス、フロントマター）
REQ-RUNTIME-03: インストーラーはインタラクティブおよび非インタラクティブ（--claude --global）モードをサポートしなければならない
REQ-RUNTIME-04: インストーラーはグローバルとローカルの両方のインストールをサポートしなければならない
REQ-RUNTIME-05: アンインストールは他の設定に影響を与えることなく、すべての GSD ファイルをクリーンに削除しなければならない
REQ-RUNTIME-06: インストーラーはプラットフォームの違い（Windows、macOS、Linux、WSL、Docker）を処理しなければならない

ランタイム変換:

側面	Claude Code	OpenCode	Kilo	Codex	Copilot	Antigravity
コマンド	スラッシュコマンド	スラッシュコマンド	スラッシュコマンド	スキル（TOML）	スラッシュコマンド	スキル
エージェント形式	Claude ネイティブ	`mode: subagent`	`mode: subagent`	スキル	ツールマッピング	スキル
フックイベント	`PostToolUse`	N/A	N/A	N/A	N/A	N/A
設定	`settings.json`	`opencode.json(c)`	`kilo.json(c)`	TOML	Instructions	Config

37. フックシステム

目的: コンテキスト監視、ステータス表示、アップデートチェックのためのランタイムイベントフック。

要件:

REQ-HOOK-01: ステータスラインはモデル、現在のタスク、ディレクトリ、コンテキスト使用量を表示しなければならない
REQ-HOOK-02: コンテキストモニターは閾値レベルでエージェント向け警告を注入しなければならない
REQ-HOOK-03: アップデートチェッカーはセッション開始時にバックグラウンドで実行されなければならない
REQ-HOOK-04: すべてのフックは CLAUDE_CONFIG_DIR 環境変数を尊重しなければならない
REQ-HOOK-05: すべてのフックは3秒の stdin タイムアウトガードを含まなければならない
REQ-HOOK-06: すべてのフックはエラー時にサイレントに失敗しなければならない
REQ-HOOK-07: コンテキスト使用量は autocompact バッファ（16.5% リザーブ）に対して正規化されなければならない
REQ-HOOK-08: アップデートバナーはオプトインであり、アップデートが利用可能でない限りサイレントでなければならない（PR #2795）

ステータスライン表示:

[⬆ /gsd-update │] model │ [current task │] directory [█████░░░░░ 50%]

カラーコーディング: 50% 未満は緑、65% 未満は黄、80% 未満はオレンジ、80% 以上はドクロ絵文字付き赤

38. 開発者プロファイリング

コマンド: /gsd-profile-user [--questionnaire] [--refresh]

目的: Claude Code のセッション履歴を分析し、8つの次元にわたる行動プロファイルを構築します。開発者のスタイルに合わせて Claude のレスポンスをパーソナライズするための成果物を生成します。

次元:

コミュニケーションスタイル（簡潔 vs 冗長、フォーマル vs カジュアル）
意思決定パターン（迅速 vs 慎重、リスク許容度）
デバッグアプローチ（体系的 vs 直感的、ログの好み）
UX の好み（デザインセンス、アクセシビリティの認識）
ベンダー/テクノロジーの選択（フレームワークの好み、エコシステムへの精通度）
フラストレーションのトリガー（ワークフローで摩擦を引き起こすもの）
学習スタイル（ドキュメント vs 例、深さの好み）
説明の深さ（ハイレベル vs 実装詳細）

生成される成果物:

USER-PROFILE.md — 証拠引用付きの完全な行動プロファイル
CLAUDE.md プロファイルセクション — Claude Code により自動検出

フラグ:

--questionnaire — セッション履歴が利用できない場合のインタラクティブなアンケートフォールバック
--refresh — セッションを再分析してプロファイルを再生成

パイプラインモジュール:

profile-pipeline.cjs — セッションスキャン、メッセージ抽出、サンプリング
profile-output.cjs — プロファイルレンダリング、アンケート、成果物生成
gsd-user-profiler エージェント — セッションデータからの行動分析

要件:

REQ-PROF-01: セッション分析は少なくとも8つの行動次元をカバーしなければならない
REQ-PROF-02: プロファイルは実際のセッションメッセージからの証拠を引用しなければならない
REQ-PROF-03: セッション履歴がない場合、アンケートがフォールバックとして利用可能でなければならない
REQ-PROF-04: 生成された成果物は Claude Code により検出可能でなければならない（CLAUDE.md 連携）

39. 実行ハードニング

目的: 実行パイプラインに対する3つの段階的な品質改善。クロスプランの失敗が連鎖する前に検出します。

コンポーネント:

1. プレウェーブ依存関係チェック（execute-phase）ウェーブ N+1 を起動する前に、前のウェーブの成果物からのキーリンクが存在し、正しく接続されていることを検証します。クロスプランの依存関係ギャップが下流の失敗に連鎖するのを防ぎます。

2. クロスプランデータコントラクト — 第9次元（plan-checker）データパイプラインを共有するプランが互換性のある変換を持っているかチェックする新しい分析次元。あるプランが別のプランが元の形式で必要とするデータを削除する場合にフラグを立てます。

3. エクスポートレベルスポットチェック（verify-phase）レベル3の配線検証が通過した後、個々のエクスポートが実際に使用されているかスポットチェックします。配線されたファイル内に存在するが呼び出されないデッドストアを検出します。

要件:

REQ-HARD-01: プレウェーブチェックは次のウェーブを起動する前に、すべての前のウェーブの成果物からのキーリンクを検証しなければならない
REQ-HARD-02: クロスプランコントラクトチェックはプラン間の互換性のないデータ変換を検出しなければならない
REQ-HARD-03: エクスポートスポットチェックは配線されたファイル内のデッドストアを特定しなければならない

40. 検証デット追跡

コマンド: /gsd-audit-uat

目的: 未解決のテストを持つフェーズを通過した際の UAT/検証項目のサイレントな喪失を防止します。すべての過去フェーズの検証デットを表面化し、項目が忘れられないようにします。

コンポーネント:

1. クロスフェーズヘルスチェック（progress.md ステップ 1.6）すべての /gsd-progress 呼び出しで、現在のマイルストーンのすべてのフェーズの未解決項目（pending、skipped、blocked、human_needed）をスキャンします。アクション可能なリンク付きのノンブロッキング警告セクションを表示します。

2. status: partial（verify-work.md、UAT.md）「セッション終了」と「すべてのテスト解決済み」を区別する新しい UAT ステータス。テストがまだ pending、blocked、または理由なく skipped の場合に status: complete を防止します。

3. result: blocked と blocked_by タグ（verify-work.md、UAT.md）外部依存関係（サーバー、物理デバイス、リリースビルド、サードパーティサービス）によりブロックされたテストのための新しいテスト結果タイプ。スキップされたテストとは別にカテゴリ分けされます。

4. HUMAN-UAT.md の永続化（execute-phase.md）検証が human_needed を返した場合、項目は status: partial の追跡可能な HUMAN-UAT.md ファイルとして永続化されます。クロスフェーズヘルスチェックと監査システムに反映されます。

5. フェーズ完了警告（phase.cjs、transition.md） phase complete CLI は JSON 出力に検証デット警告を返します。トランジションワークフローは確認前に未解決項目を表面化します。

要件:

REQ-DEBT-01: システムは /gsd-progress ですべての過去フェーズの未解決 UAT/検証項目を表面化しなければならない
REQ-DEBT-02: システムは不完全なテスト（partial）と完了したテスト（complete）を区別しなければならない
REQ-DEBT-03: システムはブロックされたテストを blocked_by タグでカテゴリ分けしなければならない
REQ-DEBT-04: システムは human_needed の検証項目を追跡可能な UAT ファイルとして永続化しなければならない
REQ-DEBT-05: システムは検証デットが存在する場合、フェーズ完了とトランジション時に警告（ノンブロッキング）しなければならない
REQ-DEBT-06: /gsd-audit-uat はすべてのフェーズをスキャンし、項目をテスト可能性別にカテゴリ分けし、人的テストプランを生成しなければならない

v1.27 の機能

41. Fast モード

コマンド: /gsd-fast [task description]

目的: サブエージェントの起動や PLAN.md ファイルの生成なしに、些細なタスクをインラインで実行します。プランニングのオーバーヘッドを正当化できないほど小さなタスク向け: タイポ修正、設定変更、小規模なリファクタリング、コミット忘れ、簡単な追加。

要件:

REQ-FAST-01: システムはサブエージェントなしで現在のコンテキストでタスクを直接実行しなければならない
REQ-FAST-02: システムは変更に対してアトミックな git コミットを生成しなければならない
REQ-FAST-03: システムは状態の一貫性のためにタスクを .planning/quick/ で追跡しなければならない
REQ-FAST-04: リサーチ、マルチステッププランニング、または検証が必要なタスクにシステムを使用してはならない

/gsd-quick との使い分け:

/gsd-fast — 2分以内に実行可能な一文のタスク（タイポ修正、設定変更、小規模な追加）
/gsd-quick — リサーチ、マルチステッププランニング、または検証が必要なもの

42. クロス AI ピアレビュー

コマンド: /gsd-review --phase N [--claude] [--codex] [--coderabbit] [--opencode] [--qwen] [--cursor] [--agy] [--antigravity] [--ollama] [--lm-studio] [--llama-cpp] [--kimi-code] [--all]

目的: 外部の AI CLI（Claude、Codex、CodeRabbit、OpenCode、Qwen Code、Cursor、Antigravity、Kimi Code）とローカルの OpenAI 互換サーバー（Ollama、LM Studio、llama.cpp）を呼び出して、フェーズプランを独立してレビューします。レビュアーごとのフィードバックを含む構造化された REVIEWS.md を生成します。

要件:

REQ-REVIEW-01: システムはシステム上で利用可能な AI CLI を検出しなければならない
REQ-REVIEW-02: システムはフェーズプランから構造化されたレビュープロンプトを構築しなければならない
REQ-REVIEW-03: システムは選択された各 CLI を独立して呼び出さなければならない
REQ-REVIEW-04: システムはレスポンスを収集して REVIEWS.md を生成しなければならない
REQ-REVIEW-05: レビューは /gsd-plan-phase --reviews で使用可能でなければならない

生成物: {phase}-REVIEWS.md — レビュアーごとの構造化されたフィードバック

43. バックログパーキングロット

コマンド: /gsd-capture --backlog <description>、/gsd-review-backlog、/gsd-capture --seed <idea>

目的: アクティブなプランニングの準備ができていないアイデアをキャプチャします。バックログ項目は 999.x の番号付けを使用して、アクティブなフェーズシーケンスの外に留まります。シードは、適切なマイルストーンで自動的に表面化するトリガー条件を持つ、将来を見据えたアイデアです。

要件:

REQ-BACKLOG-01: バックログ項目はアクティブなフェーズシーケンスの外に留まるために 999.x の番号付けを使用しなければならない
REQ-BACKLOG-02: /gsd-discuss-phase と /gsd-plan-phase が動作するよう、フェーズディレクトリは即座に作成されなければならない
REQ-BACKLOG-03: /gsd-review-backlog は項目ごとにプロモート、維持、削除のアクションをサポートしなければならない
REQ-BACKLOG-04: プロモートされた項目はアクティブなマイルストーンシーケンスに再番号付けされなければならない
REQ-SEED-01: シードは完全な WHY と表面化条件の WHEN をキャプチャしなければならない
REQ-SEED-02: /gsd-new-milestone はシードをスキャンして一致するものを提示しなければならない

生成物:

成果物	説明
`.planning/phases/999.x-slug/`	バックログ項目ディレクトリ
`.planning/seeds/SEED-NNN-slug.md`	トリガー条件付きシード

44. 永続コンテキストスレッド

コマンド: /gsd-thread [name | description]

目的: 複数セッションにまたがるが特定のフェーズには属さない作業のための、軽量なクロスセッションナレッジストア。/gsd-pause-work よりも軽量 — フェーズ状態やプランコンテキストは不要です。

要件:

REQ-THREAD-01: システムは作成、一覧、再開モードをサポートしなければならない
REQ-THREAD-02: スレッドは .planning/threads/ にマークダウンファイルとして保存されなければならない
REQ-THREAD-03: スレッドファイルには Goal、Context、References、Next Steps セクションを含めなければならない
REQ-THREAD-04: スレッドの再開時にその完全なコンテキストを現在のセッションに読み込まなければならない
REQ-THREAD-05: スレッドはフェーズまたはバックログ項目にプロモート可能でなければならない

生成物: .planning/threads/{slug}.md — 永続コンテキストスレッド

45. PR ブランチフィルタリング

コマンド: /gsd-pr-branch [target branch]

目的: .planning/ のコミットを除外して、プルリクエストに適したクリーンなブランチを作成します。レビュアーにはコード変更のみが表示され、GSD プランニング成果物は表示されません。

要件:

REQ-PRBRANCH-01: システムは .planning/ ファイルのみを変更するコミットを特定しなければならない
REQ-PRBRANCH-02: システムはプランニングコミットを除外した新しいブランチを作成しなければならない
REQ-PRBRANCH-03: コード変更はコミットされた通りに正確に保持されなければならない

46. セキュリティハードニング

目的: GSD のプランニング成果物に対する多層防御セキュリティ。GSD は LLM のシステムプロンプトとなるマークダウンファイルを生成するため、これらのファイルに流入するユーザー制御テキストは間接的なプロンプトインジェクションの潜在的なベクターです。

コンポーネント:

1. 集中型セキュリティモジュール（security.cjs）

パストラバーサル防止 — ファイルパスがプロジェクトディレクトリ内に解決されることを検証
プロンプトインジェクション検出 — ユーザー提供テキスト内の既知のインジェクションパターンをスキャン
安全な JSON パース — 状態破損前に不正な入力をキャッチ
フィールド名バリデーション — 設定フィールド名を通じたインジェクションを防止
シェル引数バリデーション — シェル補間前にユーザーテキストをサニタイズ

2. プロンプトインジェクションガードフック（gsd-prompt-guard.js） .planning/ を対象とする Write/Edit 呼び出しをインジェクションパターンでスキャンする PreToolUse フック。アドバイザリーのみ — 正当な操作をブロックせず、検出を認識のためにログ記録します。

3. ワークフローガードフック（gsd-workflow-guard.js） Claude が GSD ワークフローコンテキスト外でファイル編集を試行した際に検出する PreToolUse フック。直接編集の代わりに /gsd-quick や /gsd-fast の使用をアドバイスします。hooks.workflow_guard（デフォルト: false）で設定可能です。

4. CI 対応インジェクションスキャナー（prompt-injection-scan.security.test.cjs）すべてのエージェント、ワークフロー、コマンドファイルに埋め込まれたインジェクションベクターをスキャンするテストスイート。

要件:

REQ-SEC-01: すべてのユーザー提供ファイルパスはプロジェクトディレクトリに対して検証されなければならない
REQ-SEC-02: プロンプトインジェクションパターンはテキストがプランニング成果物に入る前に検出されなければならない
REQ-SEC-03: セキュリティフックはアドバイザリーのみでなければならない（正当な操作を決してブロックしない）
REQ-SEC-04: ユーザー入力の JSON パースは不正なデータをグレースフルにキャッチしなければならない
REQ-SEC-05: macOS の /var → /private/var シンボリックリンク解決がパスバリデーションで処理されなければならない

47. マルチリポワークスペースサポート

目的: モノレポおよびマルチリポ構成のための自動検出とプロジェクトルート解決。.planning/ がリポジトリ境界を超えて解決する必要がある場合のワークスペースをサポートします。

要件:

REQ-MULTIREPO-01: システムはマルチリポワークスペース設定を自動検出しなければならない
REQ-MULTIREPO-02: システムはリポジトリ境界を超えてプロジェクトルートを解決しなければならない
REQ-MULTIREPO-03: エグゼキューターはマルチリポモードでリポジトリごとのコミットハッシュを記録しなければならない

48. ディスカッション監査証跡

目的: /gsd-discuss-phase 中に DISCUSSION-LOG.md を自動生成し、ディスカッション中の決定事項の完全な監査証跡を残します。

要件:

REQ-DISCLOG-01: システムは discuss-phase 中に DISCUSSION-LOG.md を自動生成しなければならない
REQ-DISCLOG-02: ログは質問内容、提示されたオプション、行われた決定をキャプチャしなければならない
REQ-DISCLOG-03: 決定 ID は discuss-phase から plan-phase へのトレーサビリティを可能にしなければならない

v1.28 の機能

49. フォレンジクス

コマンド: /gsd-forensics [description]

目的: 失敗または停滞した GSD ワークフローのポストモーテム調査。

要件:

REQ-FORENSICS-01: システムは git 履歴の異常（停滞ループ、長いギャップ、繰り返しコミット）を分析しなければならない
REQ-FORENSICS-02: システムは成果物の整合性をチェックしなければならない（完了したフェーズに期待されるファイルがあるか）
REQ-FORENSICS-03: システムは .planning/forensics/ に保存されるマークダウンレポートを生成しなければならない
REQ-FORENSICS-04: システムは調査結果で GitHub Issue の作成を提案しなければならない
REQ-FORENSICS-05: システムはプロジェクトファイルを変更してはならない（読み取り専用の調査）

生成物:

成果物	説明
`.planning/forensics/report-{timestamp}.md`	ポストモーテム調査レポート

プロセス:

スキャン — git 履歴の異常を分析: 停滞ループ、コミット間の長いギャップ、繰り返しの同一コミット
整合性チェック — 完了したフェーズに期待される成果物ファイルがあるか検証
レポート — 調査結果を含むマークダウンレポートを生成し、.planning/forensics/ に保存
Issue — チームの可視性のため、調査結果で GitHub Issue の作成を提案

50. マイルストーンサマリー

コマンド: /gsd-milestone-summary [version]

目的: チームオンボーディングのためにマイルストーン成果物から包括的なプロジェクトサマリーを生成します。

要件:

REQ-SUMMARY-01: システムはフェーズプラン、サマリー、検証結果を集約しなければならない
REQ-SUMMARY-02: システムは現在のマイルストーンとアーカイブ済みマイルストーンの両方で動作しなければならない
REQ-SUMMARY-03: システムは単一のナビゲート可能なドキュメントを生成しなければならない

生成物:

成果物	説明
`MILESTONE-SUMMARY.md`	マイルストーン成果物の包括的でナビゲート可能なサマリー

プロセス:

収集 — 対象マイルストーンからフェーズプラン、サマリー、検証結果を集約
統合 — 成果物をクロスリファレンス付きの単一のナビゲート可能なドキュメントに結合
出力 — チームオンボーディングとステークホルダーレビューに適した MILESTONE-SUMMARY.md を作成

51. ワークストリームネームスペーシング

コマンド: /gsd-workstreams

目的: 異なるマイルストーン領域での同時作業のための並列ワークストリーム。

要件:

REQ-WS-01: システムはワークストリーム状態を個別の .planning/workstreams/{name}/ ディレクトリに分離しなければならない
REQ-WS-02: システムはワークストリーム名を検証しなければならない（英数字とハイフンのみ、パストラバーサルなし）
REQ-WS-03: システムは list、create、switch、status、progress、complete、resume サブコマンドをサポートしなければならない

生成物:

成果物	説明
`.planning/workstreams/{name}/`	分離されたワークストリームディレクトリ構造

プロセス:

作成 — 分離された .planning/workstreams/{name}/ ディレクトリで名前付きワークストリームを初期化
切り替え — 後続の GSD コマンドのためにアクティブなワークストリームコンテキストを変更
管理 — ワークストリームの一覧表示、ステータス確認、進捗追跡、完了、または再開

52. マネージャーダッシュボード

コマンド: /gsd-manager

目的: 1つのターミナルから複数のフェーズを管理するためのインタラクティブなコマンドセンター。

要件:

REQ-MGR-01: システムはすべてのフェーズの概要をステータス付きで表示しなければならない
REQ-MGR-02: システムは現在のマイルストーンスコープにフィルタリングしなければならない
REQ-MGR-03: システムはフェーズの依存関係と競合を表示しなければならない

生成物: インタラクティブなターミナル出力

プロセス:

スキャン — 現在のマイルストーンのすべてのフェーズとそのステータスを読み込み
表示 — フェーズの依存関係、競合、進捗を示す概要をレンダリング
操作 — 個々のフェーズのナビゲーション、検査、操作のコマンドを受け付け

53. Assumptions ディスカッションモード

コマンド: /gsd-discuss-phase（workflow.discuss_mode: 'assumptions' 設定時）

目的: インタビュー形式の質問をコードベースファーストの仮定分析に置き換えます。

要件:

REQ-ASSUME-01: システムは質問の前にコードベースを分析して構造化された仮定を生成しなければならない
REQ-ASSUME-02: システムは仮定を信頼度レベル（Confident/Likely/Unclear）で分類しなければならない
REQ-ASSUME-03: システムはデフォルトのディスカスモードと同一の CONTEXT.md フォーマットを生成しなければならない
REQ-ASSUME-04: システムは信頼度ベースのスキップゲートをサポートしなければならない（すべて HIGH の場合は質問なし）

生成物:

成果物	説明
`{phase}-CONTEXT.md`	デフォルトのディスカスモードと同じフォーマット

プロセス:

分析 — コードベースをスキャンして実装アプローチに関する構造化された仮定を生成
分類 — 仮定を信頼度レベル別にカテゴリ分け: Confident、Likely、Unclear
ゲート — すべての仮定が HIGH 信頼度の場合、質問を完全にスキップ
確認 — 不明確な仮定をターゲット化された質問としてユーザーに提示
出力 — デフォルトのディスカスモードと同一フォーマットで {phase}-CONTEXT.md を生成

54. UI フェーズ自動検出

対象: /gsd-new-project および /gsd-progress

目的: UI 重視のプロジェクトを自動検出し、/gsd-ui-phase の推奨を表面化します。

要件:

REQ-UI-DETECT-01: システムはプロジェクト説明の UI シグナル（キーワード、フレームワーク参照）を検出しなければならない
REQ-UI-DETECT-02: システムは該当する場合に ROADMAP.md のフェーズに ui_hint をアノテーションしなければならない
REQ-UI-DETECT-03: システムは UI 重視フェーズのネクストステップに /gsd-ui-phase を提案しなければならない
REQ-UI-DETECT-04: システムは /gsd-ui-phase を必須にしてはならない

プロセス:

検出 — プロジェクト説明と技術スタックの UI シグナル（キーワード、フレームワーク参照）をスキャン
アノテーション — ROADMAP.md の該当フェーズに ui_hint マーカーを追加
表面化 — UI 重視フェーズのネクストステップに /gsd-ui-phase の推奨を含める

55. マルチランタイムインストーラー選択

対象: npx @opengsd/gsd-core

目的: 1回のインタラクティブなインストールセッションで複数のランタイムを選択します。

要件:

REQ-MULTI-RT-01: インタラクティブプロンプトはマルチセレクトをサポートしなければならない（例: Claude Code + Antigravity）
REQ-MULTI-RT-02: CLI フラグは非インタラクティブインストールで引き続き動作しなければならない

プロセス:

検出 — システム上で利用可能な AI CLI ランタイムを特定
プロンプト — ランタイム選択のためのマルチセレクトインターフェースを提示
インストール — 1回のセッションで選択されたすべてのランタイムに対して GSD を設定

v1.29 の機能

56. Windsurf ランタイムサポート

対象: npx @opengsd/gsd-core

目的: Windsurf AI IDE のサポートを追加します。

要件:

REQ-WINDSURF-01: インストーラーは --windsurf フラグによる Windsurf インストールをサポートしなければならない
REQ-WINDSURF-02: Windsurf ルール形式に対応したプロンプトファイルを生成しなければならない

プロセス:

検出 — Windsurf のインストール状態を確認
変換 — GSD プロンプトを Windsurf ルール形式に変換
インストール — Windsurf 設定ディレクトリに GSD を設定

57. 国際化ドキュメント

対象: docs/ ディレクトリ

目的: GSD ドキュメントをポルトガル語、韓国語、日本語で提供します。

要件:

REQ-I18N-01: ドキュメントはポルトガル語（pt）、韓国語（ko）、日本語（ja）で提供されなければならない
REQ-I18N-02: 翻訳は英語のソースドキュメントと同期を維持しなければならない

プロセス:

翻訳 — コアドキュメントを対象言語に変換
公開 — 翻訳されたドキュメントを英語版と並んでアクセス可能にする

v1.31 の機能

59. スキーマドリフト検出

コマンド: /gsd-execute-phase 実行時に自動

目的: ORM スキーマファイルが対応するマイグレーションまたは push コマンドなしに変更された場合を検出し、誤検知の検証を防止します。

要件:

REQ-SCHEMA-01: システムは ORM スキーマファイル（Prisma、Drizzle、Payload、Sanity、Mongoose）の変更を検出しなければならない
REQ-SCHEMA-02: スキーマ変更が検出された場合、対応するマイグレーション/push コマンドの存在を確認しなければならない
REQ-SCHEMA-03: 二層防御を実装しなければならない: 計画時注入と実行時ゲート
REQ-SCHEMA-04: 検出をオーバーライドする GSD_SKIP_SCHEMA_CHECK 環境変数をサポートしなければならない
REQ-SCHEMA-05: マイグレーションなしのスキーマ変更時に誤検知の検証を防止しなければならない

プロセス:

検出 — 計画実行中の ORM スキーマファイルの変更を監視
確認 — 計画に対応するマイグレーション/push コマンドが含まれていることを確認
ゲート — マイグレーションなしのスキーマドリフトが検出された場合、実行をブロック（実行時ゲート）
注入 — 計画生成中にマイグレーションリマインダーを追加（計画時注入）

設定: GSD_SKIP_SCHEMA_CHECK 環境変数で検出をバイパス。

60. セキュリティエンフォースメント

コマンド: /gsd-secure-phase <N>

目的: フェーズ実装に対する脅威モデルアンカードのセキュリティ検証。

要件:

REQ-SEC-01: システムは脅威モデルアンカードの検証（ブラインドスキャンではない）を実行しなければならない
REQ-SEC-02: 設定可能な OWASP ASVS 検証レベル（1-3）をサポートしなければならない
REQ-SEC-03: 設定可能な重大度しきい値に基づいてフェーズ進行をブロックしなければならない
REQ-SEC-04: 分析のために gsd-security-auditor エージェントを起動しなければならない

生成物:

成果物	説明
セキュリティ監査レポート	重大度分類付きの脅威モデルアンカードの発見事項

プロセス:

モデル — フェーズ実装コンテキストから脅威モデルを構築
監査 — gsd-security-auditor を起動して脅威モデルに対して検証
ゲート — 発見事項が security_block_on 重大度以上の場合、フェーズ進行をブロック

設定:

設定	型	デフォルト	説明
`security_enforcement`	boolean	`true`	脅威モデルセキュリティ検証を有効化
`security_asvs_level`	number (1-3)	`1`	OWASP ASVS 検証レベル
`security_block_on`	string	`"high"`	フェーズ進行をブロックする最小重大度

61. ドキュメント生成

コマンド: /gsd-docs-update

目的: 正確性チェック付きのプロジェクトドキュメントを生成・検証します。

要件:

REQ-DOCS-01: システムはドキュメント生成のために gsd-doc-writer エージェントを起動しなければならない
REQ-DOCS-02: システムは正確性チェックのために gsd-doc-verifier エージェントを起動しなければならない
REQ-DOCS-03: システムは生成されたドキュメントを実際の実装に対して検証しなければならない

生成物:

成果物	説明
更新されたプロジェクトドキュメント	生成および検証されたドキュメントファイル

プロセス:

生成 — gsd-doc-writer を起動して実装からドキュメントを作成・更新
検証 — gsd-doc-verifier を起動してコードベースに対するドキュメント正確性をチェック
出力 — 正確性アノテーション付きの検証済みドキュメントを生成

62. ディスカスチェーンモード

フラグ: /gsd-discuss-phase <N> --chain

目的: 手動のコマンド連続実行を削減するため、discuss、plan、execute フェーズを1つのフローで自動チェーンします。

要件:

REQ-CHAIN-01: --chain フラグが提供された場合、システムは discuss → plan → execute を自動チェーンしなければならない
REQ-CHAIN-02: チェーンされたフェーズ間のすべてのゲート設定を尊重しなければならない
REQ-CHAIN-03: いずれかのフェーズが失敗した場合、チェーンを停止しなければならない

プロセス:

ディスカス — コンテキスト収集のためにディスカスフェーズを実行
プラン — 収集されたコンテキストでプランフェーズを自動的に呼び出し
エクセキュート — 生成されたプランでエクセキュートフェーズを自動的に呼び出し

63. 単一フェーズ自律モード

フラグ: /gsd-autonomous --only N

目的: 全残りフェーズではなく、1つのフェーズだけを自律的に実行します。

要件:

REQ-ONLY-01: --only N が提供された場合、システムは指定されたフェーズ番号のみを実行しなければならない
REQ-ONLY-02: フル自律モードと同じ discuss → plan → execute フローに従わなければならない
REQ-ONLY-03: 指定されたフェーズが完了した後に停止しなければならない

プロセス:

選択 — --only N 引数からターゲットフェーズを特定
実行 — そのフェーズに対してフル自律フロー（discuss → plan → execute）を実行
停止 — 次のフェーズに進まず、フェーズ完了後に停止

64. スコープ削減検出

対象: /gsd-plan-phase

目的: 三層防御により、計画生成中のサイレントな要件削除を防止します。

要件:

REQ-SCOPE-01: プランナーは明示的な正当化なしにスコープを削減することを禁止されなければならない
REQ-SCOPE-02: プランチェッカーは要件ディメンションカバレッジを検証しなければならない
REQ-SCOPE-03: オーケストレーターは削除された要件を回復して再注入しなければならない
REQ-SCOPE-04: 三層防御を実装しなければならない: プランナー禁止、チェッカーディメンション、オーケストレーター回復

プロセス:

禁止 — プランナー指示でスコープ削減を明示的に禁止
チェック — プランチェッカーがすべてのフェーズ要件が計画でカバーされていることを確認
回復 — オーケストレーターが削除された要件を検出してプランニングループに再注入

65. クレーム出所タグ付け

対象: /gsd-plan-phase --research-phase

目的: リサーチのクレームにソースエビデンスのタグを付け、仮定を別途記録します。

要件:

REQ-PROVENANCE-01: リサーチャーはクレームにソースエビデンス参照をマークしなければならない
REQ-PROVENANCE-02: 仮定はソース付きクレームとは別に記録されなければならない
REQ-PROVENANCE-03: システムはエビデンス付き事実と推論された仮定を区別しなければならない

プロセス:

リサーチ — リサーチャーがコードベースとドメインソースから情報を収集
タグ — 各クレームにソース（ファイルパス、ドキュメント、API レスポンス）をアノテーション
分離 — 直接的なエビデンスのない仮定を別セクションに記録

66. Worktree トグル

設定: workflow.use_worktrees: false

目的: 順次実行を好むユーザーのために git worktree 分離を無効化します。

要件:

REQ-WORKTREE-01: システムは分離戦略を決定する際に workflow.use_worktrees 設定を尊重しなければならない
REQ-WORKTREE-02: 後方互換性のためにデフォルトは true（worktree 有効）でなければならない
REQ-WORKTREE-03: worktree が無効な場合、順次実行にフォールバックしなければならない

設定:

設定	型	デフォルト	説明
`workflow.use_worktrees`	boolean	`true`	`false` の場合、git worktree 分離を無効化

67. プロジェクトコードプレフィックス

設定: project_code: "ABC"

目的: マルチプロジェクトの曖昧さ解消のためにフェーズディレクトリ名にプロジェクトコードをプレフィックスします。

要件:

REQ-PREFIX-01: 設定された場合、システムはフェーズディレクトリにプロジェクトコードをプレフィックスしなければならない（例: ABC-01-setup/）
REQ-PREFIX-02: project_code が設定されていない場合、標準命名を使用しなければならない
REQ-PREFIX-03: すべてのフェーズ操作で一貫してプレフィックスを適用しなければならない

設定:

設定	型	デフォルト	説明
`project_code`	string	(なし)	フェーズディレクトリ名のプレフィックス

68. Claude Code スキルマイグレーション

対象: npx @opengsd/gsd-core

目的: GSD コマンドを Claude Code 2.1.88+ のスキル形式に後方互換性を維持してマイグレーションします。

要件:

REQ-SKILLS-01: インストーラーは Claude Code 2.1.88+ 向けに skills/gsd-*/SKILL.md を書き込まなければならない
REQ-SKILLS-02: インストーラーはレガシー commands/gsd/ ディレクトリを自動クリーンしなければならない
REQ-SKILLS-03: レガシー commands/gsd/ パスを通じて古い Claude Code バージョンとの後方互換性を維持しなければならない

プロセス:

検出 — Claude Code のバージョンをチェックしてスキルサポートを判定
マイグレーション — 各 GSD コマンドに対して skills/gsd-*/SKILL.md ファイルを書き込み
クリーン — スキルがインストールされた場合、レガシー commands/gsd/ ディレクトリを削除
フォールバック — 古い Claude Code バージョンのためにレガシー commands/gsd/ パス互換性を維持

v1.32 の機能

69. STATE.md 整合性ゲート

コマンド: state validate、state sync [--verify]、state planned-phase --phase N --plans N

目的: STATE.md と実際のファイルシステム間のドリフトを検出・修復し、古い状態からのカスケードエラーを防止します。

要件:

REQ-STATE-01: state validate は STATE.md フィールドとファイルシステムの実態間のドリフトを検出しなければならない
REQ-STATE-02: state sync はディスク上の実際のプロジェクト状態から STATE.md を再構築しなければならない
REQ-STATE-03: state sync --verify は書き込みなしで提案される変更を表示するドライランを実行しなければならない
REQ-STATE-04: state planned-phase はプランフェーズ完了後の状態遷移を記録しなければならない（Planned/Ready to execute）

生成物:

成果物	説明
更新された `STATE.md`	ファイルシステムの実態を反映した修正済み状態

プロセス:

検証 — STATE.md フィールドをファイルシステム（フェーズディレクトリ、計画ファイル、サマリー）と比較
同期 — ドリフトが検出された場合、ディスクから STATE.md を再構築
遷移 — エクセキュートフェーズの準備状態として計画数付きのポストプランニング状態を記録

70. 自律モード `--to N` フラグ

フラグ: /gsd-autonomous --to N

目的: 特定のフェーズ完了後に自律実行を停止し、部分的な自律実行を可能にします。

要件:

REQ-TO-01: システムは指定されたフェーズ番号の完了後に実行を停止しなければならない
REQ-TO-02: N までの各フェーズに対して同じ discuss → plan → execute フローに従わなければならない
REQ-TO-03: --to N は境界付き自律範囲のために --from N と組み合わせ可能でなければならない

プロセス:

境界設定 — --to N 引数から上限フェーズを設定
実行 — フェーズ N まで（含む）の各フェーズに対して自律フローを実行
停止 — フェーズ N の完了後に停止

71. リサーチゲート

対象: /gsd-plan-phase

目的: RESEARCH.md に未解決のオープンクエスチョンがある場合にプランニングをブロックし、不完全な情報に基づく計画を防止します。

要件:

REQ-RESGATE-01: プランニング開始前に RESEARCH.md の未解決オープンクエスチョンをスキャンしなければならない
REQ-RESGATE-02: オープンクエスチョンが存在する場合、プランフェーズのエントリをブロックしなければならない
REQ-RESGATE-03: 具体的な未解決クエスチョンをユーザーに表示しなければならない

プロセス:

スキャン — RESEARCH.md のオープンクエスチョンセクションで未解決項目をチェック
ゲート — 未解決クエスチョンが見つかった場合、プランニングをブロック
表示 — 解決が必要な具体的なオープンクエスチョンを表示

72. ベリファイヤーマイルストーンスコープフィルタリング

対象: /gsd-execute-phase（ベリファイヤーステップ）

目的: 真のギャップと後続フェーズに延期された項目を区別し、検証の偽陰性を削減します。

要件:

REQ-VSCOPE-01: ベリファイヤーはギャップが後続マイルストーンフェーズで対処されるかチェックしなければならない
REQ-VSCOPE-02: 後続フェーズで対処されるギャップは「ギャップ」ではなく「延期」とマークされなければならない
REQ-VSCOPE-03: 真のギャップ（将来のフェーズでもカバーされない）のみが失敗として報告されなければならない

プロセス:

検証 — 標準的なゴール逆行検証を実行
フィルター — 検出されたギャップを後続マイルストーンフェーズとクロスリファレンス
分類 — 延期された項目を真のギャップとは別にマーク

73. Read-Before-Edit ガードフック

対象: フック（PreToolUse）

目的: ファイルが編集前に読み込まれることを確認し、非 Claude ランタイムでの無限リトライループを防止します。

要件:

REQ-RBE-01: フックはセッションで以前に読み込まれていないファイルを対象とする Edit/Write ツールコールを検出しなければならない
REQ-RBE-02: フックはまずファイルを読み込むよう勧告しなければならない（勧告的、非ブロッキング）
REQ-RBE-03: フックは組み込みの read-before-edit 強制のないランタイムで一般的な無限リトライループを防止しなければならない

74. コンテキスト削減

対象: プロンプトアセンブリ・パイプライン

目的: Markdown 切り詰めとキャッシュフレンドリーなプロンプト順序により、コンテキストプロンプトサイズを削減します。

要件:

REQ-CTXRED-01: システムはコンテキスト予算内に収まるよう、大きすぎる Markdown アーティファクトを切り詰めなければならない
REQ-CTXRED-02: キャッシュフレンドリーなアセンブリのためにプロンプトを順序付けなければならない（安定したプレフィックスを先頭に）
REQ-CTXRED-03: 削減は必須情報（見出し、要件、タスク構造）を保持しなければならない
REQ-CTXRED-04: スキルの description: フィールドは ≤ 100 文字でなければならない；npm run lint:descriptions で強制（scripts/lint-descriptions.cjs と tests/skill-frontmatter-contract.test.cjs 参照）

プロセス:

計測 — ワークフローの総プロンプトサイズを計算
切り詰め — 大きすぎるアーティファクトに Markdown 対応の切り詰めを適用
順序付け — KV キャッシュ再利用の最適化のためにプロンプトセクションを配置

75. ディスカスフェーズ `--power` フラグ

フラグ: /gsd-discuss-phase --power

目的: ディスカスフェーズのファイルベースの一括質問回答で、準備済み回答ファイルからのバッチ入力を可能にします。

要件:

REQ-POWER-01: システムはディスカッション質問への事前記述済み回答を含むファイルを受け付けなければならない
REQ-POWER-02: システムは回答を対応するグレーエリア質問にマッピングしなければならない
REQ-POWER-03: システムはインタラクティブなディスカスフェーズと同一の CONTEXT.md を生成しなければならない

76. デバッグ `--diagnose` フラグ

フラグ: /gsd-debug --diagnose

目的: 修正を試みず調査のみを行う診断専用モード。

要件:

REQ-DIAG-01: システムは完全なデバッグ調査（仮説、エビデンス、根本原因）を実行しなければならない
REQ-DIAG-02: システムはコード変更を一切行ってはならない
REQ-DIAG-03: システムは発見事項と推奨修正を含む診断レポートを生成しなければならない

77. フェーズ依存関係分析

コマンド: /gsd-manager --analyze-deps

目的: フェーズ依存関係を検出し、/gsd-manager 実行前に ROADMAP.md への Depends on エントリを提案します。

要件:

REQ-DEP-01: システムはフェーズ間のファイルオーバーラップを検出しなければならない
REQ-DEP-02: システムはセマンティック依存関係（API/スキーマのプロデューサーとコンシューマー）を検出しなければならない
REQ-DEP-03: システムはデータフロー依存関係（出力プロデューサーとリーダー）を検出しなければならない
REQ-DEP-04: システムは依存関係エントリを提案し、書き込み前にユーザー確認を要求しなければならない

生成物: 依存関係提案テーブル；オプションで ROADMAP.md の Depends on フィールドを更新

78. アンチパターン重大度レベル

対象: /gsd-resume-work

目的: 重大度ベースのアンチパターン強制によるリジューム時の必須理解チェック。

要件:

REQ-ANTI-01: システムはアンチパターンを重大度レベルで分類しなければならない
REQ-ANTI-02: システムはセッションリジューム時に必須の理解チェックを強制しなければならない
REQ-ANTI-03: より高い重大度のアンチパターンは承認されるまでワークフロー進行をブロックしなければならない

79. メソドロジーアーティファクトタイプ

対象: プランニングアーティファクト

目的: メソドロジードキュメントの消費メカニズムを定義し、エージェントによって正しく消費されることを確保します。

要件:

REQ-METHOD-01: システムはメソドロジーを独自のアーティファクトタイプとしてサポートしなければならない
REQ-METHOD-02: メソドロジーアーティファクトはエージェント向けの定義された消費メカニズムを持たなければならない

80. プランナー到達可能性チェック

対象: /gsd-plan-phase

目的: 実行にコミットする前にプランステップが達成可能であることを検証します。

要件:

REQ-REACH-01: プランナーは各プランステップが到達可能なファイルと API を参照していることを検証しなければならない
REQ-REACH-02: 到達不可能なステップは実行中ではなくプランニング中にフラグ付けされなければならない

81. Playwright-MCP UI 検証

対象: /gsd-verify-work（オプション）

目的: ベリファイフェーズ中の Playwright-MCP を使用した自動ビジュアル検証。

要件:

REQ-PLAY-01: システムはベリファイフェーズ中のオプションの Playwright-MCP ビジュアル検証をサポートしなければならない
REQ-PLAY-02: ビジュアル検証はオプトインであり、必須であってはならない
REQ-PLAY-03: システムは UI-SPEC.md の期待値に対してビジュアル状態をキャプチャ・比較しなければならない

82. Pause-Work 拡張

対象: /gsd-pause-work

目的: よりリッチなハンドオフデータで非フェーズコンテキストをサポートし、pause-work の適用範囲を拡大します。

要件:

REQ-PAUSE-01: システムは非フェーズコンテキスト（クイックタスク、デバッグセッション、スレッド）でのポーズをサポートしなければならない
REQ-PAUSE-02: ハンドオフデータは現在の作業タイプに適切なよりリッチなコンテキストを含まなければならない

83. レスポンス言語設定

設定: response_language

目的: 非英語ユーザーのためのクロスフェーズ言語一貫性。

要件:

REQ-LANG-01: システムはすべてのフェーズとエージェントで response_language 設定を尊重しなければならない
REQ-LANG-02: 設定はすべてのスポーンされたエージェントに伝播し、一貫した言語出力を確保しなければならない

設定:

設定	型	デフォルト	説明
`response_language`	string	(なし)	エージェントレスポンスの言語コード（例: `"pt"`、`"ko"`、`"ja"`）

84. 手動アップデート手順

対象: docs/manual-update.md

目的: npx が利用不可または npm パブリッシュに障害が発生している環境のための手動アップデートパスを文書化します。

要件:

REQ-MANUAL-01: ドキュメントはステップバイステップの手動アップデート手順を記述しなければならない
REQ-MANUAL-02: 手順は npm アクセスなしで機能しなければならない

85. 新規ランタイムサポート (Trae, Cline, Augment Code)

対象: npx @opengsd/gsd-core

目的: Trae IDE、Cline、Augment Code ランタイムへの GSD インストールを拡張します。

要件:

REQ-TRAE-01: インストーラーは Trae IDE インストールのための --trae フラグをサポートしなければならない
REQ-CLINE-01: インストーラーは .clinerules 設定を通じて Cline をサポートしなければならない
REQ-AUGMENT-01: インストーラーはスキル変換と設定管理で Augment Code をサポートしなければならない

86. 自律モード `--interactive` フラグ

フラグ: /gsd-autonomous --interactive

目的: ディスカスフェーズをインタラクティブ（ユーザーが質問に回答）に保ちながら、プランと実行をバックグラウンドエージェントとしてディスパッチするリーンコンテキスト自律モード。

要件:

REQ-INTERACT-01: --interactive はインタラクティブな質問（自動回答なし）で discuss-phase をメインコンテキスト内でインラインに実行しなければならない
REQ-INTERACT-02: --interactive はコンテキスト分離のために plan-phase と execute-phase をバックグラウンドエージェントとしてディスパッチしなければならない
REQ-INTERACT-03: --interactive はパイプラインの並列性を有効にしなければならない — フェーズ N のビルド中にフェーズ N+1 をディスカス
REQ-INTERACT-04: メインコンテキストはディスカッション会話のみを蓄積しなければならない（リーンコンテキスト）

プロセス:

インラインディスカス — メインコンテキストでユーザーインタラクションとともに discuss-phase を実行
ディスパッチ — プランと実行を新鮮なコンテキストウィンドウを持つバックグラウンドエージェントに送信
パイプライン — バックグラウンドエージェントがフェーズ N をビルドする間、フェーズ N+1 のディスカッションを開始

87. コミットドキュメントガードフック

フック: gsd-commit-docs.js

目的: commit_docs 設定を強制する PreToolUse フックで、planning.commit_docs が false の場合に .planning/ ファイルがコミットされることを防止します。

要件:

REQ-COMMITDOCS-01: フックは .planning/ ファイルをステージングする git commit コマンドを傍受しなければならない
REQ-COMMITDOCS-02: フックは commit_docs が false の場合に .planning/ ファイルを含むコミットをブロックしなければならない
REQ-COMMITDOCS-03: フックは勧告的でなければならない — commit_docs が true または不在の場合はブロックしない

88. コミュニティフックオプトイン

フック: gsd-validate-commit.sh、gsd-session-state.sh、gsd-phase-boundary.sh

目的: GSD プロジェクト向けのオプションの git およびセッションフックで、設定の hooks.community: true の背後にゲートされています。

要件:

REQ-COMMUNITY-01: すべてのコミュニティフックは .planning/config.json の hooks.community が true でない限りノーオペレーションでなければならない
REQ-COMMUNITY-02: gsd-validate-commit.sh は git コミットメッセージに Conventional Commits 形式を強制しなければならない
REQ-COMMUNITY-03: gsd-session-state.sh はセッション状態遷移をトラッキングしなければならない
REQ-COMMUNITY-04: gsd-phase-boundary.sh はフェーズ境界チェックを強制しなければならない

設定:

設定	型	デフォルト	説明
`hooks.community`	boolean	`false`	コミット検証、セッション状態、フェーズ境界のオプションコミュニティフックを有効化

89. グローバル学習ストア

コマンド: フェーズ完了時に自動トリガー；プランナーが消費 設定: features.global_learnings

目的: セッションを超えてプロジェクトをまたいだ学習をグローバルストアに永続化し、プランナーエージェントがプロジェクト履歴全体のパターンから学習できるようにします（現在のセッションだけでなく）。

要件:

REQ-LEARN-01: 学習はフェーズ完了時に .planning/ からグローバルストアに自動コピーされなければならない
REQ-LEARN-02: プランナーエージェントはスポーン時にインジェクションを通じて関連する学習を受け取らなければならない
REQ-LEARN-03: インジェクションはコンテキストの肥大化を避けるために learnings.max_inject でキャップされなければならない
REQ-LEARN-04: 機能は features.global_learnings: true によるオプトインでなければならない

設定:

設定	型	デフォルト	説明
`features.global_learnings`	boolean	`false`	クロスプロジェクト学習パイプラインを有効化
`learnings.max_inject`	number	(システムデフォルト)	プランナーにインジェクトされる最大学習エントリ数

90. クエリ可能コードベースインテリジェンス

コマンド: /gsd-map-codebase --query [<term>|status|diff|refresh] 設定: intel.enabled

目的: コードベース構造、API サーフェス、依存関係グラフ、ファイルロール、アーキテクチャ決定のクエリ可能な JSON インデックスを .planning/intel/ に維持します。コードベース全体を読み込まずにターゲット検索を可能にします。

要件:

REQ-INTEL-01: インテルファイルは .planning/intel/ に JSON として保存されなければならない
REQ-INTEL-02: query モードはすべてのインテルファイルをまたいで用語を検索し、ファイルごとに結果をグループ化しなければならない
REQ-INTEL-03: status モードは鮮度を報告しなければならない（FRESH/STALE、古さの閾値：24 時間）
REQ-INTEL-04: diff モードは現在のインテル状態を最後のスナップショットと比較しなければならない
REQ-INTEL-05: refresh モードはすべてのファイルを再構築するために intel-updater エージェントをスポーンしなければならない
REQ-INTEL-06: 機能は intel.enabled: true によるオプトインでなければならない

生成されるインテルファイル:

ファイル	内容
`stack.json`	テクノロジースタックと依存関係
`api-map.json`	エクスポートされた関数と API サーフェス
`dependency-graph.json`	モジュール間の依存関係
`file-roles.json`	各ソースファイルのロール分類
`arch-decisions.json`	検出されたアーキテクチャ決定

91. 実行コンテキストプロファイル

設定: context_profile

目的: 特定の作業タイプに合わせて調整されたあらかじめ設定された実行コンテキスト（モード、モデル、ワークフロー設定）を選択します（個別設定を手動で調整せずに）。

要件:

REQ-CTX-01: dev プロファイルは反復開発に最適化しなければならない（balanced モデル、plan_check 有効）
REQ-CTX-02: research プロファイルはリサーチ重視の作業に最適化しなければならない（高いモデルティア、research 有効）
REQ-CTX-03: review プロファイルはコードレビュー作業に最適化しなければならない（verifier と code_review 有効）

利用可能なプロファイル: dev、research、review

設定:

設定	型	デフォルト	説明
`context_profile`	string	(なし)	実行コンテキストプリセット：`dev`、`research`、または `review`

92. ゲート分類法

参照: gsd-core/references/gates.md エージェント: plan-checker、verifier

目的: すべてのワークフロー決定ポイントを構造化する 4 つの正規ゲートタイプを定義し、plan-checker と verifier エージェントが一貫したゲートロジックを適用できるようにします。

ゲートタイプ:

タイプ	説明
確認	ユーザーが進行前に承認（例：ロードマップレビュー）
品質	自動化された品質チェックが通過しなければならない（例：プラン検証ループ）
安全	検出されたリスクまたはポリシー違反でのハードストップ
遷移	フェーズまたはマイルストーン境界の確認

要件:

REQ-GATES-01: plan-checker は各チェックポイントを 4 つのゲートタイプのいずれかに分類しなければならない
REQ-GATES-02: verifier はゲートタイプに適したゲートロジックを適用しなければならない
REQ-GATES-03: ハードストップ安全ゲートは --auto フラグでバイパスされてはならない

93. コードレビューパイプライン

コマンド: /gsd-code-review、/gsd-code-review --fix

目的: フェーズ中に変更されたソースファイルの構造化レビューで、各修正をアトミックにコミットする別の自動修正パスを伴います。

要件:

REQ-REVIEW-01: gsd-code-review は SUMMARY.md と git diff フォールバックを使用してフェーズにファイルをスコープしなければならない
REQ-REVIEW-02: レビューは 3 つの深さレベルをサポートしなければならない：quick、standard、deep
REQ-REVIEW-03: 所見は重大度で分類されなければならない：Critical、Warning、Info
REQ-REVIEW-04: gsd-code-review --fix は REVIEW.md を読み込み、デフォルトで Critical および Warning の所見を修正しなければならない
REQ-REVIEW-05: 各修正は説明的なメッセージとともにアトミックにコミットされなければならない
REQ-REVIEW-06: --auto フラグは修正と再レビューの反復ループを有効にしなければならない（最大 3 回）
REQ-REVIEW-07: 機能は workflow.code_review 設定フラグでゲートされなければならない

設定:

設定	型	デフォルト	説明
`workflow.code_review`	boolean	`true`	コードレビューコマンドを有効化
`workflow.code_review_depth`	string	`standard`	デフォルトのレビュー深度：`quick`、`standard`、または `deep`
`workflow.code_review_depth_overrides`	array	`[]`	変更ファイル集合に対するパスプレフィックス一致で特定ディレクトリのレビュー深度をエスカレートする、順序付き `{ paths, depth }` ルール（#2554）。詳細は下記参照。

パススコープのコードレビュー深度オーバーライド

workflow.code_review_depth_overrides は、レビュー対象の変更ファイル集合に対して、セグメント単位のディレクトリパスプレフィックスでルールを照合します。src/auth は src/auth/token.ts および src/auth 自体に一致しますが、src/authfoo/x.ts や docs/src/auth/x.ts には一致しません。照合は git と同様に大文字小文字を区別します。

エスカレーションはレビュー全体単位であり、ファイル単位ではありません：深度はレビューエージェントに渡される単一のスカラー値であり、ファイルごとの設定ではないため、ルールセット全体で一致した最も強いティアがレビュー内のすべてのファイルに適用されます — 機密ファイルが無関係なファイルと同じレビューに含まれたために浅くレビューされることはありません。

v1 はディレクトリプレフィックス一致のみをサポートし、glob 構文はサポートしません：このプロジェクトには glob エンジン（minimatch、picomatch、fast-glob）が存在せず、この機能のために追加もされていません。* や ? を含むパス（例：src/auth/**）は、静かな近似一致ではなく設定エラーとして扱われます。

94. ソクラテス的探索

コマンド: /gsd-explore [topic]

目的: プランにコミットする前にソクラテス的な問いかけを通じてアイデアの探索を開発者にガイドします。出力を適切な GSD アーティファクトにルーティングします：ノート、TODO、シード、リサーチクエスチョン、要件更新、または新規フェーズ。

要件:

REQ-EXPLORE-01: 探索はソクラテス的な問いかけを使用しなければならない — ソリューションを提案する前に質問する
REQ-EXPLORE-02: セッションは出力を適切な GSD アーティファクトにルーティングするオプションを提供しなければならない
REQ-EXPLORE-03: オプションのトピック引数は最初の質問をプライムしなければならない
REQ-EXPLORE-04: 探索はオプションで技術的実現可能性のためにリサーチエージェントをスポーンしなければならない

95. セーフアンドゥ

コマンド: /gsd-undo --last N | --phase NN | --plan NN-MM

目的: フェーズマニフェストと git log を使用して GSD フェーズまたはプランのコミットを安全にロールバックし、依存関係チェックとリバート適用前のハード確認ゲートを伴います。

要件:

REQ-UNDO-01: --phase モードはマニフェストと git log フォールバックを通じてフェーズのすべてのコミットを識別しなければならない
REQ-UNDO-02: --plan モードは特定のプランのすべてのコミットを識別しなければならない
REQ-UNDO-03: --last N モードはインタラクティブな選択のために最近の GSD コミットを表示しなければならない
REQ-UNDO-04: システムはリバート前に依存するフェーズ/プランをチェックしなければならない
REQ-UNDO-05: git revert が実行される前に確認ゲートを表示しなければならない

96. プランインポート

コマンド: /gsd-import --from <filepath>

目的: 外部プランファイルを PROJECT.md 決定との競合検出とともに GSD プランニングシステムに取り込み、有効な GSD PLAN.md に変換して plan-checker で検証します。

要件:

REQ-IMPORT-01: インポーターは外部プランと既存の PROJECT.md 決定間の競合を検出しなければならない
REQ-IMPORT-02: 検出されたすべての競合は書き込み前にユーザーに提示されなければならない
REQ-IMPORT-03: インポートされたプランは有効な GSD PLAN.md 形式として書き込まれなければならない
REQ-IMPORT-04: 書き込まれたプランは gsd-plan-checker 検証を通過しなければならない

97. 高速コードベーススキャン

コマンド: /gsd-map-codebase --fast [--focus tech|arch|quality|concerns]

目的: 1 つまたは 2 つの組み合わせたフォーカスエリアに対して単一のマッパーエージェントをスポーンする /gsd-map-codebase の軽量な代替手段で、4 つの並列エージェントのオーバーヘッドなしに .planning/codebase/ にターゲット出力を生成します。

要件:

REQ-SCAN-01: スキャンは（4 つの並列エージェントではなく）正確に 1 つのマッパーエージェントをスポーンしなければならない
REQ-SCAN-02: フォーカスエリアは次のいずれかでなければならない：tech、arch、quality、concerns、または組み合わせた tech+arch 省略形（デフォルト：tech+arch）；組み合わせフォーカスは 1 回のパスで両エリアをカバーする単一エージェントとして実行
REQ-SCAN-03: 出力は /gsd-map-codebase と同じ形式で .planning/codebase/ に書き込まれなければならない

98. 自律監査から修正

コマンド: /gsd-audit-fix [--source <audit>] [--severity high|medium|all] [--max N] [--dry-run]

目的: 監査を実行し、所見を自動修正可能と手動のみに分類し、テスト検証とアトミックコミットで自動修正可能な問題を自律的に修正するエンドツーエンドパイプライン。

要件:

REQ-AUDITFIX-01: 所見は変更前に自動修正可能または手動のみとして分類されなければならない
REQ-AUDITFIX-02: 各修正はコミット前にテストで検証されなければならない
REQ-AUDITFIX-03: 各修正はアトミックにコミットされなければならない
REQ-AUDITFIX-04: --dry-run は修正を適用せずに分類テーブルを表示しなければならない
REQ-AUDITFIX-05: --max N は 1 回の実行で適用される修正数を制限しなければならない（デフォルト：5）

99. 改善されたプロンプトインジェクションスキャナー

フック: gsd-prompt-guard.js、gsd-read-injection-scanner.js スクリプト: scripts/prompt-injection-scan.sh、scripts/base64-scan.sh

目的: プランニングアーティファクトおよび取り込んだコンテンツ内のプロンプトインジェクション試行の多層防御検出。ライブフックはフック独立性のために独自のパターンサブセットをインライン化します（security.cts からインポートしません）。CIスキャナー（security.cts の scanForInjection）は、テストでのコードベース全体スキャン用の集中エンジンを提供します。

要件:

REQ-SCAN-INJ-01: ライブフックは不可視 Unicode 文字（ゼロ幅スペース、ソフトハイフン、Unicode タグブロック U+E0000–E007F）を検出しなければならない
REQ-SCAN-INJ-02: ライブフックは既知のインジェクションパターン（命令オーバーライド、ロール操作、システムプロンプト抽出、偽のメッセージ境界）を検出しなければならない。Base64 デコードスキャンは CI 時制御（scripts/base64-scan.sh）であり、ライブフックではない — ライブフックは base64 持ち出しフレーズ正規表現のみを一致させ、デコードはしない。
REQ-SCAN-INJ-03: ~~スキャナーはエントロピー分析を適用しなければならない~~ — エントロピー分析（scanEntropyAnomalies）は #2198 でデッドコードとして削除された（本番呼び出し元ゼロ；ライブフックはエントロピー分析を実行しない）。この要件は保守可能なライブ実装まで保留。
REQ-SCAN-INJ-04: スキャナーは勧告的のみでなければならない — 検出はログに記録されるが、ブロッキングではない

100. プランフェーズのストール検出

コマンド: /gsd-plan-phase

目的: プランナーの修正ループが停止した（複数のイテレーションにわたって同じ出力を生成している）ことを検出し、異なる戦略にエスカレートするか明確な診断で終了してサイクルを破ります。

要件:

REQ-STALL-01: 修正ループは連続するイテレーション全体で同一のプラン出力を検出しなければならない
REQ-STALL-02: ストール検出時、システムは再試行前に戦略をエスカレートしなければならない
REQ-STALL-03: 最大ストール再試行数は制限されなければならない（既存の最大 3 イテレーションでキャップ）

101. /gsd-progress --next のハードストップ安全ゲート

コマンド: /gsd-progress --next

目的: 繰り返し同一ステップが検出された場合に自律チェーニングを中断するハードストップ安全ゲートと連続呼び出しガードを追加し、/gsd-progress --next の暴走ループを防止します。

要件:

REQ-NEXT-GATE-01: /gsd-progress --next は連続した同一ステップ呼び出しをトラッキングしなければならない
REQ-NEXT-GATE-02: 同一ステップの繰り返し時、システムはユーザーにハードストップゲートを提示しなければならない
REQ-NEXT-GATE-03: ユーザーはハードストップゲートを通過して続行するために明示的に確認しなければならない

102. アダプティブモデルプリセット

設定: model_profile: "adaptive"

目的: すべてのエージェントに単一のティアを適用するのではなく、現在のエージェントのロールに基づいて適切なモデルティアを自動的に選択するロールベースのモデル割り当て。

要件:

REQ-ADAPTIVE-01: adaptive プリセットはエージェントロールに基づいてモデルティアを割り当てなければならない（planner → quality ティア、executor → balanced ティアなど）
REQ-ADAPTIVE-02: adaptive は /gsd-config --profile adaptive で選択可能でなければならない

103. ポストマージハンク検証

コマンド: /gsd-update --reapply

目的: アップデート後のローカルパッチ適用後、すべてのハンクが実際に適用されたことを期待されるパッチ内容とライブファイルシステムを比較することで検証します。不完全なマージをサイレントに受け入れるのではなく、ドロップされたまたは部分的なハンクを即座に表示します。

要件:

REQ-PATCH-VERIFY-01: reapply-patches はマージ後に各ハンクが適用されたことを検証しなければならない
REQ-PATCH-VERIFY-02: ドロップされたまたは部分的なハンクはファイルと行のコンテキストとともにユーザーに報告されなければならない
REQ-PATCH-VERIFY-03: 検証はパッチごとではなく、すべてのパッチが適用された後に実行されなければならない

v1.35.0 機能

新規ランタイムサポート (Cline, CodeBuddy, Qwen Code)
GSD-2 逆マイグレーション
AI 統合フェーズウィザード
AI 評価レビュー

104. 新規ランタイムサポート (Cline, CodeBuddy, Qwen Code)

対象: npx @opengsd/gsd-core

目的: Cline、CodeBuddy、Qwen Code ランタイムへの GSD インストールを拡張します。

要件:

REQ-CLINE-02: Cline インストールは .clinerules を ~/.cline/（グローバル）または ./.cline/（ローカル）に書き込まなければならない。カスタムスラッシュコマンドなし — ルールベースの統合のみ。フラグ：--cline。
REQ-CODEBUDDY-01: CodeBuddy インストールはスキルを ~/.codebuddy/skills/gsd-*/SKILL.md にデプロイしなければならない。フラグ：--codebuddy。
REQ-QWEN-01: Qwen Code インストールはスキルを ~/.qwen/skills/gsd-*/SKILL.md にデプロイしなければならない（Claude Code 2.1.88+ で使用されるオープン標準に従う）。QWEN_CONFIG_DIR 環境変数はデフォルトパスをオーバーライドします。フラグ：--qwen。

ランタイムサマリー:

ランタイム	インストール形式	設定パス	フラグ
Cline	`.clinerules`	`~/.cline/` または `./.cline/`	`--cline`
CodeBuddy	スキル (`SKILL.md`)	`~/.codebuddy/skills/`	`--codebuddy`
Qwen Code	スキル (`SKILL.md`)	`~/.qwen/skills/`	`--qwen`

105. GSD-2 逆マイグレーション

コマンド: /gsd-import --from-gsd2 [--dry-run] [--force] [--path <dir>]

目的: GSD-2 形式（Milestone→Slice→Task 階層の .gsd/ ディレクトリ）のプロジェクトを v1 の .planning/ 形式に移行し、すべての GSD v1 コマンドとの完全な互換性を復元します。

要件:

REQ-FROM-GSD2-01: インポーターは指定または現在のディレクトリから .gsd/ を読み込まなければならない
REQ-FROM-GSD2-02: Milestone→Slice 階層は連続したフェーズ番号に平坦化されなければならない（M001/S01→フェーズ 01、M001/S02→フェーズ 02、M002/S01→フェーズ 03 など）
REQ-FROM-GSD2-03: --force なしに既存の .planning/ ディレクトリを上書きしないよう保護しなければならない
REQ-FROM-GSD2-04: --dry-run はファイルを書き込まずにすべての変更をプレビューしなければならない
REQ-FROM-GSD2-05: マイグレーションは PROJECT.md、REQUIREMENTS.md、ROADMAP.md、STATE.md、および連続したフェーズディレクトリを生成しなければならない

フラグ:

フラグ	説明
`--dry-run`	ファイルを書き込まずにマイグレーション出力をプレビュー
`--force`	既存の `.planning/` ディレクトリを上書き
`--path <dir>`	GSD-2 ルートディレクトリを指定

106. AI 統合フェーズウィザード

コマンド: /gsd-ai-integration-phase [N]

目的: プロジェクトフェーズで AI/LLM 機能の選択、統合、評価計画を開発者にガイドします。プランニングと検証に組み込まれる構造化された AI-SPEC.md を生成します。

要件:

REQ-AISPEC-01: ウィザードはフレームワーク選択、モデル選択、統合アプローチをカバーするインタラクティブな決定マトリックスを提示しなければならない
REQ-AISPEC-02: システムはプロジェクトタイプに関連するドメイン固有の失敗モードと評価基準を表示しなければならない
REQ-AISPEC-03: システムは 3 つの並列専門家エージェントをスポーンしなければならない：domain-researcher、framework-selector、eval-planner
REQ-AISPEC-04: 出力はフレームワーク推奨、実装ガイダンス、評価戦略を含む {phase}-AI-SPEC.md を生成しなければならない

生成物: フェーズディレクトリ内の {phase}-AI-SPEC.md

107. AI 評価レビュー

コマンド: /gsd-eval-review [N]

目的: 実行された AI フェーズの評価カバレッジを AI-SPEC.md プランと照合して遡及的に監査します。フェーズが閉じられる前に計画済みと実装済みの評価間のギャップを特定します。

要件:

REQ-EVALREVIEW-01: レビューは指定されたフェーズから AI-SPEC.md を読み込まなければならない
REQ-EVALREVIEW-02: 各評価ディメンションは COVERED、PARTIAL、または MISSING としてスコアリングされなければならない
REQ-EVALREVIEW-03: 出力は所見、ギャップ説明、および修正ガイダンスを含まなければならない
REQ-EVALREVIEW-04: EVAL-REVIEW.md はフェーズディレクトリに書き込まれなければならない

生成物: スコアリングされた評価ディメンション、ギャップ分析、修正ステップを含む {phase}-EVAL-REVIEW.md

v1.36.0 機能

108. プランバウンス

コマンド: /gsd-plan-phase N --bounce

目的: プランがチェッカーを通過した後、外部スクリプト（2 番目の AI、リンター、カスタムバリデーター）を通じてオプションで精製します。バウンスステップは各プランをバックアップし、スクリプトを実行し、結果の YAML フロントマターの整合性を検証し、プランチェッカーを再実行し、何か失敗した場合は元に戻します。

要件:

REQ-BOUNCE-01: --bounce フラグまたは workflow.plan_bounce: true がステップを有効化；--skip-bounce は常に無効化
REQ-BOUNCE-02: workflow.plan_bounce_script は有効な実行ファイルを指していなければならない；スクリプトが見つからない場合は警告を生成してスキップ
REQ-BOUNCE-03: 各プランはスクリプト実行前に *-PLAN.pre-bounce.md にバックアップされる
REQ-BOUNCE-04: YAML フロントマターが壊れているまたはプランチェッカーが失敗したバウンスされたプランはバックアップから復元される
REQ-BOUNCE-05: workflow.plan_bounce_passes（デフォルト：2）はスクリプトが受け取る精製パス数を制御する

設定: workflow.plan_bounce、workflow.plan_bounce_script、workflow.plan_bounce_passes

109. 外部コードレビューコマンド

コマンド: /gsd-ship（強化版）

目的: /gsd-ship の手動レビューステップの前に、設定されている場合は外部コードレビューコマンドを自動的に実行します。コマンドは stdin を通じて diff とフェーズコンテキストを受け取り、JSON verdict（APPROVED または REVISE）を返します。結果に関わらず既存の手動レビューフローにフォールスルーします。

要件:

REQ-EXTREVIEW-01: workflow.code_review_command はコマンド文字列に設定されなければならない；null はスキップを意味する
REQ-EXTREVIEW-02: diff は --stat サマリーを含めて BASE_BRANCH に対して生成される
REQ-EXTREVIEW-03: レビュープロンプトは stdin を通じてパイプされる（シェルインターポレートされない）
REQ-EXTREVIEW-04: 120 秒タイムアウト；失敗時に stderr をキャプチャ
REQ-EXTREVIEW-05: verdict、confidence、summary、issues フィールドの JSON 出力をパース

設定: workflow.code_review_command

110. クロス AI 実行デリゲーション

コマンド: /gsd-execute-phase N --cross-ai

目的: 個々のプランを実行のために外部 AI ランタイムにデリゲートします。フロントマターに cross_ai: true があるプラン（または --cross-ai 使用時はすべてのプラン）が stdin を通じて設定済みコマンドに送信されます。正常に処理されたプランは通常の executor キューから削除されます。

要件:

REQ-CROSSAI-01: --cross-ai はすべてのプランをクロス AI に強制；--no-cross-ai は無効化
REQ-CROSSAI-02: workflow.cross_ai_execution: true とプランフロントマター cross_ai: true がプランごとのアクティベーションに必要
REQ-CROSSAI-03: タスクプロンプトはインジェクションを防ぐために stdin を通じてパイプされる
REQ-CROSSAI-04: ダーティなワーキングツリーは実行前に警告を生成する
REQ-CROSSAI-05: 失敗時、ユーザーは選択する：再試行、スキップ（通常の executor にフォールバック）、またはアボート

設定: workflow.cross_ai_execution、workflow.cross_ai_command、workflow.cross_ai_timeout

111. アーキテクチャ責任マッピング

コマンド: /gsd-plan-phase（強化されたリサーチステップ）

目的: フェーズリサーチ中に、phase-researcher が各機能をそのアーキテクチャティアオーナー（ブラウザ、フロントエンドサーバー、API、CDN/スタティック、データベース）にマッピングします。プランナーはこのマップに対してタスクをクロスリファレンスし、plan-checker はディメンション 7c としてティアコンプライアンスを強制します。

要件:

REQ-ARM-01: Phase researcher は RESEARCH.md にアーキテクチャ責任マップテーブルを生成しなければならない（ステップ 1.5）
REQ-ARM-02: プランナーはマップに対してタスクからティアへの割り当てをサニティチェックしなければならない
REQ-ARM-03: Plan checker はディメンション 7c としてティアコンプライアンスを検証しなければならない（一般的な不一致は WARNING、セキュリティに敏感なものは BLOCKER）

生成物: {phase}-RESEARCH.md 内の ## Architectural Responsibility Map セクション

112. 学習の抽出

コマンド: /gsd-extract-learnings N

目的: 完了したフェーズのアーティファクトから構造化された知識を抽出します。PLAN.md と SUMMARY.md（必須）および VERIFICATION.md、UAT.md、STATE.md（オプション）を読み込み、決定、教訓、パターン、驚きの 4 カテゴリの学習を生成します。オプションで capture_thought ツールを通じて各項目を外部ナレッジベースにキャプチャします。

要件:

REQ-LEARN-01: PLAN.md と SUMMARY.md が必要；見つからない場合は明確なエラーで終了
REQ-LEARN-02: 各抽出された項目にはソース帰属（アーティファクトとセクション）が含まれる
REQ-LEARN-03: capture_thought ツールが利用可能な場合、source、project、phase メタデータとともに項目をキャプチャする
REQ-LEARN-04: capture_thought が利用不可の場合、正常に完了し、外部キャプチャがスキップされたことをログに記録する
REQ-LEARN-05: 2 回実行すると前の LEARNINGS.md が上書きされる

生成物: YAML フロントマター（phase、project、カテゴリごとのカウント、missing_artifacts）を含む {phase}-LEARNINGS.md

オプション統合 — capture_thought: capture_thought はバンドルされたツールではなく、規約です。GSD はそれを同梱せず、必須でもありません。ワークフローは現在のセッションの MCP サーバーが capture_thought という名前のツールを公開しているかどうかを確認し、公開している場合は以下のシグネチャで抽出した学習ごとに 1 回呼び出します。そのようなツールが存在しない場合、ステップはサイレントにスキップされ、LEARNINGS.md が主要な出力として残ります。

期待されるツールシグネチャ：

capture_thought({
  category: "decision" | "lesson" | "pattern" | "surprise",
  phase: <phase_number>,
  content: <learning_text>,
  source: <artifact_name>
})

メモリ / ナレッジベース MCP サーバー（例：ExoCortex スタイルのサーバー、claude-mem、または mem0 スタイルのサーバー）を実行するユーザーは、このツール名を実装して、project、phase、source メタデータとともに学習を自動的にナレッジベースにルーティングできます。それ以外のユーザーは追加のセットアップなしに /gsd-extract-learnings を使用できます — LEARNINGS.md アーティファクトが機能です。

114. コンテキストウィンドウ対応プロンプト薄化

目的: 200K トークン未満のコンテキストウィンドウを持つモデルのスタティックプロンプトオーバーヘッドを最大 40% 削減します。拡張例とアンチパターンリストがエージェント定義から @ required_reading を通じてオンデマンドで読み込まれる参照ファイルに抽出されます。

要件:

REQ-THIN-01: CONTEXT_WINDOW < 200000 の場合、executor と planner のエージェントプロンプトはインライン例を省略する
REQ-THIN-02: 抽出されたコンテンツは references/executor-examples.md と references/planner-antipatterns.md に存在する
REQ-THIN-03: 標準（200K-500K）と拡張（500K+）ティアは影響を受けない
REQ-THIN-04: コアルールと決定ロジックはインラインのまま；詳細な例のみが抽出される

参照ファイル: executor-examples.md、planner-antipatterns.md

115. 設定可能な CLAUDE.md パス

目的: プロジェクトが CLAUDE.md をルート以外の場所に保存できるようにします。claude_md_path 設定キーは /gsd-profile-user および関連コマンドが生成された CLAUDE.md ファイルを書き込む場所を制御します。

要件:

REQ-CMDPATH-01: claude_md_path はデフォルトで ./CLAUDE.md
REQ-CMDPATH-02: プロファイル生成コマンドは設定からパスを読み込み、指定された場所に書き込む
REQ-CMDPATH-03: 相対パスはプロジェクトルートから解決される

設定: claude_md_path

116. TDD パイプラインモード

目的: オプトインの TDD（レッドグリーンリファクタリング）をファーストクラスのフェーズ実行モードとして提供します。有効にすると、プランナーは適切なタスクに対して積極的に type: tdd を選択し、executor は RED/GREEN/REFACTOR ゲートシーケンスを強制し、RED 前の予期しない GREEN でフェイルファストします。

要件:

REQ-TDD-01: workflow.tdd_mode 設定キー（boolean、デフォルト false）
REQ-TDD-02: 有効時、プランナーは references/tdd.md の TDD ヒューリスティックをすべての適格なタスク（ビジネスロジック、API、バリデーション、アルゴリズム、ステートマシン）に適用する
REQ-TDD-03: Executor は type: tdd プランのゲートシーケンスを強制する — RED コミット（test(...)）は GREEN コミット（feat(...)）より先でなければならない
REQ-TDD-04: Executor は RED フェーズ中にテストが予期しなくパスした場合にフェイルファストする（機能がすでに存在するかテストが間違っている）
REQ-TDD-05: フェーズ終了時の協調レビューチェックポイントがすべての TDD プランにわたるゲートコンプライアンスを確認する（勧告的、非ブロッキング）
REQ-TDD-06: ゲート違反は SUMMARY.md の ## TDD Gate Compliance セクション下に表示される

設定: workflow.tdd_mode 参照ファイル: tdd.md、checkpoints.md

v1.37.0 機能

117. スパイクコマンド

コマンド: /gsd-spike [idea] [--quick]

目的: 実装アプローチにコミットする前に 2〜5 つの焦点を絞った実現可能性実験を実行します。各実験は Given/When/Then フレーミングを使用し、実行可能なコードを生成し、VALIDATED / INVALIDATED / PARTIAL verdict を返します。コンパニオンの /gsd-spike --wrap-up は所見をプロジェクトローカルのスキルにパッケージ化します。

要件:

REQ-SPIKE-01: 各実験はコードが書かれる前に Given/When/Then 仮説を生成しなければならない
REQ-SPIKE-02: 各実験は動作するコードまたは最小限の再現を含まなければならない
REQ-SPIKE-03: 各実験はエビデンスとともに VALIDATED、INVALIDATED、または PARTIAL verdict のいずれかを返さなければならない
REQ-SPIKE-04: 結果は .planning/spikes/NNN-experiment-name/ に README と MANIFEST.md とともに保存されなければならない
REQ-SPIKE-05: --quick フラグはインテーク会話をスキップし、引数テキストを実験方向として使用する
REQ-SPIKE-06: /gsd-spike --wrap-up は所見を .claude/skills/spike-findings-[project]/ にパッケージ化しなければならない

生成物:

アーティファクト	説明
`.planning/spikes/NNN-name/README.md`	仮説、実験コード、verdict、エビデンス
`.planning/spikes/MANIFEST.md`	verdict を含むすべてのスパイクのインデックス
`.claude/skills/spike-findings-[project]/`	パッケージ化された所見（`/gsd-spike --wrap-up` 経由）

118. スケッチコマンド

コマンド: /gsd-sketch [idea] [--quick] [--text]

目的: 実装にコミットする前に使い捨ての HTML モックアップを通じてデザイン方向を探索します。デザインの質問ごとに 2〜3 のインタラクティブなバリアントを生成し、ビルドステップなしにブラウザで直接閲覧できます。コンパニオンの /gsd-sketch --wrap-up は勝利した決定をプロジェクトローカルのスキルにパッケージ化します。

要件:

REQ-SKETCH-01: 各スケッチは 1 つの特定のビジュアルデザイン質問に答えなければならない
REQ-SKETCH-02: 各スケッチはタブナビゲーションを持つ単一の index.html に 2〜3 の意味のある異なるバリアントを含まなければならない
REQ-SKETCH-03: すべてのインタラクティブ要素（ホバー、クリック、トランジション）は機能しなければならない
REQ-SKETCH-04: スケッチはリアルに近いコンテンツを使用しなければならない（ lorem ipsum ではない）
REQ-SKETCH-05: 共有の themes/default.css は合意された美観に適応した CSS 変数を提供しなければならない
REQ-SKETCH-06: --quick フラグはムードインテークをスキップ；--text フラグは非 Claude ランタイム用に AskUserQuestion を番号付きリストに置き換える
REQ-SKETCH-07: 勝利バリアントは README フロントマターと HTML タブの ★ でマークされなければならない
REQ-SKETCH-08: /gsd-sketch --wrap-up は勝利した決定を .claude/skills/sketch-findings-[project]/ にパッケージ化しなければならない

生成物:

アーティファクト	説明
`.planning/sketches/NNN-name/index.html`	2〜3 のインタラクティブ HTML バリアント
`.planning/sketches/NNN-name/README.md`	デザイン質問、バリアント、勝者、注目点
`.planning/sketches/themes/default.css`	共有 CSS テーマ変数
`.planning/sketches/MANIFEST.md`	勝者を含むすべてのスケッチのインデックス
`.claude/skills/sketch-findings-[project]/`	パッケージ化された決定（`/gsd-sketch --wrap-up` 経由）

119. エージェントサイズ予算強制

目的: CI で強制される段階的な行数制限でエージェントプロンプトファイルをリーンに保ちます。過大なエージェントは本番のコンテキストウィンドウを肥大化させる前にキャッチされます。

要件:

REQ-BUDGET-01: agents/gsd-*.md ファイルは 3 つのティアに分類される：XL（≤ 1,600 行）、Large（≤ 1,000 行）、Default（≤ 500 行）
REQ-BUDGET-02: ティア割り当てはファイルの YAML フロントマターで宣言される（size: xl | large | default）
REQ-BUDGET-03: tests/agent-size-budget.test.cjs は制限を強制し、違反時に CI を失敗させる
REQ-BUDGET-04: size フロントマターキーのないファイルはデフォルト（500 行）制限にデフォルトする

テストファイル: tests/agent-size-budget.test.cjs

120. 共有ボイラープレート抽出

目的: 共通の 2 つのボイラープレートブロックをオンデマンドで読み込まれる共有参照ファイルに抽出することでエージェント間の重複を削減します。エージェントファイルをサイズ予算内に保ち、ボイラープレートの更新を単一ファイルの変更にします。

要件:

REQ-BOILER-01: 必須初期読み込み命令は references/mandatory-initial-read.md に抽出される
REQ-BOILER-02: プロジェクトスキルディスカバリー命令は references/project-skills-discovery.md に抽出される
REQ-BOILER-03: 以前これらのブロックをインライン化していたエージェントは @ required_reading を通じてそれらを参照しなければならない

参照ファイル: references/mandatory-initial-read.md、references/project-skills-discovery.md

121. ナレッジグラフ統合

目的: .planning/graphs/ にプロジェクトの軽量なナレッジグラフを構築、クエリ、検査します。プロジェクトごとのオプトイン。ユーザー向けコマンドの /gsd-graphify とプログラマティックな gsd-tools.cjs graphify … 動詞ファミリーとして公開されています。コマンド、エージェント、ワークフロー、フェーズをまたいだノードとエッジのグラフ指向ビューで /gsd-map-codebase --query（スナップショット指向）を補完します。

要件:

REQ-GRAPH-01: .planning/config.json の graphify.enabled: true によるオプトイン。無効時、/gsd-graphify はアクティベーションヒントを表示して書き込みなしで停止。
REQ-GRAPH-02: スラッシュコマンド /gsd-graphify はサブコマンド build、query <term>、status、diff を公開。プログラマティック CLI node gsd-tools.cjs graphify … はさらに snapshot を公開し、graphify build の最終ステップとして自動的に呼び出される。
REQ-GRAPH-03: ビルドは設定可能な graphify.build_timeout（秒）内で実行；タイムアウトを超えた場合、部分的なグラフを残さずにクリーンに中断。
REQ-GRAPH-04: graphify.cjs は graph.edges が存在しない場合に graph.links にフォールバックし、古いグラフアーティファクトが引き続きレンダリングされるようにする。
REQ-GRAPH-05: Graphify は gsd-tools.cjs graphify ... コマンドハンドラーを通じて呼び出される。

設定: graphify.enabled、graphify.build_timeout 参照ファイル: commands/gsd/graphify.md、bin/lib/graphify.cjs

v1.40.0 機能

122. スキルサーフェス統合

目的: 31 のマイクロスキルを 4 つの新しいグループ化された親と、サブ操作をフラグとして吸収する 6 つの既存の親に折りたたんで、積極的なスキルリストのオーバーヘッドを削減します。機能的な損失はゼロ — 削除されたすべてのマイクロスキルの動作は統合された親のフラグを通じて存続します。統合後、commands/gsd/*.md は 59 のサブスキル（plus 6 つのネームスペースメタスキル、#123 参照）を搭載。

要件:

REQ-CONSOLIDATE-01: 4 つの新しいグループ化されたスキルがマイクロスキルのクラスターを置き換える：
- /gsd-capture — add-todo（デフォルト）、note（--note）、add-backlog（--backlog）、plant-seed（--seed）、check-todos（--list）を折りたたむ
- /gsd-phase — add-phase（デフォルト）、insert-phase（--insert）、remove-phase（--remove）、edit-phase（--edit）を折りたたむ
- /gsd-config — settings-advanced（--advanced）、settings-integrations（--integrations）、set-profile（--profile）を折りたたむ
- /gsd-workspace — new-workspace（--new）、list-workspaces（--list）、remove-workspace（--remove）を折りたたむ
REQ-CONSOLIDATE-02: 6 つの既存の親がラップアップ/サブ操作をフラグとして吸収：/gsd-update --sync、/gsd-update --reapply、/gsd-sketch --wrap-up、/gsd-spike --wrap-up、/gsd-map-codebase --fast、/gsd-map-codebase --query、/gsd-code-review --fix、/gsd-progress --do、/gsd-progress --next。
REQ-CONSOLIDATE-03: 削除されたマイクロスキルスラッシュフォーム（gsd-add-todo、gsd-add-backlog、gsd-plant-seed、gsd-check-todos、gsd-add-phase、gsd-insert-phase、gsd-remove-phase、gsd-edit-phase、gsd-new-workspace、gsd-list-workspaces、gsd-remove-workspace、gsd-settings-advanced、gsd-settings-integrations、gsd-set-profile、gsd-sketch-wrap-up、gsd-spike-wrap-up、gsd-reapply-patches、gsd-code-review-fix、…）は「Unknown command」に解決しなければならない — シャドウスタブなし。
REQ-CONSOLIDATE-04: autonomous.md は（削除された gsd-code-review-fix を以前呼び出していた代わりに）/gsd-code-review --fix を呼び出す。

参照 issue: #2790

123. ネームスペースメタスキル（2 段階ルーティング）

目的: フラットな積極的スキルリストを 2 段階の階層的ルーティングレイヤーに置き換えます。モデルは 86 エントリの代わりに 6 つのネームスペースルーターを認識し、ネームスペースを選択してからサブスキルにルーティングします。説明にはルーティング密度のためにパイプ区切りのキーワードタグ（≤ 60 文字）を使用します。

コマンド:

/gsd-workflow — フェーズパイプラインルーター（discuss / plan / execute / verify / phase / progress）
/gsd-project — プロジェクトライフサイクル（マイルストーン、監査、サマリー）
/gsd-quality — 品質ゲート（コードレビュー、デバッグ、監査、セキュリティ、評価、UI）
/gsd-context — コードベースインテリジェンス（マップ、グラファイファイ、ドキュメント、学習）
/gsd-manage — 設定 / ワークスペース / ワークストリーム / スレッド / アップデート / シップ / インボックス
/gsd-ideate — 探索とキャプチャ（探索、スケッチ、スパイク、スペック、キャプチャ）

トークンコスト:

	エントリ数	概算トークン
v1.40 以前のフルインストール	86	~2,150
ネームスペースメタスキル	6	~120

要件:

REQ-NS-01: 6 つの commands/gsd/ns-*.md ネームスペースルーターはパイプ区切りのキーワードタグ説明（≤ 60 文字）とともに搭載される。
REQ-NS-02: 既存のサブスキルは変更されず、引き続き直接呼び出し可能 — ネームスペーススキルは直接スラッシュフォームの置き換えではなく追加的。
REQ-NS-03: 各ネームスペースルーターの本体には、#2790 以後の統合されたサーフェス上の正しい具体的なサブスキルへのユーザーインテントをマッピングするルーティングテーブルが含まれる。

参照 issue: #2792

124. コンテキストウィンドウ使用率ガード

コマンド: /gsd-health --context

目的: コンテキストウィンドウの飽和に対する品質ガード。2 つの閾値：60% 使用率で警告（「/gsd-thread を検討してください」）、70% でクリティカル（「推論品質が低下する可能性があります」；最近のコンテキストアテンション研究による破断点に一致）。

要件:

REQ-CTX-GUARD-01: /gsd-health --context は現在の使用率、閾値ティア（ok / warn / critical）、修正提案を含む構造化されたステータス行を出力する。
REQ-CTX-GUARD-02: 同じトリアージは gsd-tools.cjs validate context --tokens-used <int> --context-window <int> として公開されている — ステータス行とフック呼び出し元の構造化エンベロープ（#125）。両フラグは必須；ハンドラーは REQ-CTX-GUARD-03 の純粋な分類器と同じ { percent, state } エンベロープを返す。
REQ-CTX-GUARD-03: 分類器（bin/lib/context-utilization.cjs）は純粋：入力 (tokensUsed, contextWindow)、出力 { percent, state }。ユニットテストが容易で、任意の呼び出し元から再利用しやすい。

参照 issue: #2792

125. フェーズライフサイクルステータス行リードサイド

目的: ステータス行にフェーズオーケストレーション状態を表示します。parseStateMd() は 4 つの新しい STATE.md フロントマターフィールドを読み込み、formatGsdState() は実行中、アイドル、および進行状況シーンをレンダリングします。ライトサイドの配線は後の RC で行われます。

要件:

REQ-LIFECYCLE-01: parseStateMd() は 4 つのオプションフィールドを読み込む：
- active_phase — オーケストレーターが実行中のフェーズ番号
- next_action — アイドル時の推奨される次のコマンド
- next_phases — 次のフェーズ番号の YAML フロー配列
- progress — ネストされた total_phases / completed_phases / percent ブロック
REQ-LIFECYCLE-02: formatGsdState() はライフサイクルフィールドを優先順位の順にチェックし、最初に一致するシーンを出力する（フェーズアクティブ → アイドル次推奨 → マイルストーン完了 → デフォルトフォールバック）。
REQ-LIFECYCLE-03: 4 つのフィールドはすべてデフォルトで undefined；既存の STATE.md ファイルはバイト単位で同一にレンダリングされる。

参照 issue: #2833 — フルフィールドリファレンスとレンダリングルールについては docs/STATE-MD-LIFECYCLE.md を参照。

v1.41.0 機能

126. フェーズタイプごとのモデル選択

目的: フルエージェント分類法を習得せずにフェーズレベル（プランニング、リサーチ、実行、検証）でモデルチューニングを表現します。エージェントごとの model_overrides（精密、冗長）とグローバル model_profile ティア（粗い、均一）の中間に位置します。

設定キー: .planning/config.json の models

フェーズタイプスロット:

スロット	割り当てられたエージェント
`planning`	`gsd-planner`、`gsd-roadmapper`、`gsd-pattern-mapper`
`discuss`	`gsd-assumptions-analyzer`
`research`	`gsd-phase-researcher`、`gsd-project-researcher`、`gsd-research-synthesizer`、`gsd-codebase-mapper`、`gsd-ui-researcher`
`execution`	`gsd-executor`、`gsd-debugger`、`gsd-doc-writer`
`verification`	`gsd-verifier`、`gsd-plan-checker`、`gsd-integration-checker`、`gsd-nyquist-auditor`、`gsd-ui-checker`、`gsd-ui-auditor`、`gsd-doc-verifier`、`gsd-code-reviewer`
`completion`	（将来のサブエージェント用に予約）

受け入れられる値: "opus" / "sonnet" / "haiku" / "inherit"

解決の優先順位（高→低）:

1. model_overrides[<agent>]
2. dynamic_routing.tier_models[<tier>]   (有効時)
3. models[<phase_type>]                  (この機能)
4. model_profile
5. ランタイムデフォルト

要件:

REQ-PHASE-MODELS-01: 6 つの名前付き models.* スロットが config-schema.cjs と config-schema.ts に受け入れられる；config-set は不明なフェーズタイプを拒否する。
REQ-PHASE-MODELS-02: models ブロックのない設定は v1.41 以前の動作とバイト単位で同一に動作する。
REQ-PHASE-MODELS-03: discuss と completion は前方互換性のためにスキーマに受け入れられる；今日それらを設定することはサブエージェントが各にマッピングされるまでノーオペレーション。

参照 issue: #3023

127. 失敗ティアエスカレーション付き動的ルーティング

目的: デフォルトで安価なティアを使用し、オーケストレーターがソフト失敗（検証が決定的でない、プランチェック FLAG など）を検出した場合に自動的により有能なモデルにエスカレートします。

設定キー: .planning/config.json の dynamic_routing

動作:

enabled: false（デフォルト）— 機能はオフ；すべてのエージェントは変更なしに優先順位チェーンを使用。
enabled: true — リゾルバーは最初のスポーンに tier_models[default_tier] を選択し、オーケストレーターが検出したソフト失敗で 1 ティア上にエスカレートし、max_escalations でキャップ。

構成: model_overrides は常に優先；dynamic_routing.tier_models[<tier>] は models.<phase_type> と model_profile より上で解決。

要件:

REQ-DYNROUTE-01: dynamic_routing.enabled はマスタースイッチとして機能；false またはブロックが存在しない場合、動作変更はゼロ。
REQ-DYNROUTE-02: 新しいリゾルバー resolveModelForTier(cwd, agent, attempt)（core.cjs 内）はオーケストレーター統合の単一コールサイト。
REQ-DYNROUTE-03: max_escalations はランナウェイコストを防ぐためにエスカレーションチェーンをキャップ。

参照 issue: #3024

128. アップデートバナーオプトイン

目的: GSD ステータス行を拒否またはバイパスしたユーザーに、ステータス行を必要とせずにアップデートの可用性を表示します。

動作:

インストール時、インストーラーが GSD ステータス行を検出しない場合、オプトインの SessionStart フックを提供します。
フックはステータス行で使用されているのと同じキャッシュ ~/.cache/gsd/gsd-update-check.json を読み込み、アップデートが利用可能な場合のみバナーを表示します。
最新の場合はサイレント。
障害診断は 24 時間に 1 回に制限。
npx @opengsd/gsd-core --uninstall によってクリーンに削除。

要件:

REQ-BANNER-01: バナーは明示的なオプトインなしにインストールされない。
REQ-BANNER-02: 追加のネットワークリクエストなし — 既存のバックグラウンドアップデートチェックキャッシュを再利用。
REQ-BANNER-03: アンインストールパスはバナーフックを削除する。

参照 issue: #2795

129. issue-driven-orchestration ガイド

目的: GitHub / Linear / Jira issue から GSD ワークフロー全体を駆動するレシピを文書化し、トラッカー中心の概念を既存の GSD プリミティブにマッピングします。

ドキュメント: docs/issue-driven-orchestration.md

対象ワークフロー:

issue ごとに分離されたワークスペースを作成（/gsd-workspace --new）
マネージャーダッシュボードを実行して全体を把握（/gsd-manager）
自律的に実行（/gsd-autonomous）
検証とレビュー（/gsd-verify-work、/gsd-review）
シップして issue をクローズ（/gsd-ship）

新しいコマンドやデーモンプロセスはなし — 既存のプリミティブをトラッカー駆動ワークフローにマッピングする純粋なドキュメントアーティファクト。

参照 issue: #2840

130. グラファイファイコミットベースの古さ検出

目的: アーキテクチャグラフが現在のコミットから構築されたか古いコミットから構築されたかを表示し、既存の mtime ベースの古さシグナルを補完します。

コマンド: /gsd-graphify status

返される新フィールド（graphify v0.7+ グラフ）:

フィールド	型	説明
`built_at_commit`	string	グラフが構築されたコミット SHA
`current_commit`	string	現在の `git HEAD`
`commits_behind`	number	グラフが HEAD から何コミット遅れているか
`commit_stale`	boolean \| null	`true`=古い、`false`=最新、`null`=利用不可（v0.7 以前、非 git）

レンダリング出力（シグナルが利用可能な場合）:

Source commit: abc1234 (3 commits behind HEAD)

セキュリティ: built_at_commit は git に到達する前に 4〜40 の 16 進文字として検証される — 悪意のある graph.json はダッシュオプションを argv にインジェクトできない。

フォールバック: v0.7 以前のグラフと非 git チェックアウトは commit_stale: null を返す；呼び出し元は既存の mtime ベースの stale フラグにフォールバック。既存ユーザーの動作変更なし。

参照 issue: #3170

v1.42.1 機能

132. パッケージ正当性ゲート

目的: 幻覚的、疑わしい、またはスロップスクワッティングのパッケージ名がシェルインストールコマンドに到達する前に停止します。

動作:

フェーズリサーチは推奨パッケージの ## Package Legitimacy Audit テーブルを書き込む。
検索のみで確認されたパッケージは [ASSUMED] として扱われ、信頼されない。
[SLOP] パッケージは推奨から削除される。
[ASSUMED] または疑わしいパッケージを必要とするプランは人間の確認チェックポイントを追加する。
Executor のインストール失敗は、同様の名前のパッケージを自動的に試みる代わりに人間の確認のために停止する。

要件:

REQ-PKG-GATE-01: リサーチはパッケージレジストリ、年齢、ダウンロード/ソースシグナル、正当性判定、および処分を記録しなければならない。
REQ-PKG-GATE-02: プランナーは実行前に未検証または疑わしいパッケージのインストールをゲートしなければならない。
REQ-PKG-GATE-03: Executor はパッケージマネージャーのインストール失敗後にパッケージ名を自動置換してはならない。

参照: v1.42.1 リリースノート

133. スキルサーフェス予算

目的: コンテキスト予算が重要な場合に、インストールされたスキルとエージェントのサーフェスエリアをユーザーが削減できるようにします。

インストールプロファイル:

プロファイル	目的
`core`	最小限のメインループサーフェス
`standard`	コアに加えて一般的なフェーズ管理コマンド
`full`	完全なサーフェス；デフォルト

ランタイムコントロール: /gsd-surface はプロファイル状態をリストし、再インストールなしにスキルクラスターを有効化、無効化、またはリセットします。

要件:

REQ-SURFACE-01: インストーラーは --profile=<name> を解決し、アクティブなプロファイルを .gsd-profile に永続化しなければならない。
REQ-SURFACE-02: --minimal と --core-only は --profile=core のエイリアスとして残らなければならない。
REQ-SURFACE-03: ランタイムサーフェス状態はインストールプロファイルマーカーの外側に永続化されなければならない。

参照: ADR-0011

134. インストーラーマイグレーション

目的: インストールとアップデート中のランタイム設定クリーンアップを明示的で監査可能、かつロールバック対応にします。

機能:

初回ベースラインマイグレーションは管理されたファイルを記録する。
レガシーステールファイルのクリーンアップは削除または再書き込み前に所有権のエビデンスを使用する。
ユーザー所有のアーティファクトは保存される。
曖昧な GSD らしいファイルはサイレントに上書きされる代わりに明確なレポートでブロックする。
マイグレーションプランはドライラン報告とロールバック保護をサポートする。

要件:

REQ-INSTALL-MIGRATION-01: マイグレーション記録はメタデータ、インストールスコープ、所有権のエビデンスを含まなければならない。
REQ-INSTALL-MIGRATION-02: 所有権が曖昧な場合、破壊的なアクションはフェイルドクローズでなければならない。
REQ-INSTALL-MIGRATION-03: インストール失敗はロールバックデータが存在する場合、インストール前の状態を復元しなければならない。

参照: インストーラーマイグレーション

135. カスタムシップ PR ボディセクション

コマンド: /gsd-ship

設定キー: ship.pr_body_sections

目的: GSD ワークフローファイルを編集せずに、生成された PR ボディにプロジェクト固有の PRD スタイルセクションを追加します。

動作: 設定されたセクションは必須の Summary、Changes、Requirements Addressed、Verification、および Key Decisions セクションの後に追加されます。アーティファクトの見出しからコピー、テンプレートをレンダリング、またはスタティックテキストにフォールバックできます。

要件:

REQ-SHIP-SECTIONS-01: カスタムセクションは必須の PR セクションを置き換え、削除、または並べ替えてはならない。
REQ-SHIP-SECTIONS-02: 不明なテンプレートトークンは設定検証によって拒否されなければならない。
REQ-SHIP-SECTIONS-03: 無効化されたセクションは PR 出力に表示されることなく設定に残らなければならない。

参照: カスタム PR ボディセクション

136. レビューデフォルトレビュアー

コマンド: /gsd-review

設定キー: review.default_reviewers

目的: チームがフラグなしの /gsd-review 実行のデフォルトレビュアーサブセットを選択できるようにします。

優先順位:

明示的なレビュアーフラグ -> --all -> review.default_reviewers -> すべての検出されたレビュアー

要件:

REQ-REVIEW-DEFAULTS-01: review.default_reviewers が欠如している場合、以前のすべて検出動作を維持しなければならない。
REQ-REVIEW-DEFAULTS-02: 空の配列は拒否されなければならない；すべて検出動作を復元するにはキーを削除する。
REQ-REVIEW-DEFAULTS-03: 既知だが利用不可のレビュアーは実行をハードフェイルさせる代わりに診断とともにスキップされなければならない。

参照: 設定リファレンス

137. ファロー構造レビュープリパス

コマンド: /gsd-code-review

設定キー: code_quality.fallow.*

目的: エージェントレビューの前にオプションの構造分析パスを追加します。

動作: 有効時、GSD は fallow バイナリを解決し、境界付き監査を実行し、FALLOW.json を書き込み、REVIEW.md に構造的な所見を埋め込みます。

要件:

REQ-FALLOW-01: Fallow はオプトインであり、デフォルトで無効でなければならない。
REQ-FALLOW-02: 欠如または失敗した fallow 実行は明確な診断を生成しなければならない。
REQ-FALLOW-03: 埋め込み予算を超えた所見は、生の JSON アーティファクトを保存しながら警告とともにスキップされなければならない。

参照: 設定リファレンス

138. フェーズ終了時の人間検証モード

設定キー: workflow.human_verify_mode

目的: フライト中の人間チェックポイントの中断を減らしながら、人間の検証要件を保持します。

動作: デフォルトの "end-of-phase" モードは人間チェックをフェーズレビューのための <verify><human-check> ブロックに埋め込みます。"mid-flight" はブロッキングの checkpoint:human-verify タスクを復元します。

要件:

REQ-HUMAN-VERIFY-01: checkpoint:decision と checkpoint:human-action はモードに関わらずブロッキングのまま。
REQ-HUMAN-VERIFY-02: 人間が必要な検証はフェーズ終了時のレビューが解決するまで保留のまま。
REQ-HUMAN-VERIFY-03: キーのない設定は "end-of-phase" を使用しなければならない。

参照: チェックポイントリファレンス

139. クォータとレート制限の失敗分類

コマンド: /gsd-execute-phase

目的: プロバイダーのクォータとレート制限の失敗を、通常の executor の失敗ではなく待機して再開の条件として扱います。

動作: エージェント出力は 429、rate limit、usage limit、RESOURCE_EXHAUSTED、usage_limit_reached などのシグナルに対して分類されます。一致する失敗はリセット待ちの回復パスを提示します。

要件:

REQ-QUOTA-01: クォータ失敗は即時再試行を主要な回復として提供してはならない。
REQ-QUOTA-02: 分類は Claude、Copilot、Codex、および汎用プロバイダーセンチネルをカバーしなければならない。
REQ-QUOTA-03: 非クォータ失敗は通常の実行失敗パスを継続しなければならない。

参照: プロバイダーレート制限シグナル

140. ステータス行コンテキスト位置

設定キー: statusline.context_position

目的: 狭いターミナルでコンテキストメーターを見やすく保ちます。

オプション:

値	動作
`"end"`	デフォルト；行末近くにコンテキストメーターをレンダリング
`"front"`	モデル名の直後にコンテキストメーターをレンダリング

要件:

REQ-STATUSLINE-POS-01: 無効な値は設定検証によって拒否されなければならない。
REQ-STATUSLINE-POS-02: 設定が欠如している場合、既存の末尾位置レンダリングを維持しなければならない。

参照: 設定リファレンス

141. マイルストーンタグ作成トグル

コマンド: /gsd-complete-milestone

設定キー: git.create_tag

目的: 外部リリース自動化を持つプロジェクトがローカル git タグを作成せずにマイルストーンを完了できるようにします。

動作: git.create_tag: false はマイルストーンタグ作成をスキップします。ワークフローは引き続きマイルストーンアーティファクトと状態を更新します。

要件:

REQ-MILESTONE-TAG-01: 設定が欠如している場合、自動タグ作成を維持しなければならない。
REQ-MILESTONE-TAG-02: 既存のタグの衝突はタグを上書きする代わりに明確に失敗しなければならない。
REQ-MILESTONE-TAG-03: タグ作成の無効化はマイルストーンアーカイブをスキップしてはならない。

参照: 設定リファレンス

142. 構造化 JSON エラーモード

CLI: gsd-tools --json-errors

目的: 自動化呼び出し元に安定した機械可読エラーエンベロープを提供します。

動作: --json-errors 下で失敗するコマンドは、散文のみの stderr の代わりに、エラーの種類、メッセージ、コマンドコンテキスト、および終了マッピングを含む構造化された ok: false ペイロードを返します。

要件:

REQ-JSON-ERRORS-01: 不明なコマンド、検証エラー、タイムアウト、ネイティブ失敗、フォールバック失敗、および内部エラーは正規エラーの種類にマッピングされなければならない。
REQ-JSON-ERRORS-02: CLI 終了コードマッピングは自動化呼び出し元に対して安定して維持されなければならない。
REQ-JSON-ERRORS-03: 人間可読出力は --json-errors が存在しない場合にデフォルトのまま。

195 KiB Raw Blame History Unescape Escape

GSD 機能リファレンス

目次

コア機能

1. プロジェクト初期化

2. フェーズディスカッション

3. UI デザインコントラクト

4. フェーズプランニング

5. フェーズ実行

6. 作業検証

6.5. Ship

7. UI レビュー

8. マイルストーン管理

プランニング機能

9. フェーズ管理

10. Quick モード

11. 自律モード

12. フリーフォームルーティング

13. ノートキャプチャ

14. 自動進行（Next）

品質保証機能

15. Nyquist バリデーション

16. プランチェック

17. 実行後検証

18. ノードリペア

19. ヘルスバリデーション

20. クロスフェーズ回帰ゲート

21. 要件カバレッジゲート

コンテキストエンジニアリング機能

22. コンテキストウィンドウ監視

23. セッション管理

24. セッションレポート

25. マルチエージェントオーケストレーション

26. モデルプロファイル

ブラウンフィールド機能

27. コードベースマッピング

27b. 既存コードベースオンボーディング

27a. 実行後コードベースドリフト検出

ユーティリティ機能

28. デバッグシステム

29. Todo 管理

30. 統計ダッシュボード

31. アップデートシステム

32. 設定管理

33. テスト生成

インフラストラクチャ機能

34. Git 連携

35. CLI ツール

36. マルチランタイムサポート

37. フックシステム

38. 開発者プロファイリング

39. 実行ハードニング

40. 検証デット追跡

v1.27 の機能

41. Fast モード

42. クロス AI ピアレビュー

43. バックログパーキングロット

44. 永続コンテキストスレッド

45. PR ブランチフィルタリング

46. セキュリティハードニング

47. マルチリポワークスペースサポート

48. ディスカッション監査証跡

v1.28 の機能

49. フォレンジクス

50. マイルストーンサマリー

51. ワークストリームネームスペーシング

52. マネージャーダッシュボード

53. Assumptions ディスカッションモード

54. UI フェーズ自動検出

55. マルチランタイムインストーラー選択

v1.29 の機能

56. Windsurf ランタイムサポート

57. 国際化ドキュメント

v1.31 の機能

59. スキーマドリフト検出

60. セキュリティエンフォースメント

61. ドキュメント生成

62. ディスカスチェーンモード

63. 単一フェーズ自律モード

64. スコープ削減検出

195 KiB

Raw Blame History

70. 自律モード `--to N` フラグ

75. ディスカスフェーズ `--power` フラグ

76. デバッグ `--diagnose` フラグ

86. 自律モード `--interactive` フラグ