核心用法
GSD（Get Shit Done）是一个从 Claude Code 完整移植的项目管理工作流 Skill，专为需要将想法快速转化为可执行项目的开发者和团队设计。用户通过 /gsd 命令触发核心工作流，包括 new-project（项目初始化）、plan-phase（阶段规划）、execute-phase（并行执行）、progress（状态检查）等关键指令。系统采用编排器+子代理架构，主工作流保持精简上下文，通过并行研究代理（4 个并行研究员分别调查技术栈、功能需求、架构设计和潜在陷阱）获取深度领域知识，再经需求定义、路线图生成、阶段规划和波浪式并行执行，最终通过验证闭环确保交付质量。
显著优点
结构化思维框架：将模糊创意转化为系统化的项目计划，内置深度提问技巧和上下文检查清单，显著降低项目启动的认知负担。
并行效率最大化：4 路并行研究、多计划波浪式执行，充分利用 AI 并发能力缩短项目周期。
质量内建机制：每个阶段包含验证闭环（plan-checker 审核计划可行性，verifier 对照代码检查 must_haves），避免无效执行。
状态持久化：支持 pause-work/resume-work 断点续传，调试模式持久化状态跨会话保留，适合长周期项目。
灵活适配场景：既支持 new-project 完整 ceremony，也支持 quick 模式跳过可选代理快速响应临时任务；map-codebase 支持存量项目（brownfield）分析。
潜在缺点与局限性
上下文消耗较大：完整工作流涉及多轮代理调用和文件读写，对 token 消耗和响应时间有一定要求，小型任务使用 quick 模式更合适。
学习曲线陡峭：20+ 条命令和丰富的 flag 组合需要一定时间熟悉，初期可能因命令选择不当而无法发挥最佳效果。
强假设环境依赖：依赖 git 环境、特定目录结构（.planning/）和文件模板，在非标准开发环境中可能需要额外配置。
验证依赖代码静态分析：verifier 通过代码检查验证功能实现，无法替代实际运行测试，复杂业务逻辑仍需人工 UAT。
Markdown 纯文本架构：无外部依赖的设计保证了可移植性，但也限制了与外部项目管理工具（Jira、Linear 等）的原生集成。
适合的目标群体
- 独立开发者/全栈工程师：需要快速将产品想法转化为可执行代码的个人创作者
- 技术负责人/架构师：需要系统化梳理技术选型、风险评估和里程碑规划的团队领导者
- AI 辅助开发早期采用者：熟悉 Claude Code 范式，追求结构化 AI 协作的高级用户
- 咨询/交付顾问：需要标准化交付流程、可复用项目模板和清晰进度追踪的专业服务者
- 开源项目维护者：管理多阶段特性开发、版本发布和贡献者协作的社区项目团队
常规使用风险
文件系统变更风险：Skill 会主动创建 .planning/ 目录、初始化 git 仓库、修改 REQUIREMENTS.md 等文件，建议在干净目录或已备份的代码库中使用。
Git 操作权限：Bash 工具执行 git init/add/commit，虽无破坏性命令，但批量自动提交可能导致提交信息质量参差，建议 review 关键变更。
研究查询开销：WebSearch/WebFetch 调用会产生网络请求和额外延迟，研究深度与成本成正比，可通过 --skip-research 精简。
波浪执行资源占用：大规模并行计划执行可能同时触发多个子代理，需关注并发限制和响应延迟。
模板僵化风险：标准化模板虽保证一致性，但可能不契合极端定制场景，复杂项目需人工调整生成的计划文件。