Get Shit Done 的/gsd:help分层帮助体系从一行提示到全量命令参考的渐进式披露设计【免费下载链接】get-shit-doneA light-weight and powerful meta-prompting, context engineering and spec-driven development system for Claude Code by TÂCHES.项目地址: https://gitcode.com/GitHub_Trending/getshi/get-shit-done/gsd:help是 GSDGet Shit Done面向开发者的内置帮助命令也是观察这套 spec-driven 开发系统整体面貌的最短路径。本文以其命令定义 commands/gsd/help.md 为骨架结合运行时真正加载的分层工作流 get-shit-done/workflows/help.md 与四个 mode 文件拆解它是如何通过**渐进式披露progressive disclosure**把一行提示、一页导览、全量参考、单主题查询收进同一条命令的。读完你将理解/gsd:help五个调用档位的路由规则、主题别名解析机制、精简作用域的提取算法以及驱动这套约定的工程测试契约进而能精准地用/gsd:help topic快速检索任意命令。一、设计背景为什么一条帮助命令要分层GSD 的命令面非常大从核心流水线/gsd:new-project → /gsd:plan-phase → /gsd:execute-phase到quick / fast / debug / capture / ship再到探索、质量门禁、命名空间路由等 60 条/gsd:*slash 命令。如果只有一份把所有内容平铺的参考文档无论是新手还是重度用户都无法高效使用。帮助文件旧版是单一 747 行的超大参考。feat-3039将其重构为小型分发器 按档位懒加载的 mode 文件结构见 tests/feat-3039-help-tiered.test.cjs 顶部注释核心思路有三条按调用意图分流老用户只需一屏速查新手需要向导式导览查具体命令的人需要精准切片全量参考只服务于我要看所有内容的时刻mode 文件懒加载分发器本身控制在约 40 行以内只负责根据$ARGUMENTS决定读哪一个 mode 文件mode 文件本身就是最终输出输出纪律严格无论哪个档位只输出所选档位的参考内容不掺杂项目分析、Git 状态或下一步建议避免污染模型上下文。二、命令入口一份声明式命令契约仓库内的命令定义 commands/gsd/help.md 是典型的 GSD slash 命令契约frontmatter 完整声明了命令名、用途、参数提示与运行权限--- name: gsd:help description: Show available GSD commands and usage guide argument-hint: [--brief | --full | topic | --brief topic] allowed-tools: - Read ---三个值得注意的细节argument-hint是面向使用者的能力宣示它把五种合法调用形态--brief、--full、裸topic、--brief topic、以及缺省的无参数形式一次性公布其中可组合形态--brief topic是特意写进提示的便于用户发现这条精简查询路径allowed-tools仅开放Read帮助命令只读不写不产生任何工程产物execution_context指向运行时安装位置命令安装后被分发到~/.claude/get-shit-done/workflows/help.md即本仓库 get-shit-done/workflows/help.md 的内容process节点则明确携带$ARGUMENTS跟随该工作流执行。也就是说这份命令文件是一个薄壳真正的路由逻辑全部沉淀在工作流文件中——这本身就示范了 GSD 的模块化组织哲学命令只负责契约与参数透传行为交由可独立测试的工作流承担。三、分发器五档路由与参数解析规则运行时加载的 get-shit-done/workflows/help.md 是整套帮助系统的大脑其中progressive_disclosure块声明了完整的路由表测试断言它必须恰好有 5 个路由行见 feat-3039-help-tiered.test.cjs 的dispatcher routing (structural)用例组$ARGUMENTS取值加载的 mode 文件产出--brief或-b不带主题workflows/help/modes/brief.md十行左右的顶层命令速查--full或-f、--all不带主题workflows/help/modes/full.md完整命令参考空 / 未设置workflows/help/modes/default.md面向新人的一页导览--brief topic或-b topicworkflows/help/modes/topic.md精简作用域命中章节的签名行 一行摘要其余情况——裸主题、--full topic、带前导--的主题workflows/help/modes/topic.md完整作用域命中章节的完整内容分发器还内建了一套参数解析约定先对$ARGUMENTS做 trim 与小写化识别长形式、短形式及其常见别名--brief/-b、--full/-f/--all裸 token 一律视为主题debug、--debug、capture、workflow、config全部路由到topic.md解析时剥离一个前导--冲突消解--brief与--full互斥若两者同时出现且不带主题优先--full组合透传--brief与主题同时出现时调用topic.md的精简作用域--full与主题组合则走完整作用域即主题的默认行为。向topic.md透传参数时必须保留--brief标志因为该文件要靠它决定作用域。加载 mode 后分发器把其reference块内容原样输出不附加任何上下文或建议——这是所有模式共享的铁律。四、五档位输出内容详解四个 mode 文件位于 get-shit-done/workflows/help/modes/每个文件都恰好包含一个reference块测试逐行锚定校验其正文即运行时逐字输出的内容。4.1--brief给回归用户的一行速查brief.md 全文只有约 10 行有效内容目标是一屏内唤起记忆/gsd:new-project Initialize a project (greenfield) /gsd:map-codebase Map an existing codebase (brownfield) /gsd:plan-phase N Create a phase plan /gsd:execute-phase N Execute a phase /gsd:progress Where am I, whats next /gsd:quick Small ad-hoc task with GSD guarantees /gsd:fast task Trivial inline task — no subagents /gsd:debug symptom Persistent debug session (survives /clear) /gsd:capture Save an idea / todo / note /gsd:ship N Open a PR from a completed phase并在末尾以More:引导通往其他档位。它刻意不展开任何 flag——深度信息让用户用--full或topic自己取。4.2 默认无参数面向新人的一页导览default.md 是无参数时的默认输出开场即点题Plan-driven development for solo agentic work with Claude Code. GSD turns a vague idea into a hierarchical plan, then executes it phase by phase with state tracking and atomic commits.它用Start here (3 commands)给出最小上手路径/gsd:new-project # Greenfield: questioning → research → requirements → roadmap /gsd:plan-phase 1 # Create a detailed plan for phase 1 /gsd:execute-phase 1 # Execute all plans in the phase随后用一张常用命令表覆盖 progress / quick / fast / discuss-phase / debug / capture / verify-work / ship 等高频入口并给出升级入口/gsd:help --brief # 10-line refresher of top commands /gsd:help --full # complete reference /gsd:help topic # one section only — see topics below /gsd:help --brief topic # compact scoped lookup — signature one-line summary值得注意导览中声明了对外承诺的主题列表workflow · planning · execute · quick · debug · capture · ship · config · milestones · spike · sketch · review · audit · progress。测试契约中有一条surface contractdefault.md 宣传的每个别名都必须在 topic.md 的解析表中被识别见 feat-3039-help-tiered.test.cjs 的topic.md covers the core topics promised in default.md防止导览说支持但实际查不到的失真。更新命令则以npx get-shit-done-cclatest收尾。4.3topic主题解析表与切片提取算法topic.md 是整套机制中最具工程味的一环它不复制参考内容而是按别名表在 full.md 上做范围切片。别名匹配大小写不敏感先剥离一个前导--。下表摘自其解析表并选取代表性行主题别名full.md 中的目标章节workflow/core/core-workflow## Core Workflow含 Quick Mode 止init/new-project### Project Initializationplan/planning/plan-phase### Phase Planningexecute/exec/execute-phase### Executionprogress/route### Progress Tracking### Smart Routerdebug/debugging### Debuggingspike、sketch### Spiking Sketching下的对应子块verify/verify-work/uat### User Acceptance Testing/gsd:audit-uat块ship/pr### Ship Work/gsd:pr-branch块config/settings/configuration### Configurationmilestone/milestones### Milestone Management### Milestone Auditingfiles/structure/layout## Files Structuremodes/interactive/yolo## Workflow Modeshelp## Getting Help输出算法**Output rules:**按以下顺序执行解析参数检测--brief或-b决定是否进入精简作用域随后对剩余 token 剥离一个前导--作为主题别名查表将别名对照上表未命中输出一行错误后接按行去重后的规范主题名列表并提示/gsd:help --full然后停止命中先输出一行路由前置声明见 4.5再执行提取按单元类型切片提取规则与作用域联动单章节单元单元格内为单个## Heading/### Heading完整作用域从该标题输出到下一个同级/更高级标题之前精简作用域只输出标题 该章节内首条**\/gsd:...** 加粗签名行 紧随其后的唯一非空行即一行摘要若无签名行则输出标题 首段多章节单元单元格内以 plus 连接多个章节按文档顺序逐节执行上述规则无缝衔接输出子块单元单元格指向某章节下的/gsd:X加粗块完整作用域自该**\/gsd:X ...** 加粗行起止于下一条加粗命令行或下一个标题精简作用域输出加粗行 其后单行摘要收尾输出统一关闭行More: /gsd:help --full · /gsd:help topic · /gsd:help --brief topic禁止附加不加项目评论、不追问。这种表驱动切片设计的价值在于参考内容只维护一份full.md主题查询靠结构规则现切杜绝了多份拷贝之间的漂移。4.4--full全量命令参考一份权威大文件full.md 保存着 800 余行的完整参考——测试保证它不得低于 600 行防止重构时悄悄丢内容同时保持在 LARGE 工作流预算 1500 行以内见 feat-3039-help-tiered.test.cjs 的 size budget 用例。其结构即 GSD 全部命令面的索引Quick Start / Core Workflownew-project → plan-phase → execute-phase 的循环展开 Project Initialization、Phase Planning含--research-phase只研究模式、PRD Express Path 的--prd直通路径、Execution--wave N并行、Smart Router、Quick Mode 与/gsd:fast内联任务等核心章节Roadmap / Milestone 管理/gsd:phase的增--insert生成 7.1 这类十进制插队阶段、删--remove、改--edit以及new-milestone、complete-milestone的里程碑生命周期Progress / Session / Debuggingprogress 的--next自动推进与--forensic六项完整性审计、resume-work/pause-work的会话续接、/gsd:debug抗/clear的持久化排查会话Spiking Sketching / Capturespike、sketch 及其--wrap-up把发现沉淀为.claude/skills/下的项目技能capture 的--note/--list/--seed/--backlog多形态捕捉UAT / Ship / Auditingverify-work会话式验收、ship自动生成 PR 正文、review跨 AI 同行评审、audit-uat与audit-milestone等质量与审计命令Configurationsettings/configquality / balanced / budget / inherit四档模型画像balanced为默认、surface技能面开关Additional Commands按 Discovery Specification、Planning Execution、Quality/Review、Diagnostics、Knowledge、Workflow、Repository Integration、六个 Namespace Routersgsd-context / gsd-ideate / gsd-manage / gsd-project / gsd-quality / gsd-workflow分组罗列的完整命令面Files Structure / Workflow Modes / Planning Configuration / Common Workflows.planning/目录布局树、interactive 与 yolo 两种模式、planning.commit_docs与planning.search_gitignored配置键及 JSON 示例、多场景端到端工作流以及 Getting Help 章节。需要说明这份文件的章节与标题被 topic.md 视为唯一数据源任何新章节若不加入别名表就必须出现在测试的有意孤儿INTENTIONAL_ORPHANS白名单中否则契约测试直接失败——这正是保证主题查询永不指向不存在标题的机制。4.5 路由可见性一行前置声明无论哪个作用域主题查询的输出都以一行**Topic:** \ → (scope: full | compact)开头让用户直观看到自己输入的别名命中了哪个章节、以什么作用域输出。这一解析结果可见的设计源自 review 发现由测试 [feat-3039-help-tiered.test.cjs](https://link.gitcode.com/i/d59c34ce1f684a97031d4d8cdab3784d) 明确断言topic.md documents an explicit resolved-routing preamble。五、工程保障帮助系统自身的契约测试分层帮助系统不只是一堆 Markdown它的行为边界由 feat-3039-help-tiered.test.cjs 以契约测试的方式锁定。该文件顶部注释点明设计前提这些 mode 文件本身就是帮助输出对它们结构的断言就是在测试线上契约。 测试覆盖六大面文件结构四个 mode 文件必须存在且各含且仅含一个reference块分发器不超过 40 行尺寸预算brief 不超过 30 行、default 不超过 70 行一屏约束full 不小于 600 行且不超过 1500 行分发路由progressive_disclosure表必须恰好 5 行且逐条匹配 brief/full/default/topic 的映射冲突消解与组合--brief --full不带主题时优先--full--brief topic路由到 topic.md 精简作用域且须保留--brief透传别名覆盖topic.md 中引用的每个章节标题都真实存在于 full.md每个/gsd:*子块 token 都出现在 full.md反过来full.md 的每个标题要么被别名覆盖、要么显式列入 INTENTIONAL_ORPHANSdefault.md 宣传的每个主题别名都能被 topic.md 识别命令壳契约commands/gsd/help.md 必须引用$ARGUMENTS、声明argument-hint、提示可组合的--brief topic并指向 help 工作流。这套测试把帮助内容被谁引用、向哪里路由、在哪个范围内切片全部固化为可回归校验的约束未来任何对命令面的增删都会先被它拦住。六、使用建议在正确的档位取信息结合上述机制实践中可按如下方式定位信息刚上手或久未使用先跑/gsd:help无参数获取一页导览跟着Start here三步走记忆模糊的老用户用/gsd:help --brief一屏唤起十条高频命令想精读某条命令的全部 flag 与语义用/gsd:help topic例如/gsd:help plan-phase、/gsd:help debug、/gsd:help workflow只想知道这条命令签名是什么、干什么用的用可组合的/gsd:help --brief topic拿签名 一行摘要上下文消耗最小需要系统摸底或作为离线速查手册跑/gsd:help --full。无论哪个档位你得到的都是纯参考文本——不夹带项目分析、不提下一步建议这让它既适合人读也适合被模型在上下文紧张的会话中安全调用。理解这五档体系就等于拿到了整个 GSD 命令面的结构化地图。【免费下载链接】get-shit-doneA light-weight and powerful meta-prompting, context engineering and spec-driven development system for Claude Code by TÂCHES.项目地址: https://gitcode.com/GitHub_Trending/getshi/get-shit-done创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Get Shit Done 的 `/gsd:help` 分层帮助体系：从一行提示到全量命令参考的渐进式披露设计
Get Shit Done 的/gsd:help分层帮助体系从一行提示到全量命令参考的渐进式披露设计【免费下载链接】get-shit-doneA light-weight and powerful meta-prompting, context engineering and spec-driven development system for Claude Code by TÂCHES.项目地址: https://gitcode.com/GitHub_Trending/getshi/get-shit-done/gsd:help是 GSDGet Shit Done面向开发者的内置帮助命令也是观察这套 spec-driven 开发系统整体面貌的最短路径。本文以其命令定义 commands/gsd/help.md 为骨架结合运行时真正加载的分层工作流 get-shit-done/workflows/help.md 与四个 mode 文件拆解它是如何通过**渐进式披露progressive disclosure**把一行提示、一页导览、全量参考、单主题查询收进同一条命令的。读完你将理解/gsd:help五个调用档位的路由规则、主题别名解析机制、精简作用域的提取算法以及驱动这套约定的工程测试契约进而能精准地用/gsd:help topic快速检索任意命令。一、设计背景为什么一条帮助命令要分层GSD 的命令面非常大从核心流水线/gsd:new-project → /gsd:plan-phase → /gsd:execute-phase到quick / fast / debug / capture / ship再到探索、质量门禁、命名空间路由等 60 条/gsd:*slash 命令。如果只有一份把所有内容平铺的参考文档无论是新手还是重度用户都无法高效使用。帮助文件旧版是单一 747 行的超大参考。feat-3039将其重构为小型分发器 按档位懒加载的 mode 文件结构见 tests/feat-3039-help-tiered.test.cjs 顶部注释核心思路有三条按调用意图分流老用户只需一屏速查新手需要向导式导览查具体命令的人需要精准切片全量参考只服务于我要看所有内容的时刻mode 文件懒加载分发器本身控制在约 40 行以内只负责根据$ARGUMENTS决定读哪一个 mode 文件mode 文件本身就是最终输出输出纪律严格无论哪个档位只输出所选档位的参考内容不掺杂项目分析、Git 状态或下一步建议避免污染模型上下文。二、命令入口一份声明式命令契约仓库内的命令定义 commands/gsd/help.md 是典型的 GSD slash 命令契约frontmatter 完整声明了命令名、用途、参数提示与运行权限--- name: gsd:help description: Show available GSD commands and usage guide argument-hint: [--brief | --full | topic | --brief topic] allowed-tools: - Read ---三个值得注意的细节argument-hint是面向使用者的能力宣示它把五种合法调用形态--brief、--full、裸topic、--brief topic、以及缺省的无参数形式一次性公布其中可组合形态--brief topic是特意写进提示的便于用户发现这条精简查询路径allowed-tools仅开放Read帮助命令只读不写不产生任何工程产物execution_context指向运行时安装位置命令安装后被分发到~/.claude/get-shit-done/workflows/help.md即本仓库 get-shit-done/workflows/help.md 的内容process节点则明确携带$ARGUMENTS跟随该工作流执行。也就是说这份命令文件是一个薄壳真正的路由逻辑全部沉淀在工作流文件中——这本身就示范了 GSD 的模块化组织哲学命令只负责契约与参数透传行为交由可独立测试的工作流承担。三、分发器五档路由与参数解析规则运行时加载的 get-shit-done/workflows/help.md 是整套帮助系统的大脑其中progressive_disclosure块声明了完整的路由表测试断言它必须恰好有 5 个路由行见 feat-3039-help-tiered.test.cjs 的dispatcher routing (structural)用例组$ARGUMENTS取值加载的 mode 文件产出--brief或-b不带主题workflows/help/modes/brief.md十行左右的顶层命令速查--full或-f、--all不带主题workflows/help/modes/full.md完整命令参考空 / 未设置workflows/help/modes/default.md面向新人的一页导览--brief topic或-b topicworkflows/help/modes/topic.md精简作用域命中章节的签名行 一行摘要其余情况——裸主题、--full topic、带前导--的主题workflows/help/modes/topic.md完整作用域命中章节的完整内容分发器还内建了一套参数解析约定先对$ARGUMENTS做 trim 与小写化识别长形式、短形式及其常见别名--brief/-b、--full/-f/--all裸 token 一律视为主题debug、--debug、capture、workflow、config全部路由到topic.md解析时剥离一个前导--冲突消解--brief与--full互斥若两者同时出现且不带主题优先--full组合透传--brief与主题同时出现时调用topic.md的精简作用域--full与主题组合则走完整作用域即主题的默认行为。向topic.md透传参数时必须保留--brief标志因为该文件要靠它决定作用域。加载 mode 后分发器把其reference块内容原样输出不附加任何上下文或建议——这是所有模式共享的铁律。四、五档位输出内容详解四个 mode 文件位于 get-shit-done/workflows/help/modes/每个文件都恰好包含一个reference块测试逐行锚定校验其正文即运行时逐字输出的内容。4.1--brief给回归用户的一行速查brief.md 全文只有约 10 行有效内容目标是一屏内唤起记忆/gsd:new-project Initialize a project (greenfield) /gsd:map-codebase Map an existing codebase (brownfield) /gsd:plan-phase N Create a phase plan /gsd:execute-phase N Execute a phase /gsd:progress Where am I, whats next /gsd:quick Small ad-hoc task with GSD guarantees /gsd:fast task Trivial inline task — no subagents /gsd:debug symptom Persistent debug session (survives /clear) /gsd:capture Save an idea / todo / note /gsd:ship N Open a PR from a completed phase并在末尾以More:引导通往其他档位。它刻意不展开任何 flag——深度信息让用户用--full或topic自己取。4.2 默认无参数面向新人的一页导览default.md 是无参数时的默认输出开场即点题Plan-driven development for solo agentic work with Claude Code. GSD turns a vague idea into a hierarchical plan, then executes it phase by phase with state tracking and atomic commits.它用Start here (3 commands)给出最小上手路径/gsd:new-project # Greenfield: questioning → research → requirements → roadmap /gsd:plan-phase 1 # Create a detailed plan for phase 1 /gsd:execute-phase 1 # Execute all plans in the phase随后用一张常用命令表覆盖 progress / quick / fast / discuss-phase / debug / capture / verify-work / ship 等高频入口并给出升级入口/gsd:help --brief # 10-line refresher of top commands /gsd:help --full # complete reference /gsd:help topic # one section only — see topics below /gsd:help --brief topic # compact scoped lookup — signature one-line summary值得注意导览中声明了对外承诺的主题列表workflow · planning · execute · quick · debug · capture · ship · config · milestones · spike · sketch · review · audit · progress。测试契约中有一条surface contractdefault.md 宣传的每个别名都必须在 topic.md 的解析表中被识别见 feat-3039-help-tiered.test.cjs 的topic.md covers the core topics promised in default.md防止导览说支持但实际查不到的失真。更新命令则以npx get-shit-done-cclatest收尾。4.3topic主题解析表与切片提取算法topic.md 是整套机制中最具工程味的一环它不复制参考内容而是按别名表在 full.md 上做范围切片。别名匹配大小写不敏感先剥离一个前导--。下表摘自其解析表并选取代表性行主题别名full.md 中的目标章节workflow/core/core-workflow## Core Workflow含 Quick Mode 止init/new-project### Project Initializationplan/planning/plan-phase### Phase Planningexecute/exec/execute-phase### Executionprogress/route### Progress Tracking### Smart Routerdebug/debugging### Debuggingspike、sketch### Spiking Sketching下的对应子块verify/verify-work/uat### User Acceptance Testing/gsd:audit-uat块ship/pr### Ship Work/gsd:pr-branch块config/settings/configuration### Configurationmilestone/milestones### Milestone Management### Milestone Auditingfiles/structure/layout## Files Structuremodes/interactive/yolo## Workflow Modeshelp## Getting Help输出算法**Output rules:**按以下顺序执行解析参数检测--brief或-b决定是否进入精简作用域随后对剩余 token 剥离一个前导--作为主题别名查表将别名对照上表未命中输出一行错误后接按行去重后的规范主题名列表并提示/gsd:help --full然后停止命中先输出一行路由前置声明见 4.5再执行提取按单元类型切片提取规则与作用域联动单章节单元单元格内为单个## Heading/### Heading完整作用域从该标题输出到下一个同级/更高级标题之前精简作用域只输出标题 该章节内首条**\/gsd:...** 加粗签名行 紧随其后的唯一非空行即一行摘要若无签名行则输出标题 首段多章节单元单元格内以 plus 连接多个章节按文档顺序逐节执行上述规则无缝衔接输出子块单元单元格指向某章节下的/gsd:X加粗块完整作用域自该**\/gsd:X ...** 加粗行起止于下一条加粗命令行或下一个标题精简作用域输出加粗行 其后单行摘要收尾输出统一关闭行More: /gsd:help --full · /gsd:help topic · /gsd:help --brief topic禁止附加不加项目评论、不追问。这种表驱动切片设计的价值在于参考内容只维护一份full.md主题查询靠结构规则现切杜绝了多份拷贝之间的漂移。4.4--full全量命令参考一份权威大文件full.md 保存着 800 余行的完整参考——测试保证它不得低于 600 行防止重构时悄悄丢内容同时保持在 LARGE 工作流预算 1500 行以内见 feat-3039-help-tiered.test.cjs 的 size budget 用例。其结构即 GSD 全部命令面的索引Quick Start / Core Workflownew-project → plan-phase → execute-phase 的循环展开 Project Initialization、Phase Planning含--research-phase只研究模式、PRD Express Path 的--prd直通路径、Execution--wave N并行、Smart Router、Quick Mode 与/gsd:fast内联任务等核心章节Roadmap / Milestone 管理/gsd:phase的增--insert生成 7.1 这类十进制插队阶段、删--remove、改--edit以及new-milestone、complete-milestone的里程碑生命周期Progress / Session / Debuggingprogress 的--next自动推进与--forensic六项完整性审计、resume-work/pause-work的会话续接、/gsd:debug抗/clear的持久化排查会话Spiking Sketching / Capturespike、sketch 及其--wrap-up把发现沉淀为.claude/skills/下的项目技能capture 的--note/--list/--seed/--backlog多形态捕捉UAT / Ship / Auditingverify-work会话式验收、ship自动生成 PR 正文、review跨 AI 同行评审、audit-uat与audit-milestone等质量与审计命令Configurationsettings/configquality / balanced / budget / inherit四档模型画像balanced为默认、surface技能面开关Additional Commands按 Discovery Specification、Planning Execution、Quality/Review、Diagnostics、Knowledge、Workflow、Repository Integration、六个 Namespace Routersgsd-context / gsd-ideate / gsd-manage / gsd-project / gsd-quality / gsd-workflow分组罗列的完整命令面Files Structure / Workflow Modes / Planning Configuration / Common Workflows.planning/目录布局树、interactive 与 yolo 两种模式、planning.commit_docs与planning.search_gitignored配置键及 JSON 示例、多场景端到端工作流以及 Getting Help 章节。需要说明这份文件的章节与标题被 topic.md 视为唯一数据源任何新章节若不加入别名表就必须出现在测试的有意孤儿INTENTIONAL_ORPHANS白名单中否则契约测试直接失败——这正是保证主题查询永不指向不存在标题的机制。4.5 路由可见性一行前置声明无论哪个作用域主题查询的输出都以一行**Topic:** \ → (scope: full | compact)开头让用户直观看到自己输入的别名命中了哪个章节、以什么作用域输出。这一解析结果可见的设计源自 review 发现由测试 [feat-3039-help-tiered.test.cjs](https://link.gitcode.com/i/d59c34ce1f684a97031d4d8cdab3784d) 明确断言topic.md documents an explicit resolved-routing preamble。五、工程保障帮助系统自身的契约测试分层帮助系统不只是一堆 Markdown它的行为边界由 feat-3039-help-tiered.test.cjs 以契约测试的方式锁定。该文件顶部注释点明设计前提这些 mode 文件本身就是帮助输出对它们结构的断言就是在测试线上契约。 测试覆盖六大面文件结构四个 mode 文件必须存在且各含且仅含一个reference块分发器不超过 40 行尺寸预算brief 不超过 30 行、default 不超过 70 行一屏约束full 不小于 600 行且不超过 1500 行分发路由progressive_disclosure表必须恰好 5 行且逐条匹配 brief/full/default/topic 的映射冲突消解与组合--brief --full不带主题时优先--full--brief topic路由到 topic.md 精简作用域且须保留--brief透传别名覆盖topic.md 中引用的每个章节标题都真实存在于 full.md每个/gsd:*子块 token 都出现在 full.md反过来full.md 的每个标题要么被别名覆盖、要么显式列入 INTENTIONAL_ORPHANSdefault.md 宣传的每个主题别名都能被 topic.md 识别命令壳契约commands/gsd/help.md 必须引用$ARGUMENTS、声明argument-hint、提示可组合的--brief topic并指向 help 工作流。这套测试把帮助内容被谁引用、向哪里路由、在哪个范围内切片全部固化为可回归校验的约束未来任何对命令面的增删都会先被它拦住。六、使用建议在正确的档位取信息结合上述机制实践中可按如下方式定位信息刚上手或久未使用先跑/gsd:help无参数获取一页导览跟着Start here三步走记忆模糊的老用户用/gsd:help --brief一屏唤起十条高频命令想精读某条命令的全部 flag 与语义用/gsd:help topic例如/gsd:help plan-phase、/gsd:help debug、/gsd:help workflow只想知道这条命令签名是什么、干什么用的用可组合的/gsd:help --brief topic拿签名 一行摘要上下文消耗最小需要系统摸底或作为离线速查手册跑/gsd:help --full。无论哪个档位你得到的都是纯参考文本——不夹带项目分析、不提下一步建议这让它既适合人读也适合被模型在上下文紧张的会话中安全调用。理解这五档体系就等于拿到了整个 GSD 命令面的结构化地图。【免费下载链接】get-shit-doneA light-weight and powerful meta-prompting, context engineering and spec-driven development system for Claude Code by TÂCHES.项目地址: https://gitcode.com/GitHub_Trending/getshi/get-shit-done创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考