get-shit-done/gsd-quality命名空间元技能解析质量门禁的意图路由与八大质检子技能实战指南【免费下载链接】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-doneget-shit-doneGSD是一个基于 Claude Code 的元提示meta-prompting与规范驱动开发系统其技能面skill surface非常庞大。为了让模型在低 token 开销下快速定位正确的质检能力GSD 在 v1.40 引入了名为/gsd-quality的命名空间路由元技能源文件为 commands/gsd/ns-review.md它只做一件事根据用户的一句话意图路由到对应的代码审查、调试、安全、评估、UI、验收、取证等子技能。读完本文你将理解 GSD 命名空间路由文档的前置元信息frontmatter契约、九条路由映射的完整语义、各子技能的能力边界与产物以及这套设计在仓库架构、技能集群与文档体系中的具体落点。为什么需要“路由型”技能命名空间元技能的设计动机GSD 的每一条/gsd命令本质上都是可被模型直接调用的技能skill技能数量随功能演进不断膨胀。仓库的 docs/ARCHITECTURE.md 明确记载了这套设计的动机为了压低 eager skill-listing 的 token 成本v1.40 引入了六个命名空间元技能gsd-workflow、gsd-project、gsd-quality、gsd-context、gsd-manage、gsd-ideate它们叠加在具体子技能之上。模型看到的是 6 个命名空间路由器约 120 tokens而不是一份扁平化的 86 项技能清单约 2,150 tokens。也就是说commands/gsd/ns-review.md文档文件与/gsd-quality可调用的裸形式名称是同一技能的“一体两面”文档源文件以ns-*前缀命名表示 namespace 身份但 frontmatter 中的name:才是真正可调用的裸形式。这一点与普通命令文件如 commands/gsd/code-review.md 的name: gsd:code-review不同属于命名空间元技能的专属约定。设计上命名空间技能是**叠加式additive**的——引入/gsd-quality并不会吞掉任何子命令/gsd-code-review、/gsd-debug等具体命令始终可以直接调用。路由器只是帮助模型在“意图不明确”时先选择领域、再落到具体技能属于纯发现层discovery layer不承载任何业务逻辑。Frontmatter 解剖路由文档的元信息契约/gsd-quality的技能体只有一张路由表其全部行为由文件头部的 YAML frontmatter 声明--- name: gsd-quality description: quality gates | code review debug audit security eval ui argument-hint: allowed-tools: - Read - Skill requires: [code-review, audit-uat, secure-phase, eval-review, ui-review, validate-phase, debug, forensics] ---逐项解读这份契约name: gsd-quality可调用名称的裸形式不带gsd:前缀的命名空间约定也是命令文档中出现于 docs/COMMANDS.md、docs/USER-GUIDE.md、docs/FEATURES.md、docs/INVENTORY.md 各处的/gsd-quality形态。description采用“领域标签 | 成员技能关键词”的压缩格式——首段quality gates是给模型的领域提示后段code review debug audit security eval ui用于帮助模型在此元技能与其它五个元技能之间做“意图初筛”。由于路由器会在技能清单中被模型大量预览这种短标签刻意压低了 token 占用。argument-hint: 留空因为路由文档本身不接受用户参数参数在路由到具体子技能时才由用户意图决定。allowed-tools仅授权Read与Skill。Read用于读取本路由表以及必要的上下文Skill则用于“直接调用匹配到的子技能”——这是整个路由器的全部执行模型文档末尾也以指令形式重申了这一点。requires列出本命名空间覆盖的八个子技能依赖code-review, audit-uat, secure-phase, eval-review, ui-review, validate-phase, debug, forensics。该数组与正文路由表一一对应是安装、清单校验inventory manifest与集群校验的数据来源之一。核心路由表八条意图 → 技能映射的完整语义文档正文即一张意图路由表。完整继承如下并在其后逐条展开各子技能的定位、产物与关键参数用户意图User wants应调用的技能InvokeReview code for quality and correctness/gsd-code-reviewAuto-fix code review findings/gsd-code-review --fixAudit UAT / acceptance testing/gsd-audit-uatSecurity review of a phase/gsd-secure-phaseEvaluate AI response quality/gsd-eval-reviewReview UI for design and accessibility/gsd-ui-reviewValidate phase outputs/gsd-validate-phaseDebug a failing feature or error/gsd-debugForensic investigation of a broken system/gsd-forensics路由判定与命名空间的描述字段强相关只要用户意图落在“代码审查 / 调试 / 审计 / 安全 / 评估 / UI”任一语义域模型即应命中/gsd-quality随后根据细粒度意图在表中选取唯一一行并通过Skill工具直接调用目标子技能而不是自行“编造”执行步骤。代码质量与正确性审查/gsd-code-review审查一个 phase 期间变更的源文件产出按严重级别分类的{padded_phase}-REVIEW.md审查产物并内联输出摘要。其完整调用形态见 commands/gsd/code-review.md 的 argument-hint/gsd-code-review phase-number [--depthquick|standard|deep] [--files file1,file2,...] [--fix [--all] [--auto]]phase-number必填指定要审查哪个 phase 的改动例如2或02。--depthquick|standard|deep覆盖配置workflow.code_review_depth。quick仅做模式匹配约 2 分钟standard为逐文件分析并带语言相关检查约 5–15 分钟默认值deep做跨文件分析含导入图与调用链追踪约 15–30 分钟。--files file1,file2,...显式指定文件清单跳过 SUMMARY/git 范围推导具有最高优先级。实现上会派生gsd-code-reviewerAgent 进行分析commands/gsd/code-review.md 与仓库agents/目录中的gsd-code-reviewer文件彼此呼应。审查结果自动修复/gsd-code-review --fixns-review.md特别标注了一条版本演进事实gsd-code-review-fix已被/gsd-code-review --fix吸收#2790因此路由表中没有独立的 “fix” 命令而是同一命令的子旗标。--fix会在审查完成或 REVIEW.md 已存在后派生gsd-code-fixerAgent 自动应用修复并支持两个子旗标--all把 Info 级发现也纳入修复范围默认仅 Critical Warning。--auto启用“修复 复审”的迭代循环上限为 3 次。对用户而言这意味着 “审” 与 “修” 现在是一条命令上的同族操作路由文档刻意让两个意图行共享同一个技能入口避免模型误调到已废弃的历史技能名。UAT / 验收审计/gsd-audit-uat当用户想审计验收测试acceptance testing状态时调用。它的定位是跨 phase 审计所有未结的 UAT 与验证项属于验收阶段的“查漏”技能与verify-work对话式 UAT 验证当前功能见 commands/gsd/verify-work.md形成互补verify-work负责执行验证audit-uat负责盘点存量 UAT/验证缺口。其输出形态受 UAT 记录 frontmatter 约束仓库存在对应的一致性测试。阶段安全审查/gsd-secure-phase对某个 phase 做安全维度的专项审查。它在质量域中的位置属于“安全审计”子域与代码审查正确性/质量不同维度该技能的命名也表明它作用于 phase 粒度而不是仓库级整体安全扫描。AI 产出质量评估/gsd-eval-review当用户希望评估 AI 响应质量时路由至此。其本质是审计一个已执行 AI phase 的评估evaluation覆盖情况并产出EVAL-REVIEW.md修复计划。它是 GSD 针对“AI 编写代码也需要被评估”这一场景的落地技能与ai-integration-phase、Agent 体系中的评估/审计 Agent 协同构成闭环。UI 设计与可访问性审查/gsd-ui-review对已实现的前端代码做回溯式retroactive六支柱视觉审计六支柱即设计、可访问性等维度详见其描述中的 6-pillar 语义是 UI 质量门禁的代表技能。它与 workflow 域的 commands/gsd/ui-phase.md构建 UI 阶段成对出现前者构建、后者把关。阶段产出验证/gsd-validate-phase对已完成的 phase回溯式审计并补齐 Nyquist 验证缺口GSD 内部的验证完备性规范。注意区分三个近邻技能validate-phase补齐的是“验证方法学缺口”audit-uat盘点的是“UAT/验收项缺口”而verify-work才真正执行对话式 UAT。故障调试/gsd-debug对失败的功能或报错做系统性调试并在上下文重置之间保持持久状态。它对应仓库中完整的调试会话管理设施调试会话在 context 重置后仍可恢复适合“某个功能跑不通/报错”这类迭代中问题与下面的取证场景形成对照。破损系统的取证调查/gsd-forensics当系统已“坏掉”且成因不明超出普通调试范围时使用。取证与调试的边界是路由表隐含的一条重要语义线“feature/error 失败”走debug“broken system”原因调查走forensics。后者面向恢复现场、还原事件链的深度调查。路由之后发生了什么Skill 直接调用ns-review.md以一句强制指令收尾Invoke the matched skill directly using the Skill tool.这定义了路由器的执行模型/gsd-quality自身不包含任何审查/调试逻辑也不允许自行臆造步骤。模型在Read路由表后用Skill工具把控制权交给表中命中的子技能子技能随后派生各自的后台 Agent如gsd-code-reviewer、gsd-code-fixer、读取 get-shit-done/workflows 目录中的对应 workflow 文件并按 phase 目录产物REVIEW.md、EVAL-REVIEW.md、UAT 记录等落地结果。从源码结构看命名空间层的allowed-tools之所以被严格收敛到Read/Skill正是为了让元技能“只指路、不干活”防止模型在路由阶段就越权执行写操作。在技能集群中的位置clusters.cjs的ns_meta命名空间元技能并非独立于技能面管理体系之外。在运行时表面模块的技能集群定义 get-shit-done/bin/lib/clusters.cjs 中六个命名空间路由器被归入ns_meta集群ns_meta: Object.freeze([ ns-context, ns-ideate, ns-manage, ns-project, ns-review, ns-workflow, ]),集群cluster是/gsd:surface用以批量启用/禁用技能分组的机制且成员允许重叠——同一技能可属于多个集群。观察 get-shit-done/bin/lib/clusters.cjs 可以发现质量域的成员技能同时散落在多个集群中例如audit_review集群收纳了code-review、review、audit-fix、audit-milestone、audit-uat、verify-work、validate-phase、plan-review-convergence、eval-review、add-tests、secure-phaseui集群收纳ui-phase与ui-reviewai_eval集群收纳ai-integration-phase与eval-reviewns_meta集群则只收六个ns-*路由文档本身。这套重叠结构说明质量能力在功能上彼此相关可被audit_review一键整组开关而六个路由元技能又在“命名空间层”被单独管理。由于命名空间元技能是 GSD 路由发现的关键路径仓库存在针对性的回归测试如 tests/enh-2792-namespace-skills.test.cjs并在 docs/research/data/2026-05-12-skill-audit.json 的技能审计数据与 docs/INVENTORY-MANIFEST.json 清单中登记备案。命名空间体系中的分工边界/gsd-quality与五个兄弟六个命名空间元技能共同覆盖整个命令面/gsd-quality只是其中“质检”一极。理解边界有助于正确路由意图对照各 ns 源文件 commands/gsd/ns-workflow.md、commands/gsd/ns-project.md、commands/gsd/ns-context.md、commands/gsd/ns-manage.md、[commands/gsd/ns-ideate.md)命名空间元技能领域标签典型成员与 quality 的边界/gsd-qualityquality gatescode-review、debug、forensics、secure-phase、eval-review、ui-review、audit-uat、validate-phase对已有产物/系统做“质检、审查、修复”/gsd-workflowphase pipelinediscuss/spec/plan/execute-phase、verify-work、phase、progress驱动阶段流水线“验证”动作由verify-work归属于此/gsd-projectmilestone lifecyclenew-project、new-milestone、complete-milestone、audit-milestone、milestone-summary管里程碑生命周期审计的是里程碑而非代码/gsd-contextcodebase intelligencemap-codebase、graphify、docs-update、extract-learnings建立/查询代码库知识而非审查其质量/gsd-manageconfig workspaceconfig、workspace、workstreams、thread、ship、update环境与工程管理非质量把关/gsd-ideateexploration captureexplore、sketch、spike、spec-phase、capture想法/设计/捕获尚未进入实现质检值得注意的细微分工验收验证verify-work被归入/gsd-workflow而验收审计audit-uat与阶段验证validate-phase归入/gsd-quality——一个管“做验证”一个管“查验证是否到位”。模型中一旦混淆这两层就可能把执行动作路由到审计技能因此这张命名空间边界表是正确使用/gsd-quality的关键上下文。使用建议与最佳实践基于上述设计围绕/gsd-quality的实践要点可归纳如下先意图、后粒度对模型而言面对“审查/调试/安全/审计/评估/UI/验收”相关诉求应优先想起/gsd-quality面对模糊诉求时路由文档允许仅停留在命名空间层把细粒度选择交给后续的意图澄清。审查与修复是一条命令不要试图寻找gsd-code-review-fix之类的历史命令名——#2790 起它已并入/gsd-code-review --fix。同理gsd-scan/gsd-intel等折叠历史技能名也应避免见 commands/gsd/ns-context.md 的同类说明。区分 debug 与 forensics功能失败优先/gsd-debug会话状态可跨 context 重置持久化系统彻底破损且成因不明才考虑/gsd-forensics。产物即证据审查会落地REVIEW.md、评估会落地EVAL-REVIEW.md等 phase 目录产物路由正确性可通过这些产物是否在正确 phase 目录生成来校验。直接调用始终可用命名空间是叠加层而非替代层在意图明确时直接调用子技能如/gsd-code-review 3 --depthdeep仍是完全合法的路径。小结/gsd-quality是 get-shit-done 六个命名空间元技能中负责“质量门禁”的一环它用一张意图路由表把代码审查、自动修复、UAT 审计、安全审查、AI 评估、UI 审查、阶段验证、调试与取证九类诉求映射到八个具体子技能是模型在低 token 开销下进入质检能力面的“总闸”。其源文档 commands/gsd/ns-review.md 篇幅极简却浓缩了 GSD 技能面设计的三条原则路由与执行分离元技能只 Read Skill、叠加演进历史命令折叠进现有技能而非无限新增、意图驱动九行映射定义了“用户怎么说 → 系统怎么做”的完整契约。理解它就等于掌握了 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），仅供参考 
长河君 · 2026/9/8 19:03:30 · 阅读 1.2k get-shit-done `/gsd-quality` 命名空间元技能解析：质量门禁的意图路由与八大质检子技能实战指南
get-shit-done/gsd-quality命名空间元技能解析质量门禁的意图路由与八大质检子技能实战指南【免费下载链接】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-doneget-shit-doneGSD是一个基于 Claude Code 的元提示meta-prompting与规范驱动开发系统其技能面skill surface非常庞大。为了让模型在低 token 开销下快速定位正确的质检能力GSD 在 v1.40 引入了名为/gsd-quality的命名空间路由元技能源文件为 commands/gsd/ns-review.md它只做一件事根据用户的一句话意图路由到对应的代码审查、调试、安全、评估、UI、验收、取证等子技能。读完本文你将理解 GSD 命名空间路由文档的前置元信息frontmatter契约、九条路由映射的完整语义、各子技能的能力边界与产物以及这套设计在仓库架构、技能集群与文档体系中的具体落点。为什么需要“路由型”技能命名空间元技能的设计动机GSD 的每一条/gsd命令本质上都是可被模型直接调用的技能skill技能数量随功能演进不断膨胀。仓库的 docs/ARCHITECTURE.md 明确记载了这套设计的动机为了压低 eager skill-listing 的 token 成本v1.40 引入了六个命名空间元技能gsd-workflow、gsd-project、gsd-quality、gsd-context、gsd-manage、gsd-ideate它们叠加在具体子技能之上。模型看到的是 6 个命名空间路由器约 120 tokens而不是一份扁平化的 86 项技能清单约 2,150 tokens。也就是说commands/gsd/ns-review.md文档文件与/gsd-quality可调用的裸形式名称是同一技能的“一体两面”文档源文件以ns-*前缀命名表示 namespace 身份但 frontmatter 中的name:才是真正可调用的裸形式。这一点与普通命令文件如 commands/gsd/code-review.md 的name: gsd:code-review不同属于命名空间元技能的专属约定。设计上命名空间技能是**叠加式additive**的——引入/gsd-quality并不会吞掉任何子命令/gsd-code-review、/gsd-debug等具体命令始终可以直接调用。路由器只是帮助模型在“意图不明确”时先选择领域、再落到具体技能属于纯发现层discovery layer不承载任何业务逻辑。Frontmatter 解剖路由文档的元信息契约/gsd-quality的技能体只有一张路由表其全部行为由文件头部的 YAML frontmatter 声明--- name: gsd-quality description: quality gates | code review debug audit security eval ui argument-hint: allowed-tools: - Read - Skill requires: [code-review, audit-uat, secure-phase, eval-review, ui-review, validate-phase, debug, forensics] ---逐项解读这份契约name: gsd-quality可调用名称的裸形式不带gsd:前缀的命名空间约定也是命令文档中出现于 docs/COMMANDS.md、docs/USER-GUIDE.md、docs/FEATURES.md、docs/INVENTORY.md 各处的/gsd-quality形态。description采用“领域标签 | 成员技能关键词”的压缩格式——首段quality gates是给模型的领域提示后段code review debug audit security eval ui用于帮助模型在此元技能与其它五个元技能之间做“意图初筛”。由于路由器会在技能清单中被模型大量预览这种短标签刻意压低了 token 占用。argument-hint: 留空因为路由文档本身不接受用户参数参数在路由到具体子技能时才由用户意图决定。allowed-tools仅授权Read与Skill。Read用于读取本路由表以及必要的上下文Skill则用于“直接调用匹配到的子技能”——这是整个路由器的全部执行模型文档末尾也以指令形式重申了这一点。requires列出本命名空间覆盖的八个子技能依赖code-review, audit-uat, secure-phase, eval-review, ui-review, validate-phase, debug, forensics。该数组与正文路由表一一对应是安装、清单校验inventory manifest与集群校验的数据来源之一。核心路由表八条意图 → 技能映射的完整语义文档正文即一张意图路由表。完整继承如下并在其后逐条展开各子技能的定位、产物与关键参数用户意图User wants应调用的技能InvokeReview code for quality and correctness/gsd-code-reviewAuto-fix code review findings/gsd-code-review --fixAudit UAT / acceptance testing/gsd-audit-uatSecurity review of a phase/gsd-secure-phaseEvaluate AI response quality/gsd-eval-reviewReview UI for design and accessibility/gsd-ui-reviewValidate phase outputs/gsd-validate-phaseDebug a failing feature or error/gsd-debugForensic investigation of a broken system/gsd-forensics路由判定与命名空间的描述字段强相关只要用户意图落在“代码审查 / 调试 / 审计 / 安全 / 评估 / UI”任一语义域模型即应命中/gsd-quality随后根据细粒度意图在表中选取唯一一行并通过Skill工具直接调用目标子技能而不是自行“编造”执行步骤。代码质量与正确性审查/gsd-code-review审查一个 phase 期间变更的源文件产出按严重级别分类的{padded_phase}-REVIEW.md审查产物并内联输出摘要。其完整调用形态见 commands/gsd/code-review.md 的 argument-hint/gsd-code-review phase-number [--depthquick|standard|deep] [--files file1,file2,...] [--fix [--all] [--auto]]phase-number必填指定要审查哪个 phase 的改动例如2或02。--depthquick|standard|deep覆盖配置workflow.code_review_depth。quick仅做模式匹配约 2 分钟standard为逐文件分析并带语言相关检查约 5–15 分钟默认值deep做跨文件分析含导入图与调用链追踪约 15–30 分钟。--files file1,file2,...显式指定文件清单跳过 SUMMARY/git 范围推导具有最高优先级。实现上会派生gsd-code-reviewerAgent 进行分析commands/gsd/code-review.md 与仓库agents/目录中的gsd-code-reviewer文件彼此呼应。审查结果自动修复/gsd-code-review --fixns-review.md特别标注了一条版本演进事实gsd-code-review-fix已被/gsd-code-review --fix吸收#2790因此路由表中没有独立的 “fix” 命令而是同一命令的子旗标。--fix会在审查完成或 REVIEW.md 已存在后派生gsd-code-fixerAgent 自动应用修复并支持两个子旗标--all把 Info 级发现也纳入修复范围默认仅 Critical Warning。--auto启用“修复 复审”的迭代循环上限为 3 次。对用户而言这意味着 “审” 与 “修” 现在是一条命令上的同族操作路由文档刻意让两个意图行共享同一个技能入口避免模型误调到已废弃的历史技能名。UAT / 验收审计/gsd-audit-uat当用户想审计验收测试acceptance testing状态时调用。它的定位是跨 phase 审计所有未结的 UAT 与验证项属于验收阶段的“查漏”技能与verify-work对话式 UAT 验证当前功能见 commands/gsd/verify-work.md形成互补verify-work负责执行验证audit-uat负责盘点存量 UAT/验证缺口。其输出形态受 UAT 记录 frontmatter 约束仓库存在对应的一致性测试。阶段安全审查/gsd-secure-phase对某个 phase 做安全维度的专项审查。它在质量域中的位置属于“安全审计”子域与代码审查正确性/质量不同维度该技能的命名也表明它作用于 phase 粒度而不是仓库级整体安全扫描。AI 产出质量评估/gsd-eval-review当用户希望评估 AI 响应质量时路由至此。其本质是审计一个已执行 AI phase 的评估evaluation覆盖情况并产出EVAL-REVIEW.md修复计划。它是 GSD 针对“AI 编写代码也需要被评估”这一场景的落地技能与ai-integration-phase、Agent 体系中的评估/审计 Agent 协同构成闭环。UI 设计与可访问性审查/gsd-ui-review对已实现的前端代码做回溯式retroactive六支柱视觉审计六支柱即设计、可访问性等维度详见其描述中的 6-pillar 语义是 UI 质量门禁的代表技能。它与 workflow 域的 commands/gsd/ui-phase.md构建 UI 阶段成对出现前者构建、后者把关。阶段产出验证/gsd-validate-phase对已完成的 phase回溯式审计并补齐 Nyquist 验证缺口GSD 内部的验证完备性规范。注意区分三个近邻技能validate-phase补齐的是“验证方法学缺口”audit-uat盘点的是“UAT/验收项缺口”而verify-work才真正执行对话式 UAT。故障调试/gsd-debug对失败的功能或报错做系统性调试并在上下文重置之间保持持久状态。它对应仓库中完整的调试会话管理设施调试会话在 context 重置后仍可恢复适合“某个功能跑不通/报错”这类迭代中问题与下面的取证场景形成对照。破损系统的取证调查/gsd-forensics当系统已“坏掉”且成因不明超出普通调试范围时使用。取证与调试的边界是路由表隐含的一条重要语义线“feature/error 失败”走debug“broken system”原因调查走forensics。后者面向恢复现场、还原事件链的深度调查。路由之后发生了什么Skill 直接调用ns-review.md以一句强制指令收尾Invoke the matched skill directly using the Skill tool.这定义了路由器的执行模型/gsd-quality自身不包含任何审查/调试逻辑也不允许自行臆造步骤。模型在Read路由表后用Skill工具把控制权交给表中命中的子技能子技能随后派生各自的后台 Agent如gsd-code-reviewer、gsd-code-fixer、读取 get-shit-done/workflows 目录中的对应 workflow 文件并按 phase 目录产物REVIEW.md、EVAL-REVIEW.md、UAT 记录等落地结果。从源码结构看命名空间层的allowed-tools之所以被严格收敛到Read/Skill正是为了让元技能“只指路、不干活”防止模型在路由阶段就越权执行写操作。在技能集群中的位置clusters.cjs的ns_meta命名空间元技能并非独立于技能面管理体系之外。在运行时表面模块的技能集群定义 get-shit-done/bin/lib/clusters.cjs 中六个命名空间路由器被归入ns_meta集群ns_meta: Object.freeze([ ns-context, ns-ideate, ns-manage, ns-project, ns-review, ns-workflow, ]),集群cluster是/gsd:surface用以批量启用/禁用技能分组的机制且成员允许重叠——同一技能可属于多个集群。观察 get-shit-done/bin/lib/clusters.cjs 可以发现质量域的成员技能同时散落在多个集群中例如audit_review集群收纳了code-review、review、audit-fix、audit-milestone、audit-uat、verify-work、validate-phase、plan-review-convergence、eval-review、add-tests、secure-phaseui集群收纳ui-phase与ui-reviewai_eval集群收纳ai-integration-phase与eval-reviewns_meta集群则只收六个ns-*路由文档本身。这套重叠结构说明质量能力在功能上彼此相关可被audit_review一键整组开关而六个路由元技能又在“命名空间层”被单独管理。由于命名空间元技能是 GSD 路由发现的关键路径仓库存在针对性的回归测试如 tests/enh-2792-namespace-skills.test.cjs并在 docs/research/data/2026-05-12-skill-audit.json 的技能审计数据与 docs/INVENTORY-MANIFEST.json 清单中登记备案。命名空间体系中的分工边界/gsd-quality与五个兄弟六个命名空间元技能共同覆盖整个命令面/gsd-quality只是其中“质检”一极。理解边界有助于正确路由意图对照各 ns 源文件 commands/gsd/ns-workflow.md、commands/gsd/ns-project.md、commands/gsd/ns-context.md、commands/gsd/ns-manage.md、[commands/gsd/ns-ideate.md)命名空间元技能领域标签典型成员与 quality 的边界/gsd-qualityquality gatescode-review、debug、forensics、secure-phase、eval-review、ui-review、audit-uat、validate-phase对已有产物/系统做“质检、审查、修复”/gsd-workflowphase pipelinediscuss/spec/plan/execute-phase、verify-work、phase、progress驱动阶段流水线“验证”动作由verify-work归属于此/gsd-projectmilestone lifecyclenew-project、new-milestone、complete-milestone、audit-milestone、milestone-summary管里程碑生命周期审计的是里程碑而非代码/gsd-contextcodebase intelligencemap-codebase、graphify、docs-update、extract-learnings建立/查询代码库知识而非审查其质量/gsd-manageconfig workspaceconfig、workspace、workstreams、thread、ship、update环境与工程管理非质量把关/gsd-ideateexploration captureexplore、sketch、spike、spec-phase、capture想法/设计/捕获尚未进入实现质检值得注意的细微分工验收验证verify-work被归入/gsd-workflow而验收审计audit-uat与阶段验证validate-phase归入/gsd-quality——一个管“做验证”一个管“查验证是否到位”。模型中一旦混淆这两层就可能把执行动作路由到审计技能因此这张命名空间边界表是正确使用/gsd-quality的关键上下文。使用建议与最佳实践基于上述设计围绕/gsd-quality的实践要点可归纳如下先意图、后粒度对模型而言面对“审查/调试/安全/审计/评估/UI/验收”相关诉求应优先想起/gsd-quality面对模糊诉求时路由文档允许仅停留在命名空间层把细粒度选择交给后续的意图澄清。审查与修复是一条命令不要试图寻找gsd-code-review-fix之类的历史命令名——#2790 起它已并入/gsd-code-review --fix。同理gsd-scan/gsd-intel等折叠历史技能名也应避免见 commands/gsd/ns-context.md 的同类说明。区分 debug 与 forensics功能失败优先/gsd-debug会话状态可跨 context 重置持久化系统彻底破损且成因不明才考虑/gsd-forensics。产物即证据审查会落地REVIEW.md、评估会落地EVAL-REVIEW.md等 phase 目录产物路由正确性可通过这些产物是否在正确 phase 目录生成来校验。直接调用始终可用命名空间是叠加层而非替代层在意图明确时直接调用子技能如/gsd-code-review 3 --depthdeep仍是完全合法的路径。小结/gsd-quality是 get-shit-done 六个命名空间元技能中负责“质量门禁”的一环它用一张意图路由表把代码审查、自动修复、UAT 审计、安全审查、AI 评估、UI 审查、阶段验证、调试与取证九类诉求映射到八个具体子技能是模型在低 token 开销下进入质检能力面的“总闸”。其源文档 commands/gsd/ns-review.md 篇幅极简却浓缩了 GSD 技能面设计的三条原则路由与执行分离元技能只 Read Skill、叠加演进历史命令折叠进现有技能而非无限新增、意图驱动九行映射定义了“用户怎么说 → 系统怎么做”的完整契约。理解它就等于掌握了 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），仅供参考