القائمة
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/ForceInjection/domain-driven-design-skills --skill implementing-from-taskيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
استنادا إلى تصنيف SOC المهني
عرض SKILL.md
| name | implementing-from-task |
| description | 测试中, 用户明确指定执行 implementing-from-task 时候才执行, 其余情况一律不执行 |
识别用户输入包含以下要素：
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 目录下的文档完成后输出：