开始工作项
将粘贴的 ADO 工单转化为：一个新的（或正确恢复的）分支、一份上下文记忆（后续会话可据此恢复）、基于代码库的深入探索，以及根因分析或功能布局。它在一个检查点结束——呈现发现并等待。本技能不编写任何修复或功能代码；用户首先批准方向，因为一个错误的 RCA 发布出去会浪费整个 QA 往返周期。
0. 加载本地配置
在解析工单之前，先阅读此技能文件夹中的 config.local.md。它保存了本技能故意不硬编码的名词：分支前缀、基础分支、项目的分层文档、调查存放位置、代码索引盲点以及值得参考的过往记忆。发现质量取决于这些细节，所以不要跳过。
如果文件缺失（全新安装），则尽你所能推断：基础分支从 git remote show origin（HEAD 分支）获取，前缀从用户现有分支（git branch --list "*/*"）获取——告诉用户你推断出的内容，并提议将其保存为 config.local.md（参见 config.example.md）。
记忆目录是系统提示词中为本项目命名的那个目录；仓库是你正在工作的仓库。两者都不需要配置。
1. 解析工单
从粘贴的内容中提取。ADO 页面的复制粘贴信息杂乱：第一行是大写的类型和 ID（USER STORY 12345、BUG 12346），每个字段标签单独占一行，下一行是值（State / Dev In Progress），标签以裸行形式出现在顶部附近，还有一些需要忽略的 UI 外壳（Save、Follow、Click to add …、switch to HTML editor、空的 TestRail 部分）。图片和附件在粘贴中不会保留。
- ID（数字）和工作项类型——Bug 与 User Story / Feature / PBI / Task。如果未指明类型，请推断它（重现步骤 + 预期/实际 ⇒ bug；"As a … I want" 或验收标准 ⇒ feature），并说明你推断的内容。
- 标题、状态、区域/迭代（如果存在）
- Bug：重现步骤、预期与实际结果、构建号、平台/设备/操作系统、深层链接、附件日志名称、提及的截图
- Feature：描述、验收标准、关联的设计、功能开关/实验名称
- 讨论/评论：早期尝试、QA 备注及其日期、PR 编号
如果没有 ID，请先索要 ID 再创建任何内容——ID 驱动分支和记忆名称。注意任何被引用但不可见的内容（截图、日志），以便你可以在检查点询问，而不是猜测其内容。
2. 分支
在你工作的仓库中运行 git（如果会话在工作树或其他克隆中，请使用那个——永远不要 cd 离开）：
git status --porcelain
如果工作区有未提交的更改，则停止。 列出文件和当前分支，并询问如何处理（结转、暂存或在旧分支上提交）。来自一个工作项的未提交文件会泄漏到下一个的提交中；由用户决定，而不是你。
当工作区干净时：
git fetch origin
git branch --list "<prefix>/<id>*"; git branch -r --list "origin/<prefix>/<id>*"
如果该 ID 不存在分支，则从 origin/<base> 创建 <prefix>/<id> 并记录短 SHA（git rev-parse --short HEAD）。
如果 <prefix>/<id> 或 <prefix>/<id>-N 已存在（本地或远程），请先查看最新的那个再做决定——同一个 ID 可能在三种截然不同的时刻出现：
git log --oneline origin/<base>..<prefix>/<id>[-N] # 未合并的提交？
git log --oneline origin/<base> --grep=<id> # "Merged PR NNNN: ... <id>" = 已合并
ADO 使用 squash 合并，因此已合并的分支仍然会显示其提交为“领先于”基础分支——基础分支上的 Merged PR 行才能告诉你它已合并。请将它与工单的状态以及最新 QA 评论的日期与分支的最后一次提交日期结合阅读。
| 最新现有分支 | 典型工单状态 | 操作 |
|---|---|---|
在 origin/<base> 之外没有提交（通常就是你所在的分支——用户在粘贴之前已创建它） | 新建 / 开发中 | 重复使用它。 检出，git merge --ff-only origin/<base>。 |
已合并（基础分支上有此 ID 的 Merged PR）并且 QA 在此之后已将其判定为失败 | 活动 / 重新打开，失败的 QA 评论日期晚于合并日期 | 创建下一个后缀（-1、-2，……）从 origin/<base> 开始；之前的尝试成为首要的发现素材。 |
| 未合并的提交（已推送或未推送），或 PR 仍为打开状态 | PR 审查 / 准备测试 / 进行中 | 进行中——不创建分支。 报告其内容（提交、是否已推送、落后基础分支多远），将其作为发现的主题，并询问是继续还是开始新的尝试。 |
如果信号不一致（例如状态为新建但存在未合并的分支），则视为进行中并询问——创建重复分支是代价高昂的错误。如果 git fetch 失败（VPN/认证），请说明并使用本地的 origin/<base>，并注明基础分支可能已过时。
不要推送也不要提交——用户尚未要求。
3. 上下文记忆（现在写入，稍后更新）
在发现之前写入记忆，状态为 ⏳，以便即使会话在调查中途死亡也可恢复。使用 references/memory-template.md。
- Bug →
bug-<id>-context.md，feature/story/task →feature-<id>-context.md - 如果此 ID 已存在记忆，则更新它而不创建第二个——并修正其中 git 状态现在矛盾的任何内容。
- 在
MEMORY.md中添加一行指针。没有它，后续会话将永远找不到记忆。
4. 代码库发现
目标是找到工单涉及的实际代码路径以及围绕它们的历史——足以让 RCA/布局引用 file:line，而不是猜测。
- 如果存在代码索引（CodeGraph、LSP）：首先使用工单的名词（页面、控件、服务、DTO）进行上下文查询，然后对查询结果进行一次 explore 调用；对可疑符号进行调用者/影响分析。检查配置中索引的盲点（它不解析的文件类型），并改为 grep 这些文件。
- 路由和 UI 名称：页面路由、组件名称、CSS 类以及来自工单的深层链接方案都是好的 grep 术语。
- 先前工作：
git log --oneline --all --grep=<id>，git log --oneline -20 -- <怀疑文件>，项目文档/调查文件夹（配置）以及同一区域的记忆目录中的文章。针对同一症状的、曾失败于 QA 的早期修复是最有价值的东西。 - **比较通过和失败的情况。**当 QA 列出通过的用例和一个失败的用例时，在确定机制之前，先在代码中找到两者实际上的不同之处——宿主页面、数据路径、时机。
- 每个头平台：如果 UI 在多个宿主机上共享（移动端 shell、Web），检查工单是否是平台特定的以及代码是否是。
- **不要在发现期间构建。**在这里阅读代码就足够了；构建很慢，属于实现阶段。
对于跨多个文件夹的广泛扫描，可以使用 Explore 子 agent；对于已知区域，直接手动操作。
5a. Bug → 根因分析
如果可用，使用 superpowers:systematic-debugging 技能的方法。标准是可测量的，而不是猜测的：命名机制和精确的 file:line，并解释为什么它精确地产生所报告的症状而不是其他症状（为什么失败的案例失败而通过的案例通过）。
- 从重现步骤中的用户操作到故障状态跟踪路径。引用相关行。
- 在不需要设备的情况下尽可能重现：使用组件测试进行状态/标记，使用无头浏览器静态副本进行布局/滚动/CSS 问题（配置可能指向描述现有测试工具的记忆）。如果你无法重现，请坦率说明，陈述你的置信度，以及哪些证据可以确认它（例如来自 QA 的特定日志行或截图）。
- 将根因与促成因素以及属于其他工单的相关问题区分开来。
- 提出修复方向（或 2-3 个选项并附有推荐）以及可以钉住它的回归测试——但暂时不要编写它们。
- 进行中的工作项（第 2 步）：RCA 成为对分支上已有修复的审查——它是否解决了最新的 QA 失败，以及哪些残余风险会导致它在设备上失败？建议继续使用它，并说明什么样的 QA 结果可以证明开始新的尝试是合理的。
5b. Feature → 布局和细化
如果可用，使用 superpowers:brainstorming 技能进行设计对话。
首先判断验收标准是否充分。它们是充分的，当：
- 每个 AC 都可以转化为具体的测试断言并映射到一个要修改的文件，并且
- UI 状态（加载、空、错误、禁用）、每个平台的行为、分析事件和功能开关要么已指定，要么显然不适用。
如果它们充分，不要为了提问而提问——直接布局功能。如果不充分，则需要细化：仅针对差距提问，分批在一个 AskUserQuestion 中（最多 4 个问题，具体选项，推荐一个默认值优先）。模糊的 AC 如果被猜测会导致返工。
在提问之前对每个差距进行分类：如果答案会改变设计（显示什么、数据来自哪里、用户点击时看到什么），则是一个问题。如果是具有明显内部惯例的事情——功能开关键、分析事件名称、DI 注册——选择惯例值，在布局中写入假定：，以便用户可以一目了然地纠正它，并且不要提问。4 个问题的批次是整个提问；后面不要有 "also, please confirm…" 的尾巴，因为这只不过是没有选项的更多问题。
布局涵盖：
- 要添加/修改的文件，按照项目的分层放置（配置指向定义它的文档），包括每个宿主机的 DI 注册
- 数据流：数据来自哪里，哪个服务拥有状态，它如何到达组件
- AC → 测试映射，为每个测试项目命名
- 平台差异、分析/标志、风险和未解决的问题
6. 检查点
用你发现的内容更新记忆文件（状态 🔄、根因摘要或布局摘要、未解决的问题），然后向用户呈现：
Bug：
## Bug <id>: <标题>
分支：<prefix>/<id>（来自 origin/<base> @ <sha>） — 或：进行中在 <branch>，无新分支
记忆：bug-<id>-context.md
### 根因
<机制，file:line，为什么它匹配症状> — 置信度：<高/中/低 + 可以提高什么>
### 证据
<代码引用，重现结果，历史：早期的 PR/尝试>
### 建议修复
<方向或选项 + 推荐；要添加的回归测试；要修改的文件>
### 需要你提供的
<缺失的截图/日志、决策>
Feature：
## Feature <id>: <标题>
分支 / 记忆：...
### AC 所说的 vs. 缺失的
### 建议布局（文件、数据流、AC → 测试、每个平台、假定：……）
### 问题 （或 "无——AC 充分"）
然后停止并等待批准。如果 RCA 或布局涉及 5 个以上文件或更改架构，提供将其写入项目文档/调查文件夹（配置）的提议——提议，而不是自动创建。