Takes Master

GSD Master — AI驱动开发主技能

核心定位

本技能将 Claude Code 打造成 GSD驱动的专业开发Agent，以 get-shit-done (GSD) 工作流为核心方法论，oh-my-claude 和 gstack 为辅助插件，覆盖从项目启动到交付的完整开发周期。

三层插件体系：

primary:   GSD (get-shit-done)    — 结构化执行方法论，强制计划-执行-验证循环
secondary: oh-my-claude (omc)     — Claude Code原生能力增强，团队协作
tertiary:  gstack                 — 特定能力补充（Socratic/CEO等视角）

命令速查

新项目

• /takes:new-project — 初始化项目，生成 PROJECT.md + ROADMAP.md
• /takes:map-codebase — 扫描已有代码库，创建内部映射
• /takes:help — 显示完整帮助

阶段管理

• /takes:add-phase — 添加新阶段
• /takes:plan-phase <N> — 为阶段N制定任务计划
• /takes:execute-phase <N> — 执行阶段N
• /takes:verify-work <N> — 验证阶段N是否满足要求
• /takes:plan-fix <N> — 针对阶段N验证失败生成修复方案

进度与状态

• /takes:progress — 查看整体项目进度
• /takes:pause-work — 暂停工作并保存上下文
• /takes:resume-work — 恢复暂停的工作
• /takes:list-assumptions — 查看当前假设

团队协作

• /takes:discuss-phase <N> — 团队深度讨论阶段N
• /takes:set-ai <name> — 切换AI平台（Claude/Copilot等）

GSD核心命令详解

1️⃣ 启动新项目

触发条件：用户要求开始一个全新开发项目，或在空白目录启动。

执行流程：

第一步：/takes:new-project
  → 分析用户需求，明确项目类型、目标、约束
  → 使用 gsd-project-researcher 并行研究4个方向
  → 使用 gsd-research-synthesizer 综合研究结果
  → 使用 gsd-roadmapper 生成 ROADMAP.md
  → 生成 PROJECT.md（项目概述、目标、技术栈）
  → 生成 .planning/STATE.md（初始状态）
  → Git commit: "feat: 项目初始化"

第二步：/takes:map-codebase（如已有代码）
  → 使用 gsd-codebase-mapper 扫描代码库
  → 生成 .planning/codebase/（ARCHITECTURE.md / STACK.md / CONVENTIONS.md）
  → 分析技术债务和风险点
  → Git commit: "docs: 代码库映射"

第三步：/takes:plan-phase 1
  → 使用 gsd-phase-researcher 研究阶段1技术实现
  → 使用 gsd-planner 生成详细任务计划
  → 使用 gsd-plan-checker 验证计划质量（10维度）
  → 生成 phases/1-name/PLAN.md
  → Git commit: "feat: 阶段1计划"

PLAN.md 标准格式：

# 阶段1: [阶段名称]

## 成功标准（Goal-Backward）
必须TRUE的是什么？
1. [具体标准]

## 任务列表
- [ ] TASK-1.1: [任务名称] (wave: 1)
- [ ] TASK-1.2: [任务名称] (wave: 1, deps: TASK-1.1)

## 偏差处理规则
- 自己修：规则1-3（语法/逻辑/小bug）
- 停下来问：规则4（需求不清/架构决策）

2️⃣ 执行阶段

触发条件：用户要求开始执行，或阶段计划已制定完毕。

标准执行流程：

/takes:execute-phase <N>

第一步：读取阶段计划
  → 读取 .planning/phases/N-name/PLAN.md
  → 读取 .planning/ROADMAP.md

第二步：逐 wave 执行任务
  → wave内任务可并行（gsd-executor）
  → 每个任务完成后立即 git commit（原子提交）
  → checkpoint:human-verify（大任务后暂停等待确认）

第三步：偏差处理
  if 问题类型 in [语法错误, 逻辑bug, 小bug]:
      → gsd-executor 自主修复
  elif 问题类型 in [需求不清, 架构决策, 假设冲突]:
      → 暂停，询问用户决策 → 记录到 CONTEXT.md
  else:
      → gsd-debugger 介入

第四步：gsd-verifier 验证
  → 四层验证：存在性 → 实质性 → 连线 → 数据流
  → 生成 VERIFICATION.md

第五步（如需要）：gsd-nyquist-auditor 补全测试
  → 按覆盖率gap生成测试用例
  → 3次调试上限，超出则上报

Git commit: "feat: 完成阶段N"

3️⃣ 验证与修复

触发条件：用户要求验证阶段成果，或执行后自动触发。

验证流程（gsd-verifier）：

## 四层验证

### L1: 存在性验证
必须存在的文件/功能是否都存在？

### L2: 实质性验证
每个文件/功能是否真正实现了计划要求？

### L3: 连线验证
各模块之间的接口调用是否正确连接？

### L4: 数据流验证
数据是否按预期正确流转？

## 输出格式
验证报告 → VERIFICATION.md
  - ✅ 通过项
  - ❌ 失败项：[具体问题] → [修复建议]
  - ⚠️ 警告项：[潜在风险]

4️⃣ 视角切换（gstack 辅助能力）

在特定场景自动切换视角，提升决策质量：

CEO视角 Prompt 模板：

你是CEO视角。评估这个决策：
- 投入成本：开发时间/资源
- 预期收益：业务价值/用户增长
- 风险敞口：技术风险/依赖风险
- 时间窗口：上线deadline
- 竞争壁垒：护城河是什么

给出明确结论：[采用/否决/暂缓]+理由

苏格拉底提问 Prompt 模板：

使用苏格拉底提问法深入分析这个问题：
1. [基础问题] 这个说法的依据是什么？
2. [假设问题] 我们假设了什么前提？这些前提成立吗？
3. [证据问题] 支持这个结论的证据是什么？
4. [替代问题] 有没有其他可能的解释？
5. [后果问题] 如果错了，后果是什么？

结论：经过苏格拉底质疑后的核心认识。

5️⃣ 团队协作模式（oh-my-claude扩展）

当阶段复杂度高或存在多个技术方案时，启动omc-team协作：

/takes:omc-team <phase>

1. 任命3个角色并发讨论：
   - 激进派：提出创新方案，追求速度
  . 保守派：审查风险，提出质疑
   - 务实派：平衡前两者，给出折中建议

2. 各角色独立思考后，合并观点

3. 达成共识或提交用户决策

4. 决策记录到 CONTEXT.md

6️⃣ Checkpoint协议

长任务或关键节点暂停，等待人工确认：

## Checkpoint 类型

checkpoint:human-verify
  → 暂停，显示当前状态
  → 等待用户确认后继续

checkpoint:decision
  → 暂停，列出决策选项
  → 用户选择后继续

checkpoint:commit
  → 立即git commit，保存状态
  → 等待继续指令

与 oh-my-claude / gstack 的协同策略

何时使用 oh-my-claude（omc）

何时使用 gstack

状态文件规范

.planning/                          # GSD状态根目录
├── STATE.md                        # 当前状态：位置/性能/决策
├── ROADMAP.md                      # 阶段路线图
├── REQUIREMENTS.md                  # 需求可追溯性
├── CLAUDE.md                       # 项目规范（自动生成）
├── phases/
│   ├── 1-name/
│   │   ├── PLAN.md                 # 任务计划
│   │   ├── SUMMARY.md              # 执行总结
│   │   ├── VERIFICATION.md          # 验证报告
│   │   ├── CONTEXT.md               # 用户决策锁定
│   │   └── RESEARCH.md             # 研究资料
│   └── 2-name/
│       └── ...
└── codebase/
    ├── ARCHITECTURE.md
    ├── STACK.md
    ├── CONVENTIONS.md
    └── CONCERNS.md

参考文件

详细命令用法、视角模板、验证标准请查看 references/ 目录：

• references/commands.md — 所有GSD命令的完整用法和示例
• references/perspectives.md — CEO/苏格拉底/Socratic等视角的完整Prompt模板
• references/verification.md — 四层验证标准的详细检查清单
• references/gsd-vs-harness.md — GSD工作流 vs 传统Harness工程的对比和使用场景