* fix(#2903): use the command form that actually works in reader-facing docs Docs told readers to type the colon form, which no runtime registers -- 18 of 19 runtimes use slash-hyphen and the 19th uses shell-var -- so anyone copying an example got an unrecognized command. Swept 178 occurrences across 53 files, locale mirrors included so they do not re-diverge from English. The colon form is a source-authoring token, not a user-facing one: install-time converters key on it to produce the hyphen form runtimes actually register. So the sweep is scoped, and three things are deliberately left alone: - ADRs, which are a historical record; editing their prose falsifies what was written at the time. - The legacy release-notes archive, pending a maintainer decision on whether it follows the same historical carve-out. Excluding it keeps a later reversal additive rather than a revert. - Source artifacts under commands, workflows and agents, where the colon form is load-bearing. Rewriting those would break the installed-skill guarantee across every runtime -- the single largest hazard here. The plugin namespace form is a real, separate token and survives untouched. Adds a lint enforcing exactly that boundary, since the correct form genuinely differs by directory and nothing previously caught the drift. Also fixes a hardcoded colon form in the capability-matrix generator. The sweep alone would have left the generated matrix disagreeing with the template that produces it, so the fix is at the source and the output regenerated. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(#2903): stop the sweep misquoting source frontmatter Adversarial review caught three lines where the sweep rewrote a citation of the literal YAML name: key from a source command file. That key genuinely is the colon form -- this change's own carve-out logic says source-authoring tokens keep it -- so the docs ended up misquoting the real files. One of the three is an acceptance-checklist assertion, which the sweep turned into a false statement. Restored the three citations to match their sources verbatim, surgically: where a line carried both a name: citation and a real reader-facing slash command, only the citation reverted and the command stayed corrected. The guard needed the same distinction, or it would have flagged the restoration and reddened the build: a gsd:<cmd> token preceded by name: is a citation of a source token and is now permitted. The exemption is deliberately narrow -- a bare gsd:<cmd> anywhere else still fails -- with a test pinning that narrowness. Also makes the detection case-insensitive. Review found /GSD:next slipped through silently; no such casing exists in the tree today, so this closes a latent gap rather than fixing a live one. Swept the whole tree for further corrupted citations: none beyond the three. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(#2903): retire the stale-next invariant and sweep next like every other command Maintainer decision on a genuine conflict between two contracts. Invariant #3054 banned the literal /gsd-next from user-facing docs because it named a retired workflow-advance command. But commands/gsd/next.md is a live command -- the state-aware smart-entry launcher -- and this issue requires docs to use the hyphen form every runtime actually registers. Both could not hold for this one command, so docs had been sidestepping the ban by keeping the colon form, which is exactly the defect this issue exists to remove. FEATURES.md already recorded the reassignment: the hyphen form "is not the retired workflow-advance command; it is reserved for the state-aware smart-entry launcher. Workflow advancement remains under /gsd-progress --next." With that reassignment the invariant's premise is obsolete and the guard now contradicts the documented command form, so it is retired with a comment recording why rather than deleted silently. next is now swept like every other command, and the earlier exemption added to the new guard is removed so nothing is special-cased. Four citations of the literal name: frontmatter key stay in colon form, because the source file really does carry name: gsd:next and a doc quoting it must reproduce it verbatim. Two of those lines were reworded to say which side is the frontmatter key and which is the slash command, since they previously conflated the two. Verified the retired scan would now genuinely fail against this tree -- the conflict was real and resolved, not dodged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * chore(#2903): backfill changeset pr number Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
GSD Core 文档
文档按四个象限组织:教程通过实践帮助你学习,操作指南解决具体任务,参考文档提供权威信息,概念说明探讨设计理念与决策。
语言版本:English · Português (pt-BR) · 日本語 · 简体中文
Tutorials
How-to guides
- 在你的运行时上安装 — 适用于全部 16 个受支持运行时的安装步骤
- 讨论一个阶段 — 在规划开始前记录实现决策
- 规划一个阶段 — 执行调研、分解工作并验证计划质量
- 执行一个阶段 — 使用全新上下文的子代理以并行波次运行计划
- 验证并交付 — 审查已完成的工作、诊断失败并创建 PR
- 自主运行阶段 — 使用自主模式进行无人值守的阶段执行
- 处理快速临时任务 — 使用
/gsd-quick和/gsd-fast处理阶段循环之外的临时工作 - 配置模型配置文件 — 在高质量、均衡和经济模型层级之间切换
- 设置跨 AI 审查 — 配置第二个 AI 对主代理生成的代码进行审查
- 使用工作流并行工作 — 使用工作流同时运行独立的工作线
- 使用工作空间隔离工作 — 使用工作空间对实验性或高风险变更进行沙箱隔离
- 调试失败的执行 — 诊断并从中断或不完整的阶段执行中恢复
- 探索与草图 — 在提交计划之前,使用
/gsd-spike和/gsd-sketch进行探索性工作 - 设计 UI 阶段 — 使用 UI 阶段循环处理前端和视觉工作
- 从追踪器 Issue 驱动 GSD — 从 GitHub、Linear 或 Jira issue 启动一个阶段
- 从 GSD 2 迁移 — 将现有的 GSD 2 项目升级到 GSD Core
- 更新 GSD — 重新运行安装程序以获取最新版本
- 恢复与故障排查 — 修复常见问题、重建上下文并卸载
Reference
- 命令 — 每个命令的标志和示例
- 配置 — 完整配置模式、模型配置文件、Git 分支策略
- CLI 工具 —
gsd-tools.cjs用于工作流和代理的编程式 API - 功能特性 — 完整功能索引
- 清单 — 已安装的技能与界面映射
- STATE.md 模式 —
.planning/STATE.md的逐字段参考 - CONTEXT.md 模式 —
.planning/phases/<N>/CONTEXT.md的逐字段参考 - PLAN.md 模式 —
.planning/phases/<N>/PLAN.md的逐字段参考 - 规划产物 — 所有
.planning/文件及其作用
Explanation
- 上下文工程 — 上下文腐化如何形成,以及 GSD Core 如何防止它
- 阶段循环 — 讨论 → 规划 → 执行 → 验证 → 交付循环的设计原理
- 多代理编排 — 子代理的生成、范围界定和协调方式
- 安全模型 — 信任边界、权限和安全自动化
- 架构 — 系统架构、代理模型和数据流
- 讨论模式 —
/gsd-discuss-phase的假设模式与访谈模式 - 上下文监控 — 上下文窗口监控钩子架构
- Issue 驱动编排 — 使用现有原语从追踪器 issue 驱动 GSD 的方案
Related
- 根目录 README — 首页、快速开始和文档概览
- 变更日志 — 发布历史