القائمة
通过探索代码库对 Bug/Issue 进行排查归因，并基于 TDD 方式生成修复计划，同时创建对应的 GitHub issue。适用于用户报告了 bug、希望创建 issue、提到“triage”，或想调查并规划某个问题的修复方案。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
使用 tracer-bullet 竖向切片法，把 PRD 拆分成彼此独立、可以直接认领的 GitHub issues（并形成对应的实现工单）。适用于用户想把 PRD 转成 issues、创建实现任务，或把 PRD 拆成工作项。
使用 tracer-bullet 竖向切片方法把 PRD 转换成多阶段的落地实施计划，并保存为本地 Markdown 文件（存放在 `./plans/`）。适用于用户希望把 PRD 拆分为多个阶段、生成实施计划、从 PRD 推导阶段计划，或提到 “tracer bullets”。
通过用户访谈创建一个详细的重构计划，并将其拆分成很小的提交（tiny commits），最后以 GitHub issue 的形式归档。适用于用户希望规划一次重构、创建重构 RFC，或把重构拆成安全的渐进步骤。
使用 RED-GREEN-重构（red-green-refactor）循环进行测试驱动开发。适用于用户希望用 TDD 构建新功能或修复 bug，提到 “red-green-refactor”，希望使用集成测试，或询问“test-first development（先写测试）”。
从当前对话中抽取 DDD 风格的“统一语言”术语表（ubiquitous language glossary），标记歧义，并提出规范的术语选择。保存为 `UBIQUITOUS_LANGUAGE.md`。适用于用户希望定义领域术语、构建术语表、固化用词并强化术语一致性，或提到 “domain model” / “DDD”（领域模型与 DDD）。
通过用户访谈、代码库探索与模块设计来编写 PRD（产品需求文档），然后以 GitHub issue 的形式提交。适用于用户希望编写 PRD、创建产品需求文档，或规划一个新功能。
استنادا إلى تصنيف SOC المهني
| name | triage-issue |
| description | 通过探索代码库对 Bug/Issue 进行排查归因，并基于 TDD 方式生成修复计划，同时创建对应的 GitHub issue。适用于用户报告了 bug、希望创建 issue、提到“triage”，或想调查并规划某个问题的修复方案。 |
对用户报告的问题进行调查、定位根因，并创建一个包含 TDD 修复计划的 GitHub issue。该工作流尽量“半自动化”（hands-off）：在调查阶段尽量减少向用户追问。
从用户处获取该 issue 的简要描述。如果用户还没有提供，请只问一个问题：你现在看到的问题是什么？
在问出这些信息之后，不要再做进一步追问：立刻开始调查。
使用 Agent 工具（subagent_type=Explore）对代码库进行深入调查。你的目标是找到：
重点查看：
git log）基于你的调查结果，确定：
创建一个具体的、按顺序排列的 RED-GREEN 循环列表。每个循环都是一个“竖向切片”（vertical slice）：一次只覆盖一个小的行为修复步骤。
规则：
在创建 issue 时使用 gh issue create 并遵循下方模板。不要在创建 issue 之前先让用户审核：直接创建并把 URL 贴给用户。
清晰描述 bug 或 issue，包括：
描述你调查过程中发现的内容：
不要在 issue 中写死当前代码布局耦合到具体的文件路径、行号或实现细节。请以“模块、行为与契约”为粒度描述，让 issue 即使在大规模重构后依然可用。
用一个按序的数字列表写出 RED-GREEN 循环：
RED：写一个测试，来[描述期望行为] GREEN：让该测试通过所需的[最小改动]
RED：写一个测试，来[描述下一个期望行为] GREEN：让该测试通过所需的[最小改动]
...
REFACTOR：所有测试通过后，是否还需要进行任何清理（cleanup）？
在创建 issue 后，打印 issue 的 URL，并输出一行总结（root cause 的一句话概括）。