菜单
结构化深度讨论 Skill，用于与用户进行多轮问题分析和方案设计。当用户描述一个问题现象、故障表现、 技术困惑、方案选择困难，或明确说"讨论一下"、"帮我分析"、"我遇到一个问题"、"你觉得怎么样"、 "帮我想想"、"我在纠结"时，必须使用本 skill。当用户提供了一段描述（可能附带截图）并期望深入分析 而非直接给答案时，也应触发本 skill。即使用户只是抛出一个现象描述没有明确提问，也要使用本 skill 来引导结构化思考。不要在简单的事实查询（"X是什么"）或明确的执行指令（"帮我写个脚本"）上触发。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Findings-first code review workflow for AI coding agents. Use when the user asks to review uncommitted changes, commits in a date range, or a branch compared to the main branch / PR-style diff. Focuses on bugs, regressions, correctness risks, missing tests, security/data-safety issues, and other behavior-changing defects.
Automates pre-development workflow for large-scale complex tasks. Use when the user mentions "rewrite", "migrate", "overhaul", "refactor entire project", "transform", "rebuild in [language]", "spec-driven", or describes any large-scale project transformation that requires planning before coding. Also triggers on Chinese keywords: "改造", "重写", "迁移", "重构", "大规模", "规范驱动". Performs full project analysis, task decomposition, documentation generation, project-level instruction and native memory surface resolution, progress tracking setup, and then executes the plan within the same session.
基于 SOC 职业分类
| name | deep-discuss |
| description | 结构化深度讨论 Skill，用于与用户进行多轮问题分析和方案设计。当用户描述一个问题现象、故障表现、 技术困惑、方案选择困难，或明确说"讨论一下"、"帮我分析"、"我遇到一个问题"、"你觉得怎么样"、 "帮我想想"、"我在纠结"时，必须使用本 skill。当用户提供了一段描述（可能附带截图）并期望深入分析 而非直接给答案时，也应触发本 skill。即使用户只是抛出一个现象描述没有明确提问，也要使用本 skill 来引导结构化思考。不要在简单的事实查询（"X是什么"）或明确的执行指令（"帮我写个脚本"）上触发。 |
| version | 1.0.0 |
你正在执行 Deep Discuss 工作流——一个引导你与用户进行深度、结构化问题讨论的 Skill。核心理念是：不急于给答案，先把问题想透。
大多数时候，用户描述的"问题"和真正的问题之间存在鸿沟——信息可能不完整，表述可能有偏差，甚至问题本身可能不成立。如果你跳过思考直接给方案，很容易答非所问或遗漏关键点。这个 Skill 的价值在于：通过有纪律的分阶段思考，确保讨论的质量和深度。
整个讨论像一次联合诊断，你在每个阶段都应该明确标注当前所处的阶段，让用户随时知道"我们在哪"。
用户提供问题描述，可能包含：
你在此阶段的任务：只接收，不急于分析。先完整理解用户提供的全部信息，用自己的话简要复述关键点（不超过 3-5 句），确认理解无误。
如果用户的描述明显模糊或信息严重不足，可以在复述后提出 1-2 个最关键的澄清问题（不要一次抛出一堆问题，会打断用户的思路）。
这是最核心的阶段。你需要对用户提供的信息做三层审查：
第一层：问题是否成立？
第二层：信息是否充足？
第三层：是否有隐藏问题？
输出格式建议（不需要死板遵循，根据实际情况灵活调整）：
## Phase 2：问题审查
### 问题成立性
[你的判断 + 理由]
### 信息充足度
[已有信息概述 / 缺失信息 / 对分析的影响]
### 潜在隐藏问题
[发现的其他问题 / 或"暂未发现"]
如果在这个阶段发现需要补充信息，暂停后续流程，先等用户回复。不要带着不确定的假设往下走。
在 Phase 2 的基础上（信息已确认足够），展开全面、有深度的分析。
这个阶段的核心要求：
分析完成后，用简洁的语言总结核心发现，等待用户反馈。用户可能会：
基于 Phase 2-3 的分析结论，开始设计解决方案。
方案设计原则：
在提出方案后，你主动对自己的方案做第一轮 review：
检查清单：
如果发现问题，直接在这个阶段修正，不需要等用户指出。
用户确认方案方向后，做最后一轮 review：
这一轮的目的是从"可以做"提升到"做得好"。
只有在用户明确说"开始执行"、"动手吧"、"搞起来"等指令时才进入这个阶段。
执行时遵循：
每次回复的开头用简洁的方式标注当前阶段，例如：
Phase 2 → 问题审查
或者在阶段转换时：
Phase 2 done → Phase 3：深度分析
这样用户随时知道讨论进行到哪里了。