用途：面向“修 bug 而非加功能”的场景，用结构化 spec 流程约束缺陷修复。适合 bug 不易直接定位、需先做根因分析、修复范围必须可控，或需要沉淀修复文档的情况。不适用于新功能、重构、架构升级、有意改变现有产品行为、仅改文案格式注释或依赖版本，以及过于简单可直接修复的 bug。
主要能力：分三步产出文档。1）Bugfix Analysis：先写 bugfix.md，必填 Current Behavior (Defect)、Expected Behavior (Correct)，必要时补 Unchanged Behavior (Regression Prevention)，写法接近 EARS，如 WHEN [条件] THEN the system [错误行为]、WHEN [条件] THEN the system SHALL [正确行为]、WHEN [条件] THEN the system SHALL CONTINUE TO [必须保持的行为]；按需补充复现条件、输入边界或前置条件、受影响模块、不希望被修改的代码或行为、assets/ 引用。2）Design：边界明确后写 design.md，必填根因是什么、根因如何验证、最小修复面在哪里；按需补充需测试证明的 Unchanged Behavior、支撑根因判断的 assets/ 资料；多方案时优先比较改动面、回归风险及对现有 API/UI/状态机的影响。3）Tasks（可选）：tasks.md 任务须覆盖 bug 确实存在、bug 已被修复，以及相邻行为风险下的未受影响场景仍正常；优先自动化测试，无法自动化则写清手工验证步骤与观察点。
归档约定：默认归档到 .cursor/skills/bugfix-workflow/archives/<bug-id>/ 下的 bugfix.md、design.md、tasks.md 与 assets/。<bug-id> 用唯一、简短、语义明确的 kebab-case，命名聚焦缺陷本身，优先“受影响对象 + 错误行为”；用户指定归档名或路径时遵从用户；临时分析且用户明确不归档可跳过。截图、日志、复现 HTML、代码片段、diff 摘录等默认放入 assets/，文档优先引用归档内 assets/。只归档与当前缺陷直接相关的资料。默认不读取历史归档，仅当用户明确要求、当前 bug 与某归档高度相似或需比对回归来源时，才读取最相关的少量归档。
执行要求与硬规则：先确认 bug 范围，再写文档，再改代码；有辅助资料先整理到 archives/<bug-id>/assets/ 并统一命名；实施后运行最小必要测试集，存在相邻行为风险时覆盖相邻不变场景；汇报时明确根因、改动边界、新增或更新的测试及仍未验证的风险。不要把猜测的根因写成既定事实，先标注证据；不要用泛泛的“优化”替代 bugfix；不要顺手重构无关模块，除非修复本身被其阻塞。模板见 bugfix-template.md、design-template.md、tasks-template.md。