spec-coding-skills/.claude/skills/go/SKILL.md

name	description
go	终极执行按钮，激进模式一口气完成开发任务，兼容 0->1 和 1->100 场景。

Go - 发射按钮

定位：执行按钮。无论是从零开始的 0->1，还是迭代优化的 1->100，按下 /go 就开始干活，不要停。

当用户调用 /go 或 /go <任务范围> 时，执行以下步骤：

1. 前置检查

1.1 必要文档检查

检查以下文件是否存在：

文件	必要性	用途
doc/tasks.md	必须	任务清单，执行的圣经
doc/PRD.md	必须	产品需求，理解业务
doc/FeatureSummary.md	建议	功能契约
doc/DevelopmentPlan.md	建议	技术方案
doc/UIDesign.md	可选	界面设计

缺少必要文档时：

❌ 缺少必要文档：
- doc/tasks.md (必须)
- doc/PRD.md (必须)

请先准备这些文档，或运行：
- /wp 生成 PRD
- /wt 生成 tasks

1.2 读取所有可用文档

读取存在的所有文档，建立完整上下文。

2. 智能判断执行范围

2.1 检测项目状态

┌─────────────────────────────────────────────────────────┐
│                    项目状态检测                          │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  检查 src/ 或主代码目录是否存在？                        │
│                                                         │
│     ├── 不存在 ──▶ 0->1 模式（全新项目）                │
│     │                                                   │
│     └── 存在 ──▶ 检查 tasks.md 中的 ITER 标记           │
│                   │                                     │
│                   ├── 有 ITER 标记 ──▶ 1->100 模式      │
│                   │                                     │
│                   └── 无 ITER 标记 ──▶ 继续未完成任务   │
│                                                         │
└─────────────────────────────────────────────────────────┘

2.2 确定任务范围

用户指定范围：

/go T-005          # 执行单个任务
/go T-005~T-010    # 执行任务范围
/go T-005 T-008    # 执行多个指定任务

自动判断范围：

场景	执行范围
0->1 全新项目	tasks.md 中的所有任务，从 T-001 开始
1->100 有 ITER 标记	优先执行 <!-- ITER: --> 标记的新任务
1->100 无 ITER 标记	执行所有状态为 pending/todo 的任务

2.3 向用户确认范围（唯一一次交互）

检测到项目状态：{0->1 全新项目 / 1->100 迭代项目}

即将执行任务：
- T-001: {任务名}
- T-002: {任务名}
- ...
- T-xxx: {任务名}

共 X 个任务。确认执行？[Y/n]

用户确认后，不再有任何交互，直到全部完成。

3. 激进模式执行

3.1 执行原则

┌─────────────────────────────────────────────────────────┐
│                    激进模式执行原则                      │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  1. 以 tasks.md 为圣经，严格按顺序执行                  │
│                                                         │
│  2. 不要停下来问用户，自主决策                          │
│                                                         │
│  3. 遇到问题自主修复，修复失败则记录并继续              │
│                                                         │
│  4. 发现文档冲突，基于架构经验选最优解，注释说明        │
│                                                         │
│  5. 利用所有可用工具：搜索、MCP、Skills                 │
│                                                         │
│  6. 每完成一个模块，Git 提交一次                        │
│                                                         │
└─────────────────────────────────────────────────────────┘

3.2 任务执行流程

对于每个任务 T-xxx：
│
├── 1. 读取任务详情（描述、验收标准、依赖）
│
├── 2. 检查依赖任务是否完成
│       └── 未完成 → 先执行依赖任务
│
├── 3. 执行任务
│       ├── 根据任务类型选择执行方式
│       ├── 编写代码 / 配置 / 测试
│       └── 验证验收标准
│
├── 4. 遇到问题？
│       ├── 尝试自主修复（最多 3 次）
│       ├── 修复成功 → 继续
│       └── 修复失败 → 记录问题，跳过，继续下一个
│
└── 5. 标记任务完成，更新 tasks.md

3.3 自主修复策略

问题类型	修复策略
编译错误	分析错误信息，修复代码
类型错误	检查类型定义，修复类型
依赖缺失	安装依赖包
测试失败	修复功能代码使测试通过
文档冲突	基于架构经验选最优解
未知错误	搜索解决方案，尝试修复

4. Git 提交规则

4.1 提交时机

每完成一个模块/Sprint后立即提交：

T-001 ~ T-004  → 提交一次（初始化模块）
T-005 ~ T-008  → 提交一次（核心功能模块）
T-009 ~ T-012  → 提交一次（扩展功能模块）
...

4.2 提交信息格式

feat(<scope>): <简要描述>

- 完成 T-xxx: {任务名}
- 完成 T-xxx: {任务名}
- ...

Co-Authored-By: Claude <noreply@anthropic.com>

示例：

feat(auth): 完成用户认证模块

- 完成 T-005: 用户登录功能
- 完成 T-006: 用户注册功能
- 完成 T-007: JWT Token 管理
- 完成 T-008: 权限验证中间件

Co-Authored-By: Claude <noreply@anthropic.com>

5. 进度汇报

5.1 模块完成汇报

每完成一个模块，简要汇报：

✅ 模块完成：{模块名}
   - T-005: 用户登录 ✓
   - T-006: 用户注册 ✓
   - T-007: JWT 管理 ✓
   - T-008: 权限验证 ✓

Git 提交: feat(auth): 完成用户认证模块

继续执行下一模块...

5.2 最终汇报

全部完成后，输出完整报告：

## 🚀 执行完成

**执行模式**: {0->1 全新项目 / 1->100 迭代}

**任务统计**:
| 状态 | 数量 |
|------|------|
| ✅ 完成 | X 个 |
| ⚠️ 跳过 | X 个 |
| ❌ 失败 | X 个 |

**Git 提交记录**:
- feat(init): 项目初始化
- feat(auth): 用户认证模块
- feat(core): 核心功能模块
- ...

**跳过/失败的任务**（如有）:
| 任务 | 原因 |
|------|------|
| T-xxx | {原因} |

**下一步建议**:
- 运行 `npm run dev` 验证
- 运行 `npm run test` 测试
- 检查跳过的任务

6. 特殊场景处理

6.1 技术栈识别

从文档中识别技术栈，自动适配：

识别来源	技术决策
package.json 存在	Node.js 项目
requirements.txt 存在	Python 项目
DevelopmentPlan 指定	按文档技术栈
无明确指定	询问用户（唯一例外）

6.2 测试策略

• 功能开发完成后执行测试任务
• 测试失败 → 先修复功能代码使测试通过
• 不跳过失败的测试继续部署

6.3 部署任务

• 先本地测试验证
• 确保 build 和 start 正常
• 远程部署需用户额外确认

---

工作流总览

/go
 │
 ├── 1. 前置检查
 │     ├── tasks.md 存在？ ──▶ 必须
 │     └── PRD.md 存在？ ──▶ 必须
 │
 ├── 2. 读取文档，建立上下文
 │
 ├── 3. 智能判断
 │     ├── 项目状态（0->1 / 1->100）
 │     └── 任务范围
 │
 ├── 4. 确认执行范围（唯一交互）
 │
 ├── 5. 激进模式执行
 │     ├── 按顺序执行任务
 │     ├── 自主修复问题
 │     ├── 模块完成 → Git 提交
 │     └── 汇报进度，继续下一个
 │
 └── 6. 最终汇报
       ├── 任务统计
       ├── Git 提交记录
       └── 下一步建议

注意事项

• tasks.md 是圣经，严格按其顺序和内容执行
• 不要停下来问用户，自主决策，自主修复
• 遇到无法解决的问题，记录并跳过，最后汇报
• 每完成模块立即提交，避免大量代码丢失风险
• 利用所有工具：搜索、MCP、其他 Skills

与其他 Skill 的关系

场景	使用方式
准备文档	/wp /wf /wd /wu /wt
评审文档	/rp /rf /rd /ru /rt
修改文档	/mp /mf /md /mu /mt
迭代变更（更新文档）	/iter
执行开发（本 Skill）	/go

典型工作流：

0->1：需求 → /wp → /wf → /wd → /wt → /go
1->100：发现问题 → /iter → /go