Get-Shit-Done 完整功能参考：Claude Code 元提示词与上下文工程系统的 142 项能力地图

Get-Shit-Done（GSD）是一个面向 Claude Code 等 AI 编程运行时的轻量级元提示词（meta-prompting）、上下文工程（context engineering）与规格驱动开发（spec-driven development）系统。本文以仓库 docs/FEATURES.md 为主干，逐层拆解其从“项目初始化 → 讨论 → UI 契约 → 规划 → 执行 → 验证 → 交付”的核心管线，以及围绕该管线生长的规划、质量保障、上下文工程、基础设施与各版本新增能力，帮助你建立对 GSD 功能全景与内部质量门的完整认知。读完你将能按需定位每个功能的入口命令、触发条件、产出物与关闭开关，并理解背后的多代理编排与状态机设计。

---

目录导航与文档关系

FEATURES.md 在仓库中的定位是一份带需求规格的功能与函数总参考（"Complete feature and function documentation with requirements"）。它与三份姊妹文档互补：

• 架构细节 → ARCHITECTURE.md：系统分层与内部模块结构；
• 命令语法 → COMMANDS.md：每条斜杠命令的参数解析；
• 状态文件生命周期 → STATE-MD-LIFECYCLE.md：STATE.md 前言的字段定义与渲染规则；
• 配置键详解 → CONFIGURATION.md：config.json 的键级说明。

全文按功能族 → 版本两层组织：先是八组横向能力域（Core / Planning / Quality Assurance / Context Engineering / Brownfield / Utility / Infrastructure），随后是 v1.27 起每个里程碑新增的纵向特性，共 142 项。每个条目都遵循一致的元结构：Purpose（目的）+ Requirements（REQ-XX 可追踪需求）+ Produces（产出物）/ Config（配置开关），其中的 REQ-* 编号正是文章末尾“需求覆盖门”检查的对象——需求 ID 是贯穿整个系统的可追踪主键。

---

一、核心管线：从想法到可交付软件的七步主循环

GSD 的设计哲学是“先讨论、后规划、再执行”，让每一个模糊地带（gray area）在编码之前被消除。

1. 项目初始化（Project Initialization）

命令： /gsd-new-project [--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	常见失败模式与缓解

流程为“提问 → 研究 → 综合 → 需求 → 路线图”五步：系统按检测到的项目类型（web app / CLI / mobile / API 等）自适应提问（“梦想抽取”而非“需求收集”），随后派出 4 个并行研究员代理（stack / features / architecture / pitfalls），由研究综合器汇入 SUMMARY.md。粒度设置控制阶段数量：coarse（3-5）、standard（5-8）、fine（8-12）。当 .planning/PROJECT.md 已存在时会阻止重复初始化（REQ-INIT-06）；--auto @file.md 跳过问答直接从文档抽取（REQ-INIT-07）；若存在 /gsd-map-codebase 的存量结果会一并载入。

2. 阶段讨论（Phase Discussion）

命令： /gsd-discuss-phase [N] [--auto] [--batch]

目的是在研究与规划之前捕获用户的实现偏好与决策，消除让 AI 猜测的灰色地带。系统先分析阶段范围并识别决策区（gray areas），按类型归类后只问“此前 CONTEXT.md 中尚未回答”的问题（REQ-DISC-03），最终把决策持久化到 {phase}-CONTEXT.md（含规范引用）。灰色地带分类：

类别	示例决策
视觉功能	布局、密度、交互、空状态
APIs/CLIs	响应格式、标志位、错误处理、冗长程度
内容系统	结构、语气、深度、流程
组织方式	分组标准、命名、重复、例外

--auto 自动选择推荐默认值；--batch 支持分组批量提问。两个值得注意的后续能力：当 USER-PROFILE.md 显示负责人是非技术型（learning_style: guided 等）时，系统会用产品结果语言改写提问，并把顾问研究的理由段落改写为平实语言（REQ-DISC-08/09）——这与 38 号开发者画像功能联动。

3. UI 设计契约（UI Design Contract）

命令： /gsd-ui-phase [N]

在规划前锁定设计决策，让同一阶段所有组件共享一致的视觉标准，产出 {padded_phase}-UI-SPEC.md。系统会先探测已有设计系统状态（shadcn components.json、Tailwind 配置、tokens），只问未回答的设计契约问题，并按 6 个验证维度校验：

1. Copywriting —— CTA 文案、空状态、错误消息
2. Visuals —— 视觉焦点、层级、图标可访问性
3. Color —— 强调色纪律、60/30/10 合规
4. Typography —— 字号/字重约束遵守
5. Spacing —— 栅格对齐、token 一致性
6. Registry Safety —— 第三方组件审查要求

若校验返回 BLOCKED 则进入最多 2 轮的修订循环。在 React/Next.js/Vite 项目缺少 components.json 时会引导完成 ui.shadcn.com/create 预设配置，预设字符串成为跨阶段可复现的规划产物；安全门要求先执行 npx shadcn view 与 npx shadcn diff 再引入第三方组件（REQ-UI-06）。

4. 阶段规划（Phase Planning）

命令： /gsd-plan-phase [N] [--auto] [--skip-research] [--skip-verify]

研究实现域并产出原子化、可执行、可验证的计划。每个计划只含 2-3 个任务，大小被约束为可装入单个上下文窗口；计划使用 XML 结构化表达，每个 <task> 携带 type、name、files、action、verify、done 字段：

<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>

每条计划都含 read_first 与 acceptance_criteria 小节；除非加 --skip-verify，计划检查器会跑最多 3 轮校验循环。8 个校验维度：需求覆盖、任务原子性、依赖排序、文件作用域（跨计划文件重叠不过度）、验证命令（每任务有可测试的完成标准）、上下文适配、缺口检测、Nyquist 合规。产出 {phase}-RESEARCH.md、{phase}-{N}-PLAN.md、{phase}-VALIDATION.md。若检测到前端阶段且无 UI-SPEC.md，会提示先跑 /gsd-ui-phase（UI 安全门，REQ-PLAN-07）。

5. 阶段执行（Phase Execution）

命令： /gsd-execute-phase <N>

以**波次并行（wave-based parallelization）**执行阶段内全部计划，每个执行器获得全新上下文窗口（200K tokens）。无依赖的计划进入 Wave 1 并行执行，依赖 Wave 1 的进入 Wave 2（等待前一波完成），直到全部计划完成；同波内存在文件冲突时退化为串行。

每个任务产出原子 git 提交（结构化提交消息），每完成一份计划写一份 SUMMARY.md，最后跑执行后验证器检查阶段目标，并产出 {phase}-VERIFICATION.md。执行器读取 PLAN.md 的同时可访问 PROJECT.md、STATE.md、CONTEXT.md、RESEARCH.md；支持 4 类检查点：auto、checkpoint:human-verify、checkpoint:decision、checkpoint:human-action。

并行安全机制值得注意：并行代理提交时使用 --no-verify 跳过 pre-commit 钩子以规避构建锁竞争，每波结束后由编排器统一补跑一次钩子；STATE.md 通过文件级锁文件防止多代理并发写坏。

6. 工作验证与交付

/gsd-verify-work [N]：用户验收测试（UAT）。从阶段中抽取可测试交付物、逐条呈现供用户确认；失败自动派调试代理诊断并生成修复计划；对改动 server/database/seed/启动文件的阶段注入冷启动冒烟测试（REQ-VERIFY-05），最终产出 {phase}-UAT.md。

/gsd-ship [N] [--draft]（6.5 号功能）：验证通过后，将本地完成推送到合并 PR：校验阶段已验证 → 经 gh CLI 推送分支并建 PR → 由 SUMMARY.md / VERIFICATION.md / REQUIREMENTS.md 自动生成 PR 正文 → 更新 STATE.md 的发布状态与 PR 号。--draft 建草稿 PR；ship.pr_body_sections 支持追加项目定制的 PRD 式段落（详见 135 号功能）。

7. UI 复查（UI Review）

命令： /gsd-ui-review [N]

对已实现前端代码做追溯式 6 支柱视觉审计，可独立在任何项目上运行（无需 UI-SPEC.md，按抽象质量标准）。每支柱 1-4 分计分，经 Playwright CLI 截屏存入 .planning/ui-reviews/（自动为该目录写 .gitignore），识别 Top 3 优先修复项。第 6 支柱在此处为 Experience Design（加载/错误/空状态覆盖），与 UI-SPEC 六维度形成审计闭环。

8. 里程碑管理（Milestone Management）

命令： /gsd-audit-milestone、/gsd-complete-milestone、/gsd-new-milestone [name]

校验里程碑全部需求达成（审计须识别桩实现/占位代码/未测试代码，REQ-MILE-02），随后归档至 MILESTONES.md、提供 git tag 与分支合并选项、清理 UI 复查截屏并开启下一开发周期。/gsd-new-milestone 复用 new-project 的“提问→研究→需求→路线图”流程，但不会重置既有工作流配置（REQ-MILE-09）。tag 创建行为可由 git.create_tag: false 关闭，供外部发布自动化项目使用（141 号功能）。

---

二、规划特性：让路线图具备动态适应能力

• 9. 阶段管理 /gsd-phase、/gsd-phase --insert [N]、/gsd-phase --remove [N]：追加新阶段、用十进制编号（如 3.1）插入、移除后重排后续阶段。已执行阶段禁止移除（REQ-PHASE-04），所有操作同步更新 ROADMAP.md 并创建/删除阶段目录。

• 10. 快速模式 /gsd-quick [--full] [--discuss] [--research]：以更快路径保留 GSD 保证的临时任务执行。复用与完整工作流相同的 planner + executor 代理，但默认跳过研究、计划检查与验证；--full 启用计划检查（最多 2 轮）与执行后验证；三个标志可组合（REQ-QUICK-07）。任务记录于 .planning/quick/YYMMDD-xxx-slug/。

• 11. 自主模式 /gsd-autonomous [--from N]：按路线图顺序迭代剩余阶段，对每阶段跑 discuss → plan → execute；遇到显式用户决策点（灰色地带接受、阻塞、验证）会暂停。每完成一阶段重读 ROADMAP.md以捕获动态插入的阶段。--to N（70 号）设置上限、--only N（63 号）只跑单阶段、--interactive（86 号）保持讨论内联而把 plan/execute 派发到后台代理并启用流水线并行。

• 12. 自由文本路由 /gsd-progress --do：从自然语言解析意图并映射到最匹配的 GSD 命令，路由前须用户确认，且区分“已有项目 / 无项目”两种上下文。

• 13. 便签捕获 /gsd-capture：零摩擦记想法。单次 Write 落盘时间戳笔记、list 列出项目/全局笔记、promote N 转结构化的 todo、--global 作用于全局。约束：禁止 Task / AskUserQuestion / Bash，纯内联执行（REQ-NOTE-05）。

• 14. 自动前进 /gsd-progress --next：读 STATE.md、ROADMAP.md 与阶段目录判定当前位置，自动唤起下一步正确命令。状态检测逻辑清晰可查：

状态	动作
无 .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 验证

命名取自奈奎斯特采样定理——为每个需求保证存在反馈信号：在写代码前就把自动化测试覆盖映射到阶段需求。系统在 plan-phase 研究期探测既有测试设施，将每条需求映射到具体测试命令，识别 Wave 0 任务（实现前所需的测试脚手架）。计划检查器将 Nyquist 合规作为第 8 个验证维度强制约束。追溯式入口为 /gsd-validate-phase [N]：扫描实现并把需求映射到测试、识别缺口并派审计器生成测试（最多 3 次尝试）、绝不改动实现代码（只动测试文件与 VALIDATION.md）、实现 bug 以升级项抛给用户。可用 workflow.nyquist_validation: false 关闭。

16. 计划检查（Plan Checking）

目标回溯式验证：计划在执行前是否能达成阶段目标。按 8 个质量维度校验、最多循环 3 轮、失败给出具体可执行反馈，可用 workflow.plan_check: false 关闭。100 号功能为修订循环增加停滞检测：连续迭代输出相同时升级策略或给出诊断退出。

17. 执行后验证（Post-Execution Verification）

对照阶段目标（而非仅任务完成度）自动化检查代码库交付，产出带 pass/fail 分析的 VERIFICATION.md，未决问题记入日志供 /gsd-verify-work 处理，可用 workflow.verifier: false 关闭。

18. 节点修复（Node Repair）

执行期任务验证失败时的自主恢复：分析失败后选择 RETRY（带具体调整重试）/ DECOMPOSE（拆成更小可验证子步骤）/ PRUNE（移除不可达成任务并升级给用户）。默认每任务 2 次修复预算，由 workflow.node_repair_budget 与 workflow.node_repair 配置。

19. 健康校验（Health Validation）

/gsd-health [--repair]：校验 .planning/ 目录完整性——缺失必选文件、配置一致性、无摘要的孤儿计划、阶段编号与路线图同步；--repair 自动修复可恢复问题。/gsd-health --context（124 号）另附上下文窗口利用率守卫。

20. 跨阶段回归门

阶段执行后先跑所有已完成前序阶段的测试套件再进入验证，任何失败被上报为跨阶段回归，并定位到被破坏的具体前序阶段——防止回归跨阶段累积。

21. 需求覆盖门

规划完成前，把 ROADMAP.md 分配给本阶段的所有需求 ID 抽出来，验证每条至少出现在一份 PLAN.md 中；未覆盖项会阻塞规划完成（REQ-COVGATE-03）。它与 64 号“范围缩减检测”形成三层防线（planner 禁令 → checker 维度 → 编排器回收），防止规划期静默丢需求。

---

四、上下文工程特性：对抗上下文腐烂（Context Rot）

22. 上下文窗口监控

当上下文所剩不多时同时提醒用户与代理。状态栏向用户显示使用百分比；监控器在剩余 ≤35% 注入 WARNING、≤25% 注入 CRITICAL 的代理侧警告；重复警告去抖（两次警告间隔 5 次工具使用），但严重度升级跳过去抖。架构上是两部分桥接系统：状态栏把指标写入 /tmp/claude-ctx-{session}.json，监控器读指标后注入 additionalContext 警告。关键原则：警告是建议性的，绝不覆盖用户偏好；所有钩子失败必须静默，绝不阻塞工具执行。

23. 会话管理（Session Management）

/gsd-pause-work、/gsd-resume-work、/gsd-progress：在上下文重置与会话间维持项目连续性。暂停时把当前位置与下一步写入 continue-here.md 和结构化 HANDOFF.json；恢复时优先从 HANDOFF.json（失败则回退状态文件）还原完整上下文；/clear 之后所有会话操作仍须可用。HANDOFF.json 包含阻塞项、待办人工动作与进行中任务状态，恢复会话时立即浮出这些事项。

24. 会话报告

/gsd-pause-work --report：生成结构化会话后总结文档 SESSION_REPORT.md，数据来自 STATE.md、git log 与计划/总结文件。报告段落：会话概览（时长/里程碑/阶段）、完成工作（提交/计划/阶段）、成果与交付物、阻塞与决策、资源估算（tokens/成本）、下一步建议。

25. 多代理编排

每个代理获得全新上下文窗口；编排器保持薄——派发代理、收集结果、路由下一步；上下文载荷包含全部相关项目产物；并行代理须真正独立（无共享可变状态）；代理结果先落盘再由编排器处理；失败代理会被识别（抽查实际输出与上报失败是否一致，REQ-ORCH-06）。

26. 模型画像（Model Profiles）

/gsd-config --profile <quality|balanced|budget|adaptive|inherit>：按代理精细控制所用模型，平衡质量与成本。画像为每个代理指派模型档位：

代理	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

代理级覆盖优先于画像；inherit 把决策让给运行时当前模型（在 OpenRouter、本地模型等非 Anthropic 提供方上必须用 inherit 以避免意外 API 成本）；画像切换走脚本（非 LLM 驱动）；模型解析每次编排只做一次而非每派发一次。

---

五、棕地特性：让既有代码库进入 GSD 工作流

27. 代码库映射（Codebase Mapping）

/gsd-map-codebase [area]：启动新项目前先分析既有代码库。为每个分析域派并行映射代理，向 .planning/codebase/ 产出结构化文档，覆盖技术栈、架构模式、编码约定与关注点：

文档	内容
STACK.md	语言、框架、数据库、基础设施
ARCHITECTURE.md	模式、分层、数据流、边界
CONVENTIONS.md	命名、文件组织、代码风格、测试模式
CONCERNS.md	技术债、安全问题、性能瓶颈
STRUCTURE.md	目录布局与文件组织
TESTING.md	测试设施、覆盖、模式
INTEGRATIONS.md	外部服务、API、三方依赖

--paths <p1,p2,...> 支持增量重映射：只探索列出的仓库相对前缀而非全树，也是执行后漂移门的刷新路径。每份文档的 YAML frontmatter 记录 last_mapped_commit，使漂移可对照映射点而非 HEAD 衡量。

27a. 执行后代码库漂移检测

每次 /gsd-execute-phase 结束时自动运行。计数“漂移元素”：映射路径外的新目录、(packages|apps)/*/src/index.* 的新 barrel 导出、新迁移文件（supabase/prisma/drizzle/src/migrations/…）、routes/ 或 api/ 下的新路由模块。配置：workflow.drift_threshold（整数，默认 3，最少新增结构元素数）与 workflow.drift_action（warn | auto-remap，默认 warn）。关键保证是非阻塞：任何内部失败（STRUCTURE.md 缺失、git 错误、mapper 启动失败）只记一行日志，漂移检测不能导致验证失败。

---

六、工具特性

• 28. 调试系统 /gsd-debug [description]：带跨上下文重置持久状态的系统性调试。状态机 gathering → investigating → fixing → verifying → awaiting_human_verify → resolved；已解决会话追加到 .planning/debug/knowledge-base.md，新会话先查知识库避免重复调查（REQ-DEBUG-06）。--diagnose（76 号）为只诊断模式，不做任何修改。
• 29. Todo 管理 /gsd-capture [desc]、/gsd-capture --list：待办存 .planning/todos/pending/，完成移入 completed/。
• 30. 统计面板 /gsd-stats：阶段/计划完成数、需求覆盖、git 提交指标，支持 json、table、bar 多输出格式。
• 31. 更新系统 /gsd-update：经 npm 查新版本 → 先展示更新日志再更新 → 运行时感知定位正确目录 → 本地改动备份至 gsd-local-patches/ → /gsd-update --reapply 在更新后还原本地修改（103 号为其追加逐 hunk 校验）。
• 32. 设置管理 /gsd-settings：交互式切换工作流开关与模型画像，写入 .planning/config.json，支持存为全局默认（~/.gsd/defaults.json）。核心配置键见下表：

设置	类型	默认	说明
mode	enum	interactive	interactive 或 yolo（自动批准）
granularity	enum	standard	coarse / standard / fine
model_profile	enum	balanced	quality / balanced / budget / inherit
models.<phase_type>	enum	(none)	按阶段类型覆盖模型档位（见 126 号）
dynamic_routing.enabled	boolean	false	失败分档升级总开关（见 127 号）
workflow.research	boolean	true	规划前领域研究
workflow.plan_check	boolean	true	计划验证循环
workflow.verifier	boolean	true	执行后验证
workflow.auto_advance	boolean	false	自动串联 discuss→plan→execute
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	搜索包含 gitignored 文件
parallelization.enabled	boolean	true	独立计划并行运行
git.branching_strategy	enum	none	none / phase / milestone

• 33. 测试生成 /gsd-add-tests [N]：基于 UAT 标准与验收标准、复用既有测试设施模式，为已完成阶段生成测试。

---

七、基础设施特性

34. Git 集成

每个任务独立原子提交；提交消息遵循 type(scope): description 结构：

type(phase-plan): description

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

支持 none / phase / milestone 三种分支策略；complete-milestone 提供 squash merge（推荐）或保留历史合并；.planning/ 的提交遵循 commit_docs 设置，且在 .gitignore 检出时自动跳过提交。

35. CLI 工具

面向工作流与代理的程序化工具，取代重复内联 bash。核心能力：state / phase / roadmap / verify 等原子命令；为每个工作流加载全部上下文的复合 init 命令；--raw 机器可读输出；--cjs 沙箱子代理模式（--cwd）；Windows 上全用正斜杠路径。命令类别覆盖 State（11 个子命令）、Phase（5）、Roadmap（3）、Verify（8）、Template（2）、Frontmatter（4）、Scaffold（4）、Init（12）、Validate（2）、Progress、Stats、Todo。

36. 多运行时支持

同一套 GSD 内容按运行时做内容变换后安装。支持运行时：Claude Code、OpenCode、Gemini CLI、Kilo、Codex、Copilot、Antigravity、Trae、Cline、Augment Code、CodeBuddy、Qwen Code。变换维度包括命令形式、代理格式、钩子事件、配置文件：

方面	Claude Code	OpenCode	Gemini	Kilo	Codex	Copilot	Antigravity	Trae	Cline	Augment	CodeBuddy	Qwen Code
命令	斜杠命令	斜杠命令	斜杠命令	斜杠命令	Skills (TOML)	斜杠命令	Skills	Skills	Rules	Skills	Skills	Skills
代理格式	Claude 原生	mode: subagent	Claude 原生	mode: subagent	Skills	Tool mapping	Skills	Skills	Rules	Skills	Skills	Skills
钩子事件	PostToolUse	N/A	AfterTool	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A
配置	settings.json	opencode.json(c)	settings.json	kilo.json(c)	TOML	Instructions	Config	Config	.clinerules	Config	Config	Config

37. 钩子系统

运行时事件钩子：状态栏显示模型、当前任务、目录与上下文用量；上下文监控器在阈值注入警告；更新检查器在会话启动时后台运行；所有钩子尊重 CLAUDE_CONFIG_DIR、带 3 秒 stdin 超时保护、失败静默。状态栏上下文用量为自动压缩缓冲区保留 16.5% 的归一化余量。状态栏示例与色阶：

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

色彩编码：<50% 绿、<65% 黄、<80% 橙、≥80% 红加骷髅图标。140 号 statusline.context_position 提供 front 选项以适配窄终端。

38. 开发者画像（Developer Profiling）

/gsd-profile-user [--questionnaire] [--refresh]：分析会话历史，构建 8 维度行为画像：沟通风格、决策模式、调试方法、UX 偏好、技术选型、挫败触发点、学习风格、解释深度。产出 USER-PROFILE.md（带证据引用）与 CLAUDE.md 画像小节。管线模块在 profile-pipeline.cjs（会话扫描/消息抽取/采样）与 profile-output.cjs（渲染/问卷/产物生成）中，行为分析由 gsd-user-profiler 代理完成。--questionnaire 在无会话历史时以交互问卷兜底。claude_md_path 配置键（115 号）可把生成文件定向到非根位置。

39. 执行加固

执行管线的三项增量质量改进，在级联前拦截跨计划失败：Pre-Wave 依赖检查（派发 Wave N+1 前先验证前一波产物中的关键链接已接好）、跨计划数据契约第 9 维（检查共享数据管道的计划变换是否兼容，防止一方裁掉另一方需要的原始数据）、导出级抽查（Level 3 接线验证后抽查真实导出使用，捕获“已接线但从未被调用”的死存储）。

40. 验证债务追踪

/gsd-audit-uat：防止项目带着未决测试推进时 UAT/验证项被静默丢失。五个组件：/gsd-progress 的跨阶段健康检查扫描全部前序阶段的未决项（pending/skipped/blocked/human_needed）并展示非阻塞警告；UAT 新增 status: partial 区分“会话结束”与“全部测试解决”；新增 result: blocked + blocked_by 标记外部依赖阻塞项；human_needed 验证项持久化为可追踪的 HUMAN-UAT.md；phase complete CLI 在 JSON 输出中返回验证债务警告。

---

八、自 v1.27 起的关键演进（41-142）

效率与执行模式

• 41. Fast Mode /gsd-fast [task description]：不派子代理、不生成 PLAN.md 的内联微任务执行（错别字修复、配置改动、小重构、补提交），原子提交并记入 .planning/quick/。判别：2 分钟内的一句话任务用 /gsd-fast；需要研究/多步规划/验证的用 /gsd-quick。
• 44. 持久上下文线程 /gsd-thread：跨会话但不属于任何阶段的轻量知识存储（.planning/threads/），含 Goal/Context/References/Next Steps 段落，可提升为阶段或 backlog 项。
• 47. 多仓库工作区支持：monorepo/多仓库的项目根解析，执行器在多仓库模式记录每仓库提交哈希。
• 62. Discuss Chain Mode --chain：一键串联 discuss → plan → execute，任一步失败即停链；全程尊重既有门设置。
• 117. Spike / 118. Sketch：执行前做有界可行性实验（每实验 Given/When/Then 假设 + 可运行代码 + VALIDATED/INVALIDATED/PARTIAL 判定，--wrap-up 打包为项目本地 skill）与免构建 HTML 设计探索（每题 2-3 个交互变体，themes/default.css 共享 CSS 变量，--wrap-up 打包胜出决策）。

外部协作与代码质量

• 42. 跨 AI 同行评审 /gsd-review --phase N [--gemini] [--claude] [--codex] [--coderabbit] [--opencode] [--qwen] [--cursor] [--ollama] [--lm-studio] [--llama-cpp] [--all]：调用外部 AI CLI 独立评审阶段计划，产出结构化 REVIEWS.md 供 /gsd-plan-phase --reviews 消费。评审者优先级：显式标志 > --all > review.default_reviewers > 全部检出评审者（136 号）。小上下文窗口本地模型可用 review.max_prompt_tokens_per_reviewer 自动裁剪。
• 93. 代码评审管线 /gsd-code-review、/gsd-code-review --fix：按阶段界定文件，quick/standard/deep 三档深度，Critical/Warning/Info 分级；--fix 读 REVIEW.md 修 Critical+Warning 并逐条原子提交；--auto 进入最多 3 轮修复+复评迭代。137 号加入可选的 fallow 结构性预扫描。
• 45. PR 分支过滤 /gsd-pr-branch：过滤掉仅改动 .planning/ 的提交，让评审者只看代码改动。
• 98. 自主审计到修复 /gsd-audit-fix：审计→自动可修/仅手工分类→带测试验证+原子提交的自主修复，--dry-run 预览分类表、--max N 限次数（默认 5）。
• 110. 跨 AI 执行委派 /gsd-execute-phase N --cross-ai：经 stdin 把 cross_ai: true 计划送给外部命令执行（防注入），失败时用户可重试/跳过（回退正常执行器）/中止。
• 116. TDD 管线模式 workflow.tdd_mode: true：planner 对合格任务强选 type: tdd，executor 强制 RED/GREEN/REFACTOR 门序——RED 提交（test(...)）必须先于 GREEN 提交（feat(...)），RED 阶段测试意外通过则快速失败；违规在 SUMMARY.md 的 ## TDD Gate Compliance 段暴露。

安全与防御

• 46. 安全加固：集中式 security.cjs 提供路径穿越防护（含 macOS /var→/private/var 符号链接解析）、提示注入检测、安全 JSON 解析、字段名校验、shell 参数清洗；gsd-prompt-guard.js 拦截针对 .planning/ 的注入（仅告警不阻塞）；gsd-workflow-guard.js 提示工作流外的文件直改改用 /gsd-quick//gsd-fast；CI 就绪的注入扫描套件见 tests/prompt-injection-scan.test.cjs。99 号为其增强：不可见 Unicode、编码混淆（base64/同形字）、熵分析。
• 60. 安全执行 /gsd-secure-phase <N>：威胁模型锚定而非盲目扫描；security_asvs_level（1-3，默认 1）设 OWASP ASVS 验证档，security_block_on（默认 high）决定阻塞阈值，审计由 gsd-security-auditor 代理执行。

状态、迁移与跨版本能力

• 59. Schema 漂移检测：检测 Prisma/Drizzle/Payload/Sanity/Mongoose schema 改动而无对应 migration/push；双层防御（plan 期注入提醒 + execute 期门控），GSD_SKIP_SCHEMA_CHECK 可覆盖。
• 69. STATE.md 一致性门：state validate 检测 STATE.md 字段与文件系统漂移，state sync [--verify] 从磁盘重构，state planned-phase 记录规划后状态迁移。
• 105. GSD-2 反向迁移 /gsd-import --from-gsd2 [--dry-run] [--force] [--path <dir>]：把 .gsd/（Milestone→Slice→Task）扁平化为顺序阶段号（M001/S01→phase 01…），产出 PROJECT/REQUIREMENTS/ROADMAP/STATE 与顺序阶段目录。
• 132-134. 供应链与安装加固：Package Legitimacy Gate 拦截幻觉/疑似 slopsquatting 包名（[ASSUMED] 不信任、[SLOP] 移除、失败安装禁止自动换名重试）；Skill Surface Budgeting 提供 core/standard/full 安装画像并以 /gsd:surface 运行时调节；Installer Migrations 让运行时配置清理显式、可审计、可回滚。

模型经济与上下文预算

• 89. 全局经验库：阶段完成时自动把 .planning/ 学习复制到全局库，planner 派发时注入相关条目（learnings.max_inject 封顶），features.global_learnings: true 启用。
• 90. 可查询代码库情报 /gsd-map-codebase --query：.planning/intel/ 维护 stack/api-map/dependency-graph/file-roles/arch-decisions 的 JSON 索引；status（24 小时陈旧阈值）、diff、refresh 子模式。
• 91. 执行上下文画像：context_profile: dev|research|review 一键选用按工作类型调优的设置组合。
• 102. 自适应模型预设 model_profile: "adaptive"：按代理角色自动定档（planner→quality、executor→balanced…）。
• 114. 上下文窗口感知的提示瘦身：当 CONTEXT_WINDOW < 200000 时，executor/planner 提示省略内联示例（移入 executor-examples.md 与 planner-antipatterns.md 按需加载），静态提示开销约降 40%；标准/富化档不受影响。
• 119/120. 代理瘦身：代理文件按 size frontmatter 分 XL(≤1600)/Large(≤1000)/Default(≤500) 三档并在 agent-size-budget.test.cjs 中强制执行；公共样板抽取到共享引用文件单点更新。
• 122/123. 技能面收敛与两级路由：31 个微技能折叠进 4 个新分组父技能与 6 个既有父技能的标志位；6 个命名空间路由技能（/gsd-workflow、/gsd-project、/gsd-quality、/gsd-context、/gsd-manage、/gsd-ideate）把模型看到的技能条目从 86（约 2150 tokens）降到 6（约 120 tokens），删除的微技能斜杠形式一律解析为“Unknown command”。
• 124/125. 上下文利用率与状态行生命周期：/gsd-health --context 与 gsd-sdk query validate.context 共用纯分类器（见 context-utilization.cjs：(tokensUsed, contextWindow) → { percent, state }，60% 警告、70% 临界）；状态行读取 STATE.md 的 active_phase/next_action/next_phases/progress 四个可选字段按场景渲染。
• 126/127. 分级模型选择：models.<phase_type> 六槽位（planning/discuss/research/execution/verification/completion）与 dynamic_routing（默认档起步、软失败时单档升级、max_escalations 封顶）。完整解析优先级链：model_overrides[<agent>] → dynamic_routing.tier_models[<tier>] → models[<phase_type>] → model_profile → 运行时默认。
• 130/131. 图新鲜度与 MVP 解析：/gsd-graphify status 返回 built_at_commit/commits_behind/commit_stale（提交 SHA 校验为 4-40 hex 防注入）；gsd-sdk query 新增 phase.mvp-mode、task.is-behavior-adding、user-story.validate 三个规范动词，终结工作流内联 4-8 行 bash 的重复。

里程碑收尾与可靠性（139-142）

• 139. 配额/限流失败分类：执行器输出命中 429、rate limit、usage_limit_reached 等哨兵时走“等待重置再恢复”路径，而非普通失败重试。
• 141. 里程碑 tag 开关 git.create_tag: false：跳过本地 tag 创建但照常归档。
• 142. 结构化 JSON 错误模式 gsd-tools --json-errors：失败命令返回 ok: false 的结构化载荷（error kind/message/command context/exit mapping），未知命令、校验错误、超时等映射到规范错误类。

---

九、贯穿全文的设计要点

纵观 142 项功能，可归纳出几条支配性设计原则：

1. 一切皆可追溯：每条需求都有 REQ-* 编号，需求覆盖门、范围缩减检测、里程碑审计都围绕 ID 展开，形成从 ROADMAP → PLAN → UAT 的完整证据链。
2. 门（Gate）是最基本的控制原语：gates.md 将工作流中所有校验点规约为 Pre-flight / Revision / Escalation / Abort 四种类型，规划检查器与验证器据此应用一致的逻辑；--auto 标志永远不能绕过硬停安全门。
3. 安全默认值优先，浪费被显式开关：核心质量门（research/plan_check/verifier/nyquist_validation/ui_safety_gate/node_repair）大多默认开启，而成本或噪音类特性（auto_advance、dynamic_routing、global_learnings、intel、community hooks、update banner）一律默认关闭或 opt-in。
4. 每次编排都以全新上下文窗口运转：讨论、规划、执行、验证各代理独立窗口，编排器只做薄派发与结果路由——这是上下文工程思想（模块标题语境）在编排层的落地，也是“spec-driven development”能稳定复现的机制保障。

对任何想在自己项目里启用 GSD 的开发者，建议的阅读路径是：先过一遍本文的核心管线（1-8），再按当前痛点查询对应功能号（例如“并行执行总是出问题”查 5/39/20，“上下文总是不够用”查 22/74/124），最后用 32 号的设置表把不合口味的质量门逐个调到想要的档位——一切行为都可通过 .planning/config.json 显式控制，且每个开关都对应到本文某个 REQ 编号，可随时回到这份功能地图里反查依据。

<输出文章> <输出文章>

[上述完整文章，标签内容与正文一致，此处省略重复] </输出文章>