GSD (Get Shit Done) 是一套移植自 Claude Code 的完整项目生命周期管理工作流，专为将项目从初始想法系统化推进至最终交付而设计。该技能采用编排器+子代理架构，通过 /gsd 命令体系提供端到端的工程化管理能力。
核心用法涵盖完整的项目管理闭环：使用 new-project 启动新项目并进行深度上下文收集与四轮并行领域研究；通过 plan-phase 创建包含依赖分析与验证机制的执行计划；利用 execute-phase 以波浪式并行化方式推进开发；借助 verify-work 对交付物进行对话式用户验收测试。此外还支持 debug 进行系统性故障排查、map-codebase 分析遗留代码、pause-work/resume-work 实现会话中断恢复，以及完整的里程碑与待办事项管理体系。
显著优点体现在其工程化严谨性：首先，完整的workflow移植保证了与Claude Code同等的专业级项目管理方法论；其次，四轮并行研究机制（技术栈、功能特性、架构设计、潜在风险）能显著降低技术决策盲区；第三，强制验证环（planner-checker迭代）确保执行计划的质量门槛；第四，波浪式并行执行在保持上下文清晰的同时最大化利用并发能力；最后，完整的.artifacts目录结构提供了可审计的项目历史。
潜在缺点包括：学习曲线较为陡峭，用户需要理解GSD特有的阶段规划与波浪执行概念；对上下文窗口要求较高，长时间项目可能导致上下文累积；对于小型即兴任务可能显得过度工程化，虽然提供了quick模式但仍带有较重的流程惯性；依赖文件系统状态（.planning/目录），在环境切换时需要妥善处理状态持久化。
适合的目标群体主要是软件开发团队与技术项目负责人：需要严格项目治理的远程团队可通过其结构化流程保持协作一致性；独立开发者与创业者能借助其研究机制弥补技术视野局限；产品经理与技术负责人可利用其路线图功能进行里程碑规划与资源分配。特别适合中大型功能开发、技术债务重构、复杂系统集成等需要分阶段推进的工程任务。
使用风险主要来自三方面：性能层面，并行研究阶段会同时启动4个子代理，对计算资源与API配额消耗较大；依赖层面，重度依赖文件系统状态与git版本控制，若工作区污染可能导致状态不一致；来源层面，作为T3级个人来源技能，虽经安全审计但企业环境仍需额外评估。建议定期使用audit-milestone验证里程碑完整性，并在关键节点人工审查生成的执行计划。