3bb2f8f1c5
* chore: wire docs/agents config into AGENTS.md Agent skills section
Add the `## Agent skills` discovery block pointing the engineering
skills at the existing docs/agents/{issue-tracker,triage-labels,domain}.md
files (issue tracker, triage label mapping, single-context domain docs).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* docs: rebrand to GSD Core and restructure docs with Diataxis
Reorganise the root README and docs/ around the Diataxis framework
(tutorials, how-to guides, reference, explanation), add new how-to
guides and schema references (STATE.md / CONTEXT.md / PLAN.md /
planning artifacts), and cross-link the whole set. Update the lone
legacy gsd-build reference to open-gsd; keep internal get-shit-done/
filesystem paths unchanged (directory rename tracked separately in
open-gsd/gsd-core#604). Regenerate the ja-JP, ko-KR, pt-BR and zh-CN
localised trees to mirror the new structure.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* docs: backfill changeset PR number (#605)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
4.3 KiB
如何验证并发布阶段
目标： 对已执行的工作进行用户验收测试，诊断并修复任何失败，然后开启一个带有自动生成正文的拉取请求。
前提条件： 该阶段已执行完毕并包含 SUMMARY.md 文件。如果执行尚未完成，请参阅执行阶段。
运行用户验收测试
/gsd-verify-work 1
GSD Core 读取该阶段的 SUMMARY.md 文件，提取用户可观测的交付物，并逐一引导您完成验证。对于每个检查点，它会展示应该发生的情况，并询问实际情况是否与之匹配。
yes/y/ 直接回车 → 通过，进入下一项测试- 其他任何输入 → 记录为问题，严重程度根据您的描述推断
您无需手动分类严重程度——GSD Core 会从您的描述中推断（"崩溃" → 阻塞级，"无法使用" → 严重级，"看起来不对" → 外观级）。
进度将写入 .planning/phases/01-<name>/01-UAT.md，在 /clear 之后依然保留。若会话中断，重新运行 /gsd-verify-work 1，GSD Core 会提示是否从上次检查点恢复。
发现失败时：自动诊断与修复规划
如果有测试报告问题，GSD Core 会自动执行以下步骤：
- 诊断根本原因 — 为每个问题并行启动调试代理，并将根本原因更新至
UAT.md。 - 规划差距弥补 — 在差距弥补模式下启动
gsd-planner，读取UAT.md（含诊断结果）并生成新的PLAN.md文件。 - 验证修复计划 — 启动
gsd-plan-checker确保计划可执行。若发现问题，规划器与检查器最多迭代三次。 - 呈现下一步 — 当计划通过检查器时：
Plans verified and ready for execution.
`/clear` then `/gsd-execute-phase 1 --gaps-only`
运行提示的命令以应用修复，然后重新运行 /gsd-verify-work 1 确认一切通过。
所有测试通过时：发布阶段
一旦所有 UAT 测试通过（或首次运行且未发现问题），该阶段将自动在 ROADMAP.md 和 STATE.md 中标记为已完成。
/gsd-ship 1
GSD Core 执行预检（验证状态、干净的工作树、分支、远程仓库、gh CLI 身份验证），推送分支并创建 PR：
/gsd-ship 1 # 准备审查的 PR
/gsd-ship 1 --draft # 草稿 PR — 当后续还有更多阶段时很有用
PR 正文由规划产物自动组装：
- 来自
ROADMAP.md的阶段目标 - 来自
SUMMARY.md文件及其关键文件的各计划摘要 - 已解决的需求（REQ-IDs）
- 来自
VERIFICATION.md的验证状态 - 来自
STATE.md的关键决策
无需手动编写正文。
可选：发布前或发布后的代码审查
/gsd-ship 不会自动运行代码审查，但您可以在任意节点插入审查：
验证前（在 UAT 之前发现问题）：
/gsd-code-review 1 # 标准审查
/gsd-code-review 1 --fix # 审查后自动修复 Critical 和 Warning 发现
PR 开启后（在合并前把关质量）：
/gsd-code-review 1 --depth=deep # 包含导入图的跨文件分析
请参阅配置跨 AI 审查，了解如何在周期早期为计划审查配置 Gemini、Codex 或其他审查工具。
可选：创建干净的 PR 分支
如果您的分支包含不希望审查者看到的 .planning/ 提交：
/gsd-pr-branch # 相对于 main 进行过滤
/gsd-pr-branch develop # 相对于 develop 进行过滤
/gsd-pr-branch 会创建一个仅包含代码变更的新分支——规划产物提交将被排除。若您的团队审查规范不包含规划噪音，请在 /gsd-ship 之前运行此命令。
关闭里程碑
如果这是里程碑中的最后一个阶段，请运行里程碑审计并将其归档：
/gsd-audit-milestone # 验证所有需求已发布
/gsd-complete-milestone # 归档，创建 git 标签
/gsd-complete-milestone 是 PR 合并后的自然下一步。请参阅阶段循环，了解验证与发布如何融入完整的项目生命周期。