从任务工单和 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 目录下的文档完成后输出：