Comet Preset Path: Hotfix

Quick bug fix workflow: open → build → verify → archive. Skip brainstorming and full planning, applicable for behavior fixes and scenarios that do not involve new capability design.

Applicable Conditions (must meet all):

Fix bugs in existing features, no new capability added
No interface changes or architecture adjustments involved
Scope of changes is predictable (usually ≤ 2 files)

Not Applicable: If architecture adjustments are found necessary during the fix, upgrade to the full

/comet

process.

Workflow (preset workflow, 4 phases)

Execution chain: open → build → verify → archive. Hotfix provides default decisions for each phase: streamlined initiation, direct build, scale-based verification, and archiving after verification passes.

Locate the Comet scripts first:

bash

COMET_SEARCH_ROOTS=("." "$HOME/.claude/skills" "$HOME/.codex/skills" "$HOME/.cursor/skills")
COMET_STATE="${COMET_STATE:-$(find "${COMET_SEARCH_ROOTS[@]}" -path '*/comet/scripts/comet-state.sh' -type f -print -quit 2>/dev/null)}"
COMET_GUARD="${COMET_GUARD:-$(find "${COMET_SEARCH_ROOTS[@]}" -path '*/comet/scripts/comet-guard.sh' -type f -print -quit 2>/dev/null)}"
COMET_ARCHIVE="${COMET_ARCHIVE:-$(find "${COMET_SEARCH_ROOTS[@]}" -path '*/comet/scripts/comet-archive.sh' -type f -print -quit 2>/dev/null)}"

1. Streamlined Initiation (preset open)

Reuse Comet's open capability to create a change, but use hotfix defaults: skip the long

openspec-explore

exploration and directly proceed to streamlined change creation.

Execute immediately: Use the Skill tool to load the

openspec-new-change

skill. Skipping this step is prohibited.

After loading the skill, follow its guidance to create streamlined deliverables:

```
proposal.md
```
— Problem description + root cause analysis + repair objectives (no solution comparison needed)
```
design.md
```
— Repair solution (only 1 required, no multi-solution comparison needed)
```
tasks.md
```
— Repair task list
No delta spec required (unless the fix changes acceptance scenarios of existing specs)

Initialize the Comet state file:

bash

bash "$COMET_STATE" init <name> hotfix

Verify the state after initialization:

bash

bash "$COMET_STATE" check <name> open

Complete the open → build transition with phase guard:

bash

bash "$COMET_GUARD" <change-name> open --apply

2. Direct Build (preset build)

Use hotfix default:

build_mode: direct

. Skip

superpowers:brainstorming

and

superpowers:writing-plans

(unless there are >3 tasks; if more than 3 tasks, switch to the plan and execution method selection of

/comet-build

Before continuing or starting modifications, handle uncommitted changes according to the

comet/reference/dirty-worktree.md

protocol. If the repair scope exceeds hotfix limits after attribution, follow the "Upgrade Conditions" in this document.

Execute immediately: Perform tasks one by one according to tasks.md:

Read
```
openspec/changes/<name>/tasks.md
```
to get the list of unfinished tasks
For each unfinished task:
- Modify code according to the task description
- Run the project formatting command (e.g.,
```
mvn spotless:apply
```
  ,
```
npm run format
```
  , etc.)
- Run relevant tests to confirm passing
- Check the corresponding
```
- [ ]
```
  to
```
- [x]
```
  in tasks.md
- Commit code with the format:
```
fix: <brief description of the fix>
```
After all tasks are completed, explicitly run relevant project tests and build commands

If the fix affects acceptance scenarios of existing specs:

Create a delta spec in

openspec/changes/<name>/specs/<capability>/spec.md

Include only the
```
## MODIFIED Requirements
```
section

3. Root Cause Elimination Check

Execute before running build guard to ensure the fix truly eliminates the root cause:

Read the bug description and root cause in proposal.md
Search and verify that the problematic code no longer exists
If the root cause is not eliminated, return to Step 2 to continue the fix (still in the build phase, no need to roll back state)

Upgrade Conditions:

Deep architectural issues found during root cause elimination check → Stop hotfix, handle according to upgrade condition blocking confirmation
Additional interface changes required for the fix → Stop hotfix, handle according to upgrade condition blocking confirmation

After confirming the root cause is eliminated, run the phase guard to complete the build → verify transition:

bash

bash "$COMET_GUARD" <change-name> build --apply

The state file will be automatically updated to

phase: verify

verify_result: pending

, then enter verification.

4. Verification (preset verify)

Reuse

/comet-verify

, where comet-verify's scale assessment determines lightweight or full verification.

Execute immediately: Use the Skill tool to load the

comet-verify

skill. Skipping this step is prohibited.

Small-scale hotfixes without delta specs usually meet lightweight verification conditions (≤3 tasks, ≤2 files), and comet-verify's scale assessment will select the lightweight verification path (5 quick checks). If the hotfix creates a delta spec, enter the full verification path according to comet-verify's scale assessment rules.

After verification passes, record

verify_result: pass

.comet.yaml

according to

/comet-verify

rules; this state cannot be skipped before archiving.

4. Archiving (preset archive)

Reuse

/comet-archive

. Before archiving,

.comet.yaml

must have

verify_result: pass

Execute immediately: Use the Skill tool to load the

comet-archive

skill for archiving. Skipping this step is prohibited. If there is a delta spec, sync it to the main spec according to comet-archive rules, and handle archiving annotations for associated Design Docs and Plans.

Continuous Execution Mode

<IMPORTANT> The Hotfix process is **one-time continuous execution**. After calling `/comet-hotfix`, the agent automatically advances between hotfix's own steps without actively pausing. However, pause and wait for user confirmation in the following cases:

Encountering upgrade conditions (see "Upgrade Conditions" section)
Switching to
```
/comet-build
```
when there are more than 3 tasks (workspace isolation and execution method selection)
Verification failure decisions and branch handling decisions in the verification phase (comet-verify)

Execution sequence: Streamlined Initiation → Direct Build → Verification → Archiving → Completion

Immediately proceed to the next phase after completing each phase. Corresponding Comet/OpenSpec/Superpowers skills must still be called as required within each phase; if the called skill has its own user decision points, follow that skill's rules. </IMPORTANT>

Upgrade Conditions

Stop the hotfix process and upgrade to full

/comet

if any of the following conditions are met:

Condition	Description
Changes involve 3+ files	Exceeds single-point repair scope
Architecture changes	New modules, new interfaces, new dependencies
Database schema changes	Structural adjustments
Introducing new public API	The fix creates a new external interface
Repair scope exceeds a single function/module	Requires coordinated modifications in multiple places

When upgrade conditions are met, pause and wait for explicit user confirmation to upgrade to the full

/comet

process. Do not directly enter

/comet-design

or automatically supplement Design Docs.

After user confirms the upgrade, must update the workflow field first before entering the full process:

bash

bash "$COMET_STATE" set <name> workflow full

Then supplement the Design Doc based on the current change: Immediately use the Skill tool to load the
comet-design
skill, then proceed with the full process normally. If the user does not confirm the upgrade, stop the hotfix and report that the current change exceeds the applicable scope of hotfix.

Exit Conditions

Bug has been fixed and tests passed
Change has been archived
If there are spec changes, they have been synced to the main spec

Phase Guards: Run

bash "$COMET_GUARD" <change-name> build --apply

before build → verify, and run

bash "$COMET_GUARD" <change-name> verify --apply

before verify → archive according to

/comet-verify

rules

comet-hotfix

NPX Install

Tags

SKILL.md Content (Chinese)

Comet Preset Path: Hotfix

Workflow (preset workflow, 4 phases)

1. Streamlined Initiation (preset open)

2. Direct Build (preset build)

3. Root Cause Elimination Check

4. Verification (preset verify)

4. Archiving (preset archive)

Continuous Execution Mode

Upgrade Conditions

Exit Conditions