当用户说"明确问题"、"分析问题"、"探索方案"、"审查方案"、"制定计划"、"执行计划"、"检查验证"、"回顾总结"，或"继续分析"、"深入分析"、"修改方案"、"完善方案"、"优化方案"、"更新计划"、"修订计划"、"修改计划"，或"自动模式"、"自动分析"、"自动解决"时触发。适用于 bug 修复、代码重构、功能开发等需系统性分析的复杂任务。
From open-skillsnpx claudepluginhub fudesign2008/open-skills --plugin open-skillsThis skill uses the workspace's default tool permissions.
Guides Next.js Cache Components and Partial Prerendering (PPR) with cacheComponents enabled. Implements 'use cache', cacheLife(), cacheTag(), revalidateTag(), static/dynamic optimization, and cache debugging.
Migrates code, prompts, and API calls from Claude Sonnet 4.0/4.5 or Opus 4.1 to Opus 4.5, updating model strings on Anthropic, AWS, GCP, Azure platforms.
Generates FastAPI project templates with async routes, dependency injection, Pydantic schemas, repository patterns, middleware, and config for PostgreSQL/MongoDB backends.
七阶段 PDCA 流程，阶段 1～4 只读不写。默认手动模式，说「自动模式」或「自动分析」进入全流程自动执行。
| PDCA | 阶段 | 说明 |
|---|---|---|
| Plan | 阶段 1～4 | 分析问题（含明确问题）、探索方案、审查方案、制定计划 |
| Do | 阶段 5 | 执行计划 |
| Check | 阶段 6 | 检查验证 |
| Act | 阶段 7 | 回顾总结 |
执行完成后进入阶段 6；若阶段 7 结论为「未达标需再改」，可回到「分析问题」、「探索方案」或「审查方案」开启下一轮循环。
/solve-workflow xxx、/solve xxx 等，xxx 为后续内容xxx 不包含上述任一触发词时，默认进入阶段 1（分析问题），将 xxx 视为待分析的问题描述xxx 中包含触发词即视为命中，无需精确匹配相关 skill：perf-workflow（性能专项分析）、jira-fix-workflow（Jira 端到端修复，内置本工作流）
| 说法示例 | 模式 | 说明 |
|---|---|---|
「分析问题」「探索方案」/solve xxx | 👤 手动 | 默认，阶段间需用户确认 |
| 「自动分析 xxx」「自动解决 xxx」「自动模式」 | 🤖 自动 | 全流程自动执行，无需确认 |
模式识别规则：触发词中含「自动」→ 自动模式；其余默认手动模式。运行中可随时说「切换自动模式」或「切换手动模式」切换。👤 手动各阶段停等用户确认；🤖 自动全程推进，仅阶段3超3轮时暂停。各阶段差异详见各阶段内的 [👤]/[🤖] 说明。
| 阶段 | 工具权限 | 👤 手动停止点 | 必须输出 |
|---|---|---|---|
| 1.1 明确问题 | ❌ Read/Grep（例外见1.1正文） | ⛔ 输出后停止，等用户确认 | 问题复述／要素／疑问点 |
| 1.2 技术分析 | ✅ Read/Grep；❌ Edit/Write | 继续进入阶段2 | 存在性结论／根因／影响范围 |
| 2 探索方案 | ✅ Read；❌ Edit/Write | ⛔ 输出方案表后停止，等用户选择 | 方案对比表（≥2个） |
| 3 审查方案 | ✅ Read；❌ Edit/Write | ⛔ 审查报告输出后停止，等用户判定 | 审查报告＋通过/不通过 |
| 4 制定计划 | ✅ Read；❌ Edit/Write/Bash | ⛔ 输出计划后停止，等用户确认 | 文件修改清单＋顺序 |
| 5 执行计划 | ✅ 全部 | 无坑时自动进入阶段6 | 执行报告 |
| 6 检查验证 | ✅ Bash；❌ Edit/Write | ⛔ 输出结果后停止，等用户确认 | 检查结果 |
| 7 回顾总结 | ❌ Edit/Write（除非进入下一轮） | 结束 / 或循环回阶段2/3 | 改进建议 |
各阶段进行中，若当前信息不足以保证输出质量，每次只提出 1 个最关键的问题，待用户回答后再继续（或提下一个问题）。
提问格式：
[题干（一句话说清问题）]
- A 选项一
- B 选项二
简答约定：用户可直接回复「A」「B」等选项字母，AI 解析后继续。
本工作流可在 Claude Code、OpenCode、Cursor 等不同平台运行。每个环境安装的 skill、插件、agent 不同。工作流应主动探索当前环境中可用的增强能力，在合适的阶段自动调用，而非仅依赖自身定义的流程。
工作流启动时（进入阶段1之前），执行一次环境能力扫描。扫描结果记在会话上下文中，后续阶段直接引用，无需重复扫描。
使用当前平台的 skill 发现能力，检查可用的 skill、agent、插件列表：
<available_items> 列表，或使用 skill 工具列出可用 skill扫描时，按以下能力类型关键词匹配可用 skill/agent 的 name 和 description：
| 能力类型 | 匹配关键词 | 对应阶段 | 用途 |
|---|---|---|---|
| 🔍 调试分析 | debug, root-cause, investigate, systematic-debugging | 阶段1（技术分析） | 辅助根因定位、假设驱动调查 |
| 💡 方案设计 | brainstorm, design, architect | 阶段2（探索方案） | 辅助多方案生成与对比 |
| 📋 代码审查 | code-review, review, requesting-review | 阶段3（审查方案） | 辅助方案深度审查 |
| 📝 计划制定 | plan, writing-plan | 阶段4（制定计划） | 辅助生成结构化执行计划 |
| ⚡ 代码执行 | execute, executing-plan, subagent, parallel | 阶段5（执行计划） | 多文件修改的批量编排 |
| 🧪 测试驱动 | test, tdd, test-driven | 阶段5（执行计划） | 先写测试再实现 |
| 🔧 构建修复 | build-fix, build, linter, type-check | 阶段5（执行计划） | 构建/编译/类型错误修复 |
| ✅ 完成验证 | verify, verification, complete | 阶段6（检查验证） | 执行后独立验证 |
⚠️ 本阶段禁止 Edit/Write。仅输出分析结论，不修改任何文件。
原则：先明确问题再技术分析；只读分析为主，不修改实现逻辑
[🤖 自动] 跳过本小节，直接进入 1.2 技术分析，将用户输入视为已确认的问题描述。
[👤 手动] 必须先完成本小节并获用户确认后，才能进入 1.2 技术分析。
工具限制：禁止 Read/Grep/SemanticSearch，以下情况例外：
@文件路径（含可选行号，如 @SKILL.md:83-89）``` 包裹或缩进代码块）例外时：仅读取用户直接引用的文件与行号，不得扩展到其他文件。 读取结果仅用于辅助理解问题，1.1 输出中不得出现技术分析结论。
🔌 若环境探索发现「🔍 调试分析」类能力，在根因分析环节调用（假设驱动调查、证据链构建）。
存在性验证（门控，必须最先执行）
| 结论 | 处理方式 |
|---|---|
| ✅ 问题存在 | 继续执行步骤 1～4 |
| ❌ 问题已不存在 | 报告「在当前代码库中未发现该问题，可能已被修复或逻辑已变更」，附相关代码位置，停止分析，等待用户确认 |
| ⚠️ 描述与代码不符 | 报告「代码行为与描述存在出入」，列出实际发现，回到 1.1 重新对齐问题描述 |
问题现象描述 - 复现条件和步骤
相关代码定位 - 文件路径+行号、关键函数/类
问题根因分析 - 数据流和调用链分析 3.5 行业通病评估（可选，根因明确指向硬限制时触发）
| 结论 | 处理方式 |
|---|---|
| 🚫 行业公认难题，目前无可行解 | 输出【行业通病评估报告】，暂停，等用户决定（继续探索绕过方案 / 接受现状） |
| ⚠️ 存在局限但有绕过方案 | 在后续方案探索中将绕过方案列为候选，继续步骤 4 |
| ✅ 非行业通病，属可修复问题 | 继续步骤 4 |
影响范围评估 - 受影响的模块/功能
工具限制：✅ Read/Grep/SemanticSearch/WebSearch（步骤 3.5 专用）；❌ Edit/Write；❌ Bash 执行改变实现逻辑的命令
1.1 明确问题：
【问题复述】我理解您的问题是：...
（只描述用户的意图与现象，不得出现根因判断或修复建议——技术结论留给 1.2）
【关键要素】目标：... / 约束：... / 背景：... / 期望结果：...
【Scope 拆解】（若适用）模块、依赖、顺序、首个子问题：...
【需要确认的点】（若有，每次只问一个）
[题干] A [...] B [...]
请确认我的理解是否正确。
⛔ [手动模式 — 1.1 出口] 输出以上内容后立即停止，等用户明确确认理解正确后，才能进入 1.2 技术分析。 🤖 [自动模式] 跳过 1.1，直接从 1.2 开始执行。
1.2 技术分析：先报告存在性验证结论，再依次输出现象、定位、根因；若触发步骤3.5，在根因后输出行业通病评估结论；继续输出影响范围。
行业通病评估报告（结论为「无可行解」时输出）：
【行业通病评估】
- 问题本质：...（根因一句话总结）
- 行业现状：...（已知公开记录、主流框架态度、大厂处理方式）
- 调研结论：该问题属于 [平台限制/协议约束/语言特性/标准规范]，业界目前无可行解
- 建议：接受现状 / 评估替代方案（非修复）/ 与产品对齐预期
如需继续探索绕过方案，请说「继续」；否则工作流到此暂停。
违反即违反原则。[👤 手动模式] 必须先完成 1.1 明确问题并获确认，再进入 1.2。[🤖 自动模式] 跳过 1.1 不受此限制。
原则：基于阶段1的分析，提供2-5个解决方案；方案中剔除非必要功能与过度设计（YAGNI）
🔌 若环境探索发现「💡 方案设计」类能力，在方案生成环节调用（多方案生成与对比）。
自动生成 2-5 个方案，AI 自动推荐并选择最优方案（优先：更彻底解决 > 符合最佳实践 > 改善代码质量 > 改动较少），直接进入阶段3审查。
输出方案对比表，等用户选择后进入阶段3审查。
| 方案 | 描述 | 优点 | 缺点 | 复杂度 | 推荐度 |
|---|---|---|---|---|---|
| 方案1 | ... | ... | ... | 低/中/高 | ⭐⭐⭐⭐⭐ |
| 方案2 | ... | ... | ... | 低/中/高 | ⭐⭐⭐ |
工具限制：禁止使用 Edit/Write；可使用 Read 查看代码细节
⛔ [手动模式 — 阶段2 出口] 输出方案对比表后立即停止，等用户选择方案编号后进入阶段3审查。 🤖 [自动模式] 自动选定最优方案，直接进入阶段3审查。
原则：对选定方案进行深度审查，明确其具体内容和风险，再决定是否进入制定计划
🔌 若环境探索发现「📋 代码审查」类能力，在方案审查环节调用（辅助深度审查）。
| 结论 | 判定标准 | 后续动作 |
|---|---|---|
| ✅ 通过 | 四项审查维度均无阻断问题，仅存在可接受的低风险 | 进入阶段4 |
| ❌ 不通过 | 任一维度存在需解决的问题或不可接受的风险 | 进入优化→重新审查循环 |
阻断问题判定指引（满足任一即为 ❌ 不通过）：
非阻断问题（可标注为建议，但不阻止通过）：
方案选定 → 审查（第 N 轮）→ 输出审查报告
↓
审查结论判定
├── ✅ 通过 → 进入阶段4
└── ❌ 不通过 → 方案优化 → 回到审查（第 N+1 轮）
↓
[🤖 自动] 达到循环上限？
├── 否 → 继续循环
└── 是 → 暂停，等用户介入
[🤖 自动] 每轮审查必须输出：
[👤 手动] 输出格式：
【选定方案】方案X：...
【方案解析】核心逻辑：... / 解决有效性：... / 涉及文件与模块：... / 关键实现点：...
【副作用与风险】
- 副作用/风险1：... 影响：... 缓解建议：...
- 副作用/风险2：...
【方案处理建议】建议 修改/完善/优化，理由：...
请确认是否满意，或说「修改方案」「完善方案」「优化方案」进行迭代。
⛔ [手动模式 — 阶段3 出口] 输出审查报告后立即停止，等用户明确说「通过」后进入阶段4；说「修改方案」则进入优化→重新审查循环。 🤖 [自动模式] AI 自动判定通过/不通过；通过进入阶段4，不通过自动优化后重新审查（上限3轮，超限暂停）。
工具限制：禁止使用 Edit/Write；可使用 Read 查看代码细节
原则：详细的、可执行的修改计划，只输出计划文本，不执行代码修改
🔌 若环境探索发现「📝 计划制定」类能力，在计划生成环节调用（结构化执行计划）。
【目标方案回顾】采用方案X：...
【文件修改清单】
1. 文件：xxx/yyy/zzz.js，位置：function abc()，改动：...
2. 文件：xxx/yyy/aaa.js，位置：class DEF.methodXYZ()，改动：...
【修改顺序】1. xxx/yyy/zzz.js（依赖项）→ 2. xxx/yyy/aaa.js（调用方）
【预期影响】范围：... / 风险点：...
工具限制：禁止使用 Edit/Write/Bash 修改代码；可使用 Read 确认细节
⛔ [手动模式 — 阶段4 出口] 输出计划后立即停止，等用户确认计划无误后进入阶段5执行。 🤖 [自动模式] 自动确认，直接进入阶段5。
当用户说「更新计划」「修订计划」「修改计划」时，按本阶段执行，额外标注变更对比和变更原因。
原则：严格按计划执行，完成后确认
🔌 若环境探索发现「🧪 测试驱动」类能力，先写失败测试再实现；「⚡ 代码执行」类能力，批量编排多文件修改；「🔧 构建修复」类能力，在构建失败时调用。
工具权限：✅ 允许使用 Edit/Write/Bash；使用 TodoWrite 跟踪进度
原则：只输出检查结果，不输出改进建议；改进建议在阶段 7（回顾总结）
🔌 若环境探索发现「✅ 完成验证」类能力，在验证环节调用（运行测试、确认修复、检查回归）。
若阶段 4 计划或阶段 5 执行报告涉及测试（如单元测试、集成测试、手动验证步骤）：
npm test、pytest、go test），将结果纳入检查结论【检查结果】
- 阶段1 明确问题小节的期望结果达成情况：...
- 与阶段4 计划对比：已做到 ... / 未做到 ...，原因 ...
- 验证要点/测试结论：...（若已执行测试，附上结果；若未执行，附上需人工测试的提醒）
- 副作用验证：改动是否在其他模块引入了新问题（功能副作用），是否带来性能/安全/可维护性等预期外影响（非功能副作用）
- 逻辑与整体流程审查：...
工具限制：禁止 Edit/Write；✅ 允许 Bash 执行测试命令
⛔ [阶段6 出口] 输出检查结果后立即停止，等用户确认后进入阶段7（或根据结论决定是否需要新一轮修复循环）。
原则：只做总结与建议，不强制改代码；若用户明确要求根据改进点再改，则进入新一轮「制定计划 → 执行计划」；亦可回到「审查方案」重新选定或调整方案。
【改进建议】
- 可固化做法：...
- 建议：进入下一轮 / 收尾。若收尾，遗留与后续改进：...
输出后主动询问：「是否需要生成总结文档？」
工具限制：禁止使用 Edit/Write，除非用户明确要求进入下一轮修改
| 错误 | 后果 | 修正 |
|---|---|---|
| 跳过 1.1 直接读代码 | 误解问题、无效分析 | 手动模式必须先完成明确问题并获确认；自动模式可跳过 1.1 |
| 跳过存在性验证直接进入根因分析 | 分析不存在的问题、浪费上下文 | 1.2 必须以存在性验证为第一步 |
| 存在性验证结论为「不存在/描述不符」但继续分析 | 方向全错 | 立即停止并报告，等待用户确认 |
| 行业通病评估结论为「无可行解」但未暂停等用户确认 | 可能产出无意义方案 | 输出评估报告后暂停，等用户决定是否继续 |
| 评估/审查/制定计划时修改代码 | 破坏只读约束 | 仅用 Read，禁止 Edit/Write |
| 制定计划后未经确认即执行 | 方向偏差 | 手动模式必须等用户确认；自动模式可自动确认 |
| 信息不足时一次抛出多个问题 | 用户认知负担重，答复质量下降 | 每次只问 1 个最关键问题，得到回答后再提下一个 |
| 「用户提了即必要」为由不剔除 | 方案臃肿 | 剔除非必要功能（YAGNI） |
| 审查不通过仍直接进入阶段4 | 带问题的方案进入执行，返工成本高 | 必须循环审查直到通过或达到上限 |
| 自动模式审查循环超过3轮不暂停 | 无限循环浪费资源 | 达到3轮上限必须暂停等用户介入 |
| 审查循环中未记录每轮优化内容 | 审查过程不可追溯 | 每轮审查必须输出完整审查报告 |
| 增强能力探索失败后阻断流程 | 不必要的中断 | 增强能力是可选的，探索失败必须静默跳过 |
| 增强能力突破阶段工具约束 | 只读阶段被写入 | 增强能力不改变阶段工具约束 |