CtrlK
BlogDocsLog inGet started
Tessl Logo

comet-hotfix

仅在用户明确调用 /comet-hotfix,或由 Comet 根 Skill/runtime 路由到 hotfix preset 时使用;修复已有行为 bug,不用于普通的未托管 bugfix。

67

Quality

80%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./assets/skills-zh/comet-hotfix/SKILL.md
SKILL.md
Quality
Evals
Security

Comet 预设路径:Hotfix

快速 bug fix 工作流:open → build → verify → archive。跳过 brainstorming 和完整 plan,适用于行为修复、不涉及新 capability 设计的场景。

适用条件(必须全部满足):

  1. 修复已有功能的 bug,不新增 capability
  2. 不涉及接口变更或架构调整
  3. 改动范围可预估(文件数仅作提示,不作为硬性升级条件,见下方升级判定)

不适用:如修复过程命中质变信号(见「升级判定」章节),由用户决定是否升级为完整 /comet-classic 流程。


流程(预设流程,6 步)

0. 输出语言约束

精简版 OpenSpec 产物必须使用 Comet 配置产物语言。.comet.yaml 尚不存在时依次读取项目 .comet/config.yaml 和全局 ~/.comet/config.yamlclassic.language,初始化后使用 comet state get <name> language 读取。

执行链路:open → build → verify → archive。Hotfix 为每个阶段提供默认决策:精简开启、直接构建、按规模验证、验证通过后进入归档前最终确认。

开始前按 comet/reference/scripts.md 定位 Comet 脚本(定位 comet-env.mjs);从任意入口恢复时先按 comet/reference/context-recovery.md 确认 phase/workflow。

恢复已有 hotfix change 时,第一项状态操作必须是 comet state select <change-name>;创建新 change 时,在 .comet.yaml 初始化成功后立即运行该命令,再进入源码写入步骤。

1. 快速开启(预设 open)

复用 Comet open 能力创建 change,但使用 hotfix 默认值:不执行 openspec-explore 长探索,直接进入精简 change 创建。

立即执行: 使用 Skill 工具加载 openspec-new-change 技能。禁止跳过此步骤。

技能加载后先创建 change 骨架,立即初始化可恢复状态并绑定当前 change:

comet state init <name> hotfix
comet state select <name>
comet state check <name> open

若上述 select / check 输出 BLOCKED,且原因是 bound_branch 与当前分支不一致,立即按 comet/reference/decision-point.md 暂停,让用户单选:切回绑定分支后重新运行入口验证,或在用户明确确认当前分支应接管该 change 后运行 comet state rebind <change-name> 并重新入口验证。不得自行切换分支,不得自行换绑。

入口工作区隔离是用户决策点,不再把 current 当作默认隔离模式写入。按 comet/reference/decision-point.md 暂停让用户单选:

  • A. 当前分支直接工作:运行 comet state set <name> isolation current,如实绑定当前分支
  • B. 创建分支:先创建并切换到 hotfix/YYYYMMDD/<change-name>,再运行 comet state set <name> isolation branch
  • C. 创建 worktree:必须先使用 Skill 工具加载 Superpowers using-git-worktrees 技能,由该技能创建隔离工作区;进入 worktree 后运行 comet state set <name> isolation worktree

B/C 完成后,必须在实际执行分支或 worktree 中重新运行:

comet state select <name>

随后按指引创建精简版产物:

  • proposal.md — 问题描述 + 根因分析 + 修复目标(无需方案对比)
  • design.md — 修复方案(1 个即可,无需多方案对比)
  • tasks.md — 修复任务清单
  • 无需 delta spec(除非修复改变了已有 spec 的验收场景)

阶段守卫完成 open → build 过渡:

comet guard <change-name> open --apply

检查 auto_transition 决定是否继续:

comet state next <name>
  • NEXT: auto → 继续 Step 2
  • NEXT: manual → 按 HINT 交还控制权并结束当前调用;不要再询问用户是否继续

2. 直接构建(预设 build)

使用 hotfix 默认值:build_mode: directtdd_mode: directreview_mode: offisolation 必须沿用 Step 1 中用户已确认的入口工作区隔离方式,不得自行改回 currentdirect 表示不进入完整规划/TDD 编排,不表示可以跳过复现、回归测试或验证。跳过 Superpowers brainstormingwriting-plans任务数量本身不触发 /comet-build,任务较多时仍在当前 hotfix 的 tasks.md 中按顺序执行,只有命中后文质变信号或范围 tripwire 才交给用户决定是否升级 full。

继续或开始修改前,按 comet/reference/dirty-worktree.md 协议处理未提交改动。若归因后发现修复命中质变信号或文件数 tripwire,按本文件「升级判定」处理。

修改实现前,必须先复现问题并记录失败证据

  1. 用最小可重复步骤确认用户报告的旧行为确实失败,并记录命令、输入和实际结果
  2. 能自动化时先新增一个会失败的回归测试并实际运行,确认失败原因对应本 bug,而不是环境或测试本身错误
  3. 暂时无法自动化时,在 proposal/验证报告中记录不可自动化原因和可重复的手工失败证据;不得无证据直接改代码

完成 RED 证据后,按 tasks.md 逐个执行任务:

  1. 读取 openspec/changes/<name>/tasks.md,获取未完成任务列表
  2. 对每个未完成任务:
    • 根据任务描述修改代码
    • 运行项目格式化命令(如 mvn spotless:applynpm run format 等)
    • 先运行新增的失败回归测试确认转绿,再运行相关测试确认通过
    • 将 tasks.md 中对应 - [ ] 勾选为 - [x]
    • 提交代码,commit message 格式:fix: <简述修复>
  3. 全部任务完成后,显式运行项目相关测试和构建命令

执行 hotfix 期间,只要运行程序、测试、构建或手动验证时出现崩溃、异常行为、测试失败或构建失败,必须使用 Skill 工具加载 Superpowers systematic-debugging 技能。在完成根因调查前,不得提出或实施源码修复。

具体调查、最小失败测试、修复验证和保持当前 change 验证闭环的要求,按 comet/reference/debug-gate.md 执行。

如修复影响已有 spec 验收场景

  • openspec/changes/<name>/specs/<capability>/spec.md 创建 delta spec
  • 仅包含 ## MODIFIED Requirements 部分

3. 根因消除检查

在运行 build guard 之前执行,确保修复确实消除了问题根因:

  1. 读取 proposal.md 中的 bug 描述和根因
  2. 搜索验证问题代码不再存在
  3. 如根因未消除,回到 Step 2 继续修复(此时仍在 build 阶段,无需状态回退)

升级判定信号

  • 根因消除检查发现深层架构问题 → 命中质变信号,按「升级判定」章节暂停交用户决定
  • 修复需要额外接口变更 → 命中质变信号(引入新的 public API),按「升级判定」章节暂停交用户决定

根因确认消除后,运行阶段守卫完成 build → verify 过渡:

comet guard <change-name> build --apply

状态文件自动更新为 phase: verifyverify_result: pending,然后进入验证。

4. 验证(预设 verify)

复用 /comet-verify,由 comet-verify 的规模评估决定轻量或完整验证。

立即执行: 使用 Skill 工具加载 comet-verify 技能。禁止跳过此步骤。

无 delta spec 的小范围 hotfix 通常满足轻量验证条件(≤ 3 tasks、改动文件数低于 scale 阈值),comet-verify 的规模评估会选择轻量验证路径(6 项快速检查;默认 review_mode: off 时不自动派发代码审查)。若用户希望增加审查,可在验证前运行 comet state set <name> review_mode standardthorough。若 hotfix 创建了 delta spec,则根据 comet-verify 的规模评估规则进入完整验证路径。

验证通过后,按 /comet-verify 的规则将 .comet.yamlverify_result 记录为 pass,归档前不得跳过该状态。验证通过后仍必须进入 /comet-archive 的归档前最终确认,不得自动运行归档脚本。

5. 归档(预设 archive)

复用 /comet-archive。归档前必须满足 .comet.yamlverify_result: pass,并等待 /comet-archive 的归档前最终确认。

立即执行: 使用 Skill 工具加载 comet-archive 技能进行归档。禁止跳过此步骤。 如有 delta spec,按 comet-archive 规则同步到 main spec,并处理关联 Design Doc 与 Plan 的归档标注。


连续执行模式

Hotfix 流程默认 **一次性连续执行**。调用 `/comet-hotfix` 后,agent 在 hotfix 自有步骤间自动推进,不主动停顿。**例外**:若 `auto_transition: false`,则在每个 phase 边界(build/verify/archive 之间)结束当前调用并按 `HINT` 交还控制权,由用户稍后手动运行下一阶段命令;这是手动衔接,不是新的确认点。无论 `auto_transition` 取何值,以下真正的用户决策仍需暂停:
  1. 遇到升级判定信号(见「升级判定」章节),必须使用当前平台可用的用户输入/确认机制暂停并等待用户明确选择:继续 hotfix 流程,还是升级为完整 /comet-classic 流程
  2. 验证阶段(comet-verify)接受 WARNING/SUGGESTION 偏差、处理 Spec 漂移或超过自动修复上限后的策略决策;前 3 次明确可修复失败自动闭环
  3. 归档前最终确认,以及归档提交后的分支处理决策

执行顺序:快速开启 → 直接构建 → 根因消除检查 → 验证 → 归档 → 完成

每个阶段完成后立即进入下一阶段。阶段内部仍必须按上文要求调用对应 Comet/OpenSpec/Superpowers skill,被调用的 skill 如有自己的用户决策点,按该 skill 规则执行。


升级判定

hotfix 的升级判定只决定是否从预设流程转为 full;文件数不自动升级,comet state scale 只决定验证轻重。

若由 /comet-classic 入口传入 intent frame,hotfix 在 build 前只复核 risk_signal 和升级信号:新增 capability、public API、schema 变更、跨模块协调或深层架构问题。命中时进入现有升级决策点;不得重新实现入口意图识别。

持续检查以下质变信号:跨模块协调修改、需要新增 capability、数据库 schema 变更、引入新的 public API、触及深层架构问题(hotfix 语境下多在根因消除检查时暴露)。命中任一信号时,agent 不得自行升级或自行判定可继续

文件数 tripwire 仅作提示:改动文件数超过提示阈值(如 > 4 个文件)时,也交给用户决定继续 hotfix 还是升级 full;文件数多不等于质变。bug 修复通常聚焦在 1-3 个文件,超过阈值说明改动面偏大、值得让用户复核是否仍属预设范围。

命中质变信号或文件数 tripwire 时,必须按 comet/reference/decision-point.md 的协议暂停并等待用户明确选择。不得直接进入 /comet-design,不得自动补充 Design Doc。

用户选择升级(选项 B)后,使用状态机合法的升级通道,单条命令完成预设流程 → full 转换并回退到 design 阶段:

comet state transition <name> preset-escalate

该命令原子地把 workflow/classic_profile 置为 fullphase 回退到 design、清空 design_doc,并清除预设专属的 build_modetdd_modereview_modeisolationverify_mode。然后在当前 change 基础上补充 Design Doc:立即使用 Skill 工具加载 comet-design skill;进入 build 后必须重新进行一次完整的联合工作方式选择。

用户选择继续(选项 A)时,继续 hotfix 流程,并记录用户确认继续的原因。


退出条件

  • Bug 已修复,测试通过
  • change 已归档
  • 如有 spec 变更,已同步到 main spec
  • 阶段守卫:build → verify 前运行 comet guard <change-name> build --apply,verify → archive 前按 /comet-verify 规则运行 comet guard <change-name> verify --apply

自动衔接下一阶段

comet/reference/auto-transition.md 执行。关键命令:

comet state next <name>
  • NEXT: auto → 调用 SKILL 指向的 skill 继续 hotfix 流程(phase: build 返回 comet-hotfixverify 返回 comet-verifyarchive 返回 comet-archive
  • NEXT: manual → 不调用下一 skill,按 HINT 交还控制权并结束当前调用;不再创建确认点
  • NEXT: done → 流程已完成,无需继续
Repository
rpamis/comet
Last updated
First committed

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.