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

---
name: go
description: 终极执行按钮，激进模式一口气完成开发任务，兼容 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 确定任务范围

**用户指定范围**：

```bash
/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
```