ns-bug-report-diagnosis

Bug 报告诊断

对此技能为只读。输入 = 产品报告（聊天、工单、截图描述、用户操作步骤）。输出 = 面向两类受众的聊天诊断：为负责复测的人提供通俗说明，并为下一位编码 Agent 提供简短指引。然后调度该 Agent，除非用户选择仅诊断。

此技能不会更改产品代码。补丁由 ns-execution-gitlab-issue 或 ns-coder 负责。入口优先级 4a。完整路由：../../ns-harness/references/code-skill-routing.md。继续规则：references/continue-handoff.md。

会话启动

参见 ../../ns-harness/references/session-boot.md。执行其他任何步骤之前，必须完成会话启动（阻塞）——仅限冷启动；如果本次会话已启动且文件未更改，则在会话中途跳过。绝不使用工具读取 AGENTS.md。

加载 architecture-rules.md 和 project-rules.md。如果存在 docs/context/，只打开调查地图要求的内容（覆盖项或匹配的棕地项目），不要读取整个语料库。此技能不会编写产品代码或 docs/context/ 文件（会话启动中的实现写入不受此限制）。

路由（先阅读）

触发短语：references/entry-triggers.md。

当用户需要产品故事诊断时使用——屏幕、预期与实际情况对比、作为报告的工单。即使用户之后还需要修复，屏幕故事仍从这里进入：先诊断，再调度。

如果用户要求实现或修复代码，但没有屏幕故事，则不要进入此技能 → ns-coder（优先级 5）。如果用户提供的是 GitLab ISSUE_URL，且这是宿主的第一个技能（裸执行 URL），则不要进入此技能 → ns-execution-gitlab-issue（优先级 1）。如果是没有屏幕故事的堆栈信息、CI 或日志，则不要进入此技能 → ns-investigator（优先级 4b）。如果涉及多天或版本范围，则不要进入此技能 → ns-spec-driven（优先级 2）。

移交出去

先撰写八节聊天报告（只读）。然后遵循 references/continue-handoff.md：

• 选择仅诊断 → 到此为止，交由用户处理。
• ISSUE_URL → 使用 diagnosis_complete 载荷调度 ns-execution-gitlab-issue。
• 其他情况 → 使用 diagnosis_complete 载荷调度 ns-coder。

不要在此技能中编写产品代码。除非用户选择仅诊断，或报告为空、没有可恢复的症状且没有 URL，否则不要等待用户再发一条消息。

不可妥协

1. 此技能中不得修改产品。 可读取、grep、glob、只读探索、使用浏览器或运行 docker ps。不得写入应用源代码、架构或迁移文件。不得提交。不得修改 GitLab 状态、标签或评论。之后，调度的 G/C 技能可以进行编辑。
2. 此技能中不得编写补丁。 不得在此编写修复方案、PoC 漏洞利用或“应用此差异”。最多指出位置（屏幕、客户端模块、路由、用例、持久化）。实现由 G 或 C 负责。
3. 追踪所有列出的层。 遵循 references/investigation-map.md。只有在打开使用方规则列出的其他层之后，才能说“仅前端”或“仅后端”（或“仅 API”/“仅 CLI”）。遇到第一个相似文件夹就停止，视为失败。
4. 仅限聊天。 除非用户要求，否则不要写入 .md 诊断文件。聊天报告本身就是交付物。
5. 聊天语言。 如果 project-rules.md 指定了交流语言，则遵循该语言；否则使用对话所用语言。第 2–3 节使用完整句子，不要使用电报式短语。
6. 区分事实与猜测。 标注假设。不得编造日志、ID 或未打开过的文件。
7. Docker。 绝不运行 docker compose up/down 或重启容器。如果规则指定了测试容器，可以运行 docker ps。不要为了“看看”而运行会修改状态的测试。
8. 范围外内容。 跳过 architecture-rules.md 标记为范围外的路径。不要编造登录凭据。
9. 写入边界。 如果使用方规则指定了必须经过的写入路径（引擎、聚合体、门面或等效路径），第 8 节不得提及该路径。不得编造规则未指定的写入路径。

输入

接受以下任意一种内容：

• 提示词中的自由文本报告
• 作为屏幕故事一部分的附加规格说明／截图描述／简短的技术栈片段
• GitLab 问题 URL——通过 MCP 读取（mcp-gitlab-usage 已在使用方预置，并非目录技能）。请勿在此技能中更改问题。

如果报告看起来为空，请从 ISSUE_URL／问题正文／截图／本次会话中找回症状，然后继续。仅当没有可找回的症状且没有 URL 时，才提出一个简短的澄清问题并停止。不要为了猜测 Bug 而探索整个代码仓库。

流程

report
  → restated symptom (expected vs actual)
  → discover stack (overlay → architecture-rules Stack → brownfield row)
  → trace UI → client state → HTTP → router → handler → domain → persistence
  → confirm or reject with code evidence
  → reproduce if the environment allows (optional)
  → chat report (output template)
  → continue-handoff (opt-out stop | G | C)

1. 用一段话复述报告：涉及谁、哪个屏幕／操作、预期结果、实际结果，以及任何错误文本。
2. 根据 references/investigation-map.md 查找路径。如果报告提到了某个实体，且 docs/context/brownfield-map.md 存在，则只浏览该行。
3. 沿着报告中的操作，追踪使用方中存在的每一层。
4. 收集证据：文件 + 行为不匹配之处。只引用能够证明问题的行。
5. 复现：如果可以访问 UI，且报告涉及某个屏幕，请尝试按步骤操作。不要编造凭据。如果凭据无效或应用不可用，请根据代码写出步骤，并说明你没有实际执行。如果 Bug 仅涉及 API 或 CLI，请在对应层复现并说明。如果无法复现，请说明原因。
6. 根据 references/output-template.md 编写聊天报告。不要跳过通俗语言部分。
7. 应用 references/continue-handoff.md。

置信度

级别	适用情况
高	已打开代码路径，且该路径能够解释症状
中	路径吻合，但运行时细节（数据、环境、权限）尚未验证
低	报告含糊，或仍有多个可能的层级，且没有确凿证据

即使置信度低，也要撰写报告，并继续分派，除非仅作诊断。列出哪些信息有助于提高置信度（ID、HAR、涉及的用户、记录）。

移交给下一个 Agent

结束技术部分时，确保另一个 Agent 无需重新阅读此技能即可开始编码。第 8 节必须包含 diagnosis_complete: true 以及 references/continue-handoff.md 中的载荷。

然后分派 G 或 C，除非用户选择退出。不要在此技能中实现。

此技能的通过／失败标准

通过： 修复 Agent 知道该从哪里着手；非工程人员读一遍后就能解释 Bug 以及如何验证修复；此技能因仅作诊断／报告为空而停止，或在 diagnosis_complete 的情况下分派了 G／C。

失败： 你在此技能中编辑了产品代码；罗列了文件概览；第 2–3 节仍含有工程术语；涉及多层的技术栈却只检查了一侧；在此处提出了差异补丁；在报告完整且未选择仅作诊断的情况下，停止并等待人工处理。

参考资料

文件	适用时机
references/investigation-map.md	如何查找技术栈路径并追踪各层
references/output-template.md	八部分聊天报告
references/entry-triggers.md	优先级 4a 与调查员／编码员
references/continue-handoff.md	选择退出、分派 G/C、防循环载荷
../../ns-harness/references/code-skill-routing.md	入口优先级与移交