从任务工单和 PRD 启动完整开发流程。识别用户输入的任务工单链接和 PRD 链接,自动解析任务 ID 创建分支,读取 PRD 生成 spec/plan/tasks 并实现代码。
This skill inherits all available tools. When active, it can use any tool Claude has access to.
action-mapping.mdfrontend-backend-decomposition-guide.mdplan-template.mdspec-template.mdtasks-template.md识别用户输入包含以下要素:
https://your-project-system.example.com/story/detail/{数字ID}https://your-company.atlassian.net/browse/PROJ-xxxxxhttps://your-docs.example.com/wiki/xxx 或 https://your-docs.example.com/doc/xxx示例输入:
实现 https://your-project-system.example.com/story/detail/123456 https://your-docs.example.com/wiki/DOC001
https://your-company.atlassian.net/browse/PROJ-12345 https://your-docs.example.com/doc/DOC002
修复 PROJ-12345 https://your-docs.example.com/wiki/DOC003
必须严格按顺序执行,禁止跳过任何步骤!
┌─────────────────────────────────────────────────────────┐
│ 阶段零:PRD 分析与服务定位(必须先理解再执行) │
│ ├── 0.1. 前后端职责划分 │
│ ├── 0.2. 服务定位(使用 service-discovery) │
│ ├── 0.3. 影响范围分析 │
│ └── 0.4. 输出初步分析 → ⏸️ 确认理解正确 │
├─────────────────────────────────────────────────────────┤
│ 阶段一:准备(必须完成后才能进入阶段二) │
│ ├── 1. 解析任务 ID │
│ ├── 2. 创建分支 │
│ └── 3. 获取 PRD 详细内容 │
├─────────────────────────────────────────────────────────┤
│ 阶段二:规划(必须输出文档并等待确认)🔴 强制确认点 │
│ ├── 4. 生成 spec.md → 包含影响范围分析 │
│ ├── 5. 生成 plan.md → 包含服务查找依据 │
│ ├── 6. 生成 tasks.md → 标注前后端依赖 │
│ └── ⏸️ 输出完整摘要,等待用户明确回复"确认" │
├─────────────────────────────────────────────────────────┤
│ 阶段三:实现(用户确认后才能开始) │
│ ├── 7. 分析依赖、决定执行方式 │
│ ├── 8. 实现代码 │
│ └── 9. 提交并创建 MR │
└─────────────────────────────────────────────────────────┘
违反检查点的后果:
目标:在创建分支和编写代码前,先理解需求并定位正确的服务。
使用 前后端分解指南 识别:
纯前端任务(后端无需关注):
纯后端任务(本技能重点):
协同任务(需前后端配合):
输出示例:
## PRD 分析结果
### 纯前端(后端无需关注)
- 评价列表页面新增筛选器 UI
- 动态详情页样式调整
### 纯后端(本次实现重点)
- 评价内容支持自定义表情存储和渲染
- 新增表情收藏接口
### 协同任务
- 评价 proto 新增 custom_emoji 字段(后端定义 + 前端使用)
参考项目文档定位涉及的服务(如果项目提供):
定位方法:
关键词匹配:
comment-service 或 content-service功能域匹配:
Proto 文件验证:
# 搜索相关 proto 定义
find proto/ -name "*.proto" -exec grep -l "YourFeature\|YourEntity" {} \;
输出示例:
## 服务定位结果
### 涉及服务
1. **service-a** (`app/service-a/` 或 `services/service-a/`)
- 原因:管理 XXX 功能
- 现有代码:`internal/repo/{feature}/{handler}.go`
- Proto: `proto/taptap/{service}/{feature}/v1/*.proto`
2. **service-b** (`app/service-b/`)
- 原因:负责 YYY 功能的数据处理
- 现有代码:`internal/service/{feature}.go`
- Proto: `proto/taptap/{service}/{feature}/v1/*.proto`
### 查找依据
- 关键词 "XXX" → 服务索引文档指向 `service-a`
- 关键词 "YYY" → 服务索引文档指向 `service-b`
- Proto 文件验证:`proto/taptap/{service}/` 确认包含相关定义
评估变更影响:
必须输出以下内容给用户确认:
## 📋 PRD 初步分析
### 后端需关注的功能
- [ ] 功能 1:描述
- [ ] 功能 2:描述
### 涉及服务
- **服务 A**:原因说明
- **服务 B**:原因说明
### 影响范围
- Proto 变更:是/否,影响范围
- 数据库变更:是/否,涉及表
- 配置变更:是/否,涉及配置项
---
⏸️ **请确认以上分析是否正确?**
- 回复 "确认" 继续后续流程
- 回复调整意见,我将重新分析
从输入中提取任务 ID:
https://your-company.atlassian.net/browse/PROJ-12345 → PROJ-12345)feat分支命名:{prefix}-{任务ID前缀}-{任务ID}-{short-summary}
git checkout -b feat-PROJ-12345-user-profile
读取用户提供的 PRD 链接内容:
创建 specs/TAP-{任务ID}/ 目录,生成以下文档:
spec.md(参阅 spec-template.md):
plan.md(参阅 plan-template.md):
tasks.md(参阅 tasks-template.md):
必须输出以下完整内容给用户,禁止省略:
## 📋 Spec 文档已生成
### spec.md 核心内容
#### 功能概述
{从 PRD 提炼的核心功能描述}
#### 涉及服务及依据
- **服务 A** (`app/xxx/`)
- 选择原因:{参考 service-index.md 的匹配逻辑}
- 现有代码:{相关文件路径}
- Proto 定义:{proto 文件路径}
#### 影响范围分析
- **Proto 变更**:{是/否,影响哪些服务}
- **数据库变更**:{是/否,涉及哪些表}
- **配置变更**:{是/否,Apollo/K8s 配置项}
#### 核心需求
- [ ] 需求 1:描述
- [ ] 需求 2:描述
### plan.md 核心内容
#### 实现步骤
1. {步骤 1 描述}
2. {步骤 2 描述}
#### 技术方案
- {关键技术选型和理由}
#### 风险点
- {潜在风险和应对措施}
### tasks.md 核心内容
#### 任务概览
- 总任务数:{X}
- 可并行:{是/否}
- 预计工时:{Y} 小时
#### 任务列表(前 3 项)
1. [ ] 任务 1 - {描述} | 类型: {纯后端/协同} | 依赖: {无/任务X}
2. [ ] 任务 2 - {描述} | 类型: {纯后端/协同} | 依赖: {无/任务X}
3. [ ] 任务 3 - {描述} | 类型: {纯后端/协同} | 依赖: {无/任务X}
---
⏸️ **请仔细review以上内容,确认以下问题**:
1. 服务定位是否正确?(参考项目 README.md 和 service-index.md)
2. 功能理解是否准确?(参考 PRD 原文)
3. 影响范围分析是否完整?(Proto/数据库/配置变更)
4. 实现方案是否合理?(技术选型、风险评估)
**请明确回复**:
- 回复 **"确认"** 或 **"继续"** 或 **"开始实现"** → 进入阶段三(实现代码)
- 回复 **调整意见**(如 "服务 X 应改为服务 Y")→ 我将修改文档并重新输出摘要
- 回复 **"取消"** → 终止流程
⚠️ 关键要求:
根据用户回复采取行动:
| 用户回复 | 操作 |
|---|---|
| "确认" / "继续" / "开始实现" / "OK" | 进入阶段三 |
| 具体修改意见(如 "服务改为 X") | 更新对应文档,重新输出摘要,再次等待确认 |
| "取消" / "停止" | 终止流程,清理分支 |
| 询问细节(如 "为什么选择服务 X") | 详细解释后,继续等待确认 |
自动检测任务间依赖关系:
根据依赖分析必须按以下方式执行:
| 条件 | 执行方式 | 说明 |
|---|---|---|
| 存在依赖 | 串行执行 | 按依赖顺序,单 agent |
| 完全独立 且 >= 2 个任务 | 必须并行 | 使用 git worktree,参阅 merging-parallel-work |
⚠️ 禁止:独立任务 >= 2 时串行执行(浪费时间,违反效率原则)
按任务清单逐个实现:
实现完成后:
git push -o merge_request.create 自动创建 MRCommit Message 格式:
feat(service-name): 实现 XXX 功能的并发处理 #PROJ-12345
## 变更内容
- 在 {config-file}.go 配置中新增并发数配置项
- 修改 {handler}/{feature}.go,使用 errgroup 实现并发处理
- 添加相关单元测试
## 技术方案
- 使用 Go 标准库 errgroup.Group 控制并发
- 并发数可通过配置动态调整,默认值 10
- 确保循环变量捕获,避免闭包问题
## 相关文档
- specs/PROJ-12345/spec.md
- specs/PROJ-12345/plan.md
Description 内容要求:
## 变更内容:列出修改的文件和具体改动## 技术方案:简述实现方式和关键决策## 相关文档:链接到 specs 目录下的文档完成后输出: