菜单
运行交互式 QA session：用户通过对话报告 bugs 或 issues，agent 随后创建 GitHub issues；同时在后台探索 codebase，获取上下文和 domain language。适用于用户希望报告 bugs、开展 QA、通过对话创建 issues，或提到“QA session”的场景。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
使用并行 sub-agents 为一个 module 生成多套差异显著的 interface 设计。适用于用户希望设计 API、探索 interface 选项、比较 module 形态，或提到“design it twice”的场景。
通过用户访谈创建一份由微小 commits 组成的详细 refactor plan，并将其提交为 GitHub issue。适用于用户希望规划 refactor、创建 refactoring RFC，或将 refactor 拆分为安全的增量步骤。
从当前对话中提取一份 DDD 风格的 ubiquitous language glossary，标出歧义并提出规范术语，保存到 UBIQUITOUS_LANGUAGE.md。适用于用户希望定义 domain terms、建立 glossary、收紧术语、创建 ubiquitous language，或提到“domain model”或“DDD”的场景。
询问当前情境适合使用哪个 Skill 或工作流。本 Skill 是仓库内其他 Skills 的路由入口。
从用户指定的固定点（commit、branch、tag 或 merge-base）开始，从两个维度审查代码变更：Standards 检查代码是否遵守仓库记录的编码规范，Spec 检查实现是否符合原始 Issue、PRD 或规格。两个审查由并行子 Agent 分别完成，再并列汇报。适用于用户希望审查分支、PR、开发中的改动，或要求“审查自 X 以来的变更”时。
用于设计深模块的共享词汇体系。适用于用户希望设计或改进模块接口、寻找深化机会、决定 seam 的位置、提高代码的可测试性或 Agent 可导航性，或其他 Skill 需要使用深模块词汇时。
| name | qa |
| description | 运行交互式 QA session：用户通过对话报告 bugs 或 issues，agent 随后创建 GitHub issues；同时在后台探索 codebase，获取上下文和 domain language。适用于用户希望报告 bugs、开展 QA、通过对话创建 issues，或提到“QA session”的场景。 |
运行一场交互式 QA session。用户描述遇到的问题；你负责澄清、探索 codebase 以获取上下文，并创建经得住时间和重构、以用户为中心、使用项目 domain language 的 GitHub issues。
让用户用自己的话描述问题。最多提出 2–3 个简短澄清问题，重点关注：
不要过度访谈。现有描述已经足以创建 issue 时，直接继续。
与用户对话的同时，在后台启动一个 Agent（subagent_type=Explore），理解相关区域。探索的目标是补足以下上下文：
UBIQUITOUS_LANGUAGE.md）这些上下文有助于写出更好的 issue；issue 正文中不得引用具体文件、行号或内部实现细节。
创建前，判断当前问题应作为单个 issue，还是拆成多个 issues。
出现以下情况时拆分：
出现以下情况时保留为单个 issue：
使用 gh issue create 创建 issues。无需先请用户审阅；直接创建并分享 URLs。
Issues 必须具有持久性，即使 codebase 经历大规模重构，内容仍然成立。使用用户视角进行描述。
使用以下模板：
## 发生了什么
[用直白语言描述用户实际遇到的行为]
## 预期行为
[描述期望发生的行为]
## 复现步骤
1. [开发者可以照着执行的具体编号步骤]
2. [使用 codebase 中的 domain terms，不要使用内部 module names]
3. [包含相关 inputs、flags 或 configuration]
## 补充上下文
[来自用户或 codebase 探索的额外观察，用于帮助界定问题。例如：“仅使用 Docker layer 时发生，filesystem layer 不会发生。”使用 domain language，不要引用文件]
按依赖顺序创建 issues（blockers 优先），以便引用真实 issue numbers。
每个 sub-issue 使用以下模板：
## Parent issue
#<parent-issue-number>（创建了 tracking issue 时）或“Reported during QA session”
## 问题
[描述这一项具体 behavior 问题，只写当前 slice，不要重述完整报告]
## 预期行为
[当前 slice 的期望行为]
## 复现步骤
1. [只与当前 issue 相关的步骤]
## Blocked by
- #<issue-number>（当前 issue 必须等待另一项解决时）
没有 blockers 时填写“None — can start immediately”。
## 补充上下文
[只与当前 slice 相关的额外观察]
拆分时：
UBIQUITOUS_LANGUAGE.md 时先检查）applyPatch() 在第 42 行抛错”创建后，输出所有 issue URLs，概述 blocking relationships，并询问：“下一个 issue，还是已经完成？”
持续进行，直到用户表示结束。每个 issue 独立处理，不要批量积压后再统一创建。