// 处理 TAPD Bug/Story/Task 时使用，适用于 MCP 采集上下文、确认本轮范围、驱动 Superpowers 开发验证、合并到 develop、生成提测 Wiki 或写回 TAPD。
[HINT] Download the complete skill directory including SKILL.md and all related files
| name | tapd-workflow |
| description | 处理 TAPD Bug/Story/Task 时使用，适用于 MCP 采集上下文、确认本轮范围、驱动 Superpowers 开发验证、合并到 develop、生成提测 Wiki 或写回 TAPD。 |
| allowed-tools | ["tapd-mcp","yapi-mcp","gitlab-map","gitlab-mcp","company-project-routing","superpowers","update_topic"] |
| 变量 | 定义 | 来源 | 示例 |
|---|---|---|---|
{short-id} | TAPD 任务唯一简短 ID | tapd-mcp 的 short-id 字段 | 1014292 |
{slug} | 任务标题的语义化描述短语 | 从 TAPD title 提取（必须使用中文简述，如“修复分红规则”） | 修复分红规则 |
{git-user} | 当前 Git 用户名 | git config user.name | cfj |
{YYMMDD} | 任务启动时的年月日 | 系统日期 | 260509 |
{te} | 测试人员 | tapd-mcp 的 te 字段或自定义字段（见 collector.md 动态解析规则） | 张三 |
{de} | 开发人员 | tapd-mcp 的 de 字段或 current_owner | 李四 |
{reporter} | 报告人 | tapd-mcp 的 reporter 字段 | 王五 |
这个技能是 TAPD Bug/Story/Task 的受控执行流程。它负责 TAPD 上下文、本轮范围、GitLab 合并顺序、提测 Wiki 和 TAPD 写回；代码规划、实现和验证交给 Superpowers 执行。
这是固定阶段流程。不得跳阶段。任一阶段的退出条件不满足时，必须停下补齐证据或修正状态，再进入下一阶段。
tapd-mcp：读取和写回 TAPD。yapi-mcp：涉及接口对接时查询接口文档。gitlab-map：校验分支基线、提交同步和合并状态。gitlab-mcp：创建分支、处理合并请求、合并到 develop。company-project-routing：根据项目线索解析提测 Wiki 的 服务名称。superpowers：规划、实现、验证和分支收尾工作流。__test__ 文件夹中。__test__ 目录下的相关证据文件。origin/master 或用户明确指定的功能分支；禁止从 origin/develop 切开发分支。develop 另建 develop 基线分支。develop 时，如果分支合法来源比 develop 多出历史提交，将这些提交记录为“继承基线差异”，不得当作本轮阻断，也不得因此 cherry-pick 到 origin/develop 基线上重建分支。/tapd-workflow <TAPD链接>$tapd-workflow、/tapd-workflow、技能卡片或 TAPD 链接并要求修复/开发/处理时，即视为本技能已触发。id 只用于入口查询；worktree 和提测材料命名使用 TAPD MCP 返回的 short-id。代码分支名 必须是真实 Git 分支名，不能用 short-id 代替。/bug/detail/ 是 Bug，/story/detail/ 是 Story，/task/detail/ 是 Task；不得拿 Task 链接调用 Bug 查询。count: 0 或未找到条目，不能视为采集完成；必须校验条目类型是否用错，改用正确类型重查，仍失败才停在采集阶段说明阻塞。本技能必须维护单一阶段状态机。为了保持界面整洁并明确状态，禁止在文本回复中打印冗长的阶段台账。相反，每次阶段变更、进入新状态或遇到门禁阻塞时，必须强制调用 update_topic 工具，在 summary 中记录：当前阶段、已完成阶段、TAPD 属性、阻塞项、下一动作等状态流转信息。
在执行任何写操作（特别是 replace、write_file、包含 git 等命令的 run_shell_command，或 TAPD/Wiki 写入）前，必须在 thought 思考过程中进行显式自检：“当前所处阶段为 X，是否满足写入前提？”。
如果门禁未满足，必须停在当前阶段并通过 update_topic 和简短回复说明阻塞项，不得以普通修 Bug 的方式绕过。
越界回滚机制：不得把 TAPD 工作流降级成普通修 bug 路径。只要发现自己已经跳过阶段（例如没做测试就想提交，没独立评审就想合并），必须停止当前动作，汇报已偏离的阶段，撤销越界操作，并从最近未满足的门禁补齐。
评审子 Agent 只读边界与自动发起：阶段 4 调用评审子 Agent 时，必须使用最强隔离（优先 agent_type: explorer、默认 fork_context: false），并在 prompt 中明文禁止子 Agent 执行 git 提交/推送、创建或合并 MR、写回 TAPD/Wiki。主 Agent 在完成代码实现与自测后，应自动发起只读评审，无需用户针对“调用子 Agent”这一单纯只读动作进行额外二次确认。 提交、推送、MR、合并只能由主 Agent 在核验 REVIEW_PASSED 后执行；详见 references/reviewer.md。
任何文件编辑、代码格式化、git 提交或合并前，必须先在当前回复中明确输出 PRE_EDIT_GATE: PASS。缺少以下任一证据时必须写 PRE_EDIT_GATE: BLOCKED 并停止一切写操作：
本轮处理、本轮不处理、历史内容处理策略 已声明。gitlab-map 已完成分支来源、复用关系和基线校验。如果已经在 PRE_EDIT_GATE: PASS 前发生代码修改，立即停止继续修改和声称已修复，只能汇报违规阶段、已改文件、当前风险，并回到“分支确认子流程”或“规划子流程”补门禁。
| 阶段 | 进入条件 | 退出前必须产出 |
|---|---|---|
| 1. 采集上下文 | 已定位 TAPD 项 | TAPD 摘要、关键字段、评论、附件、原型/PRD 结论 |
| 2. 补充上下文 | 采集结果不足以判断范围 | 缺失信息已说明，用户补充已纳入上下文 |
| 3. 确认本轮范围 | 上下文足以判断范围 | 本轮处理、本轮不处理、历史内容处理策略 |
| 4. 开发执行阶段 | 本轮范围已明确 | 分支确认校验通过；Superpowers 规划、实现、证据包真实生成；验证达到 REVIEW_PASSED |
| 5. 合并到 develop | 开发执行阶段通过且提交可合并 | 经用户确认后，GitLab 确认变更已合并到 develop |
| 6. 准备提测 Wiki | 合并已完成 | 完整 Wiki 草稿已展示并获得用户确认 |
| 7. 写回 TAPD | 用户已确认写回内容 | Wiki、评论、状态更新已完成 |
| 8. 清理 | 写回完成或取消 | worktree 已清理，最终结果已汇报 |
每个关键阶段完成后都要运行 regression-checker。如果检查失败，先修正证据或流程状态，再继续。
阶段完成汇报必须包含：
regression-checker 结论如果无法调用独立 regression-checker，必须按 agents/regression-checker.md 做同等自检，并在汇报中标明“按 regression-checker 规则自检”。
get_bug 和 update_bug 工具；处理 Story/Task 必须调用 get_stories_or_tasks 和 update_story_or_task。get_entity_custom_fields 动态查找语义匹配的字段，禁止硬编码。若无法确定映射，必须向用户确认并记录到 MEMORY.md。tapd-mcp 读取 TAPD，不使用 CLI 或页面抓取作为主来源。tapd-mcp 不可用，停止流程并说明阻塞原因。本轮处理、本轮不处理、历史内容处理策略。未声明的一律视为本轮范围外。这是对外单一主阶段，内部包含“分支确认 -> 规划 -> 实现 -> 验证”。
注意：这里是 Superpowers 执行的深水区，禁止“形式主义”和“伪造执行”。必须真实运行各项排查和测试工具。
执行细则见：references/development-execution.md。
gitlab-map 确认可合并状态。develop。服务名称 必须通过 company-project-routing 解析。必须按模板生成完整 Wiki 正文。仅在用户确认后执行：创建或更新提测 Wiki、写 Bug 评论、更新 TAPD 状态。
确认 GitLab 合并、TAPD 写回。 工作区清理门禁：
superpowers:finishing-a-development-branch 完成分支收尾。git status 确认当前工作区已恢复干净（或处于预期的基线状态）。