
Comet Classic
FreeStreamline your dual-star development workflow.
Free · Opens the source repo
What Comet Classic does
Comet Classic is designed to facilitate a dual-star development workflow that integrates OpenSpec and Superpowers, allowing developers to manage their project lifecycle effectively. This skill is invoked using the /comet-classic command, which can start or resume a development change. The workflow emphasizes the importance of brainstorming and thorough design before making changes, ensuring that every alteration is well thought out, except for minor hotfixes and tweaks.
To use Comet Classic, developers must follow specific guidelines outlined in the classic-layout.md file. This includes utilizing the OpenSpec CLI through the provided adapter and adhering to the logical file paths defined by the <classic-*> protocol. The skill operates by first discovering active changes and resolving user intent through a structured process that includes automatic phase detection and intent recognition. This ensures that the right actions are taken based on the current state of the project and user requests.
The workflow is structured into distinct phases, allowing for clear decision-making and context management. Developers can easily navigate between different changes, ensuring that they are working on the correct task without losing track of the overall project state. The integration of a CometIntentFrame helps in recognizing user requests and directing them to the appropriate commands, whether that be to create a new change or to resume an existing one. This structured approach minimizes the risk of confusion and maximizes productivity in development tasks.
Comet Classic is particularly useful for teams or individuals engaged in complex development projects where multiple changes may be active simultaneously. By utilizing this skill, users can maintain clarity and focus, ensuring that their workflow remains efficient and organized throughout the development process.
When to use it
Use this skill when you need to manage complex development tasks involving multiple changes and require a structured approach to project lifecycle management.
When not to use it
This skill may not be suitable for simple projects or one-off tasks that do not require extensive planning or collaboration.
What you can build with it
Managing Multiple Changes
Use Comet Classic to efficiently handle multiple active changes in a large development project.
Resuming Work on a Project
Invoke Comet Classic to resume work on an existing change without losing context.
Collaborative Development
Utilize Comet Classic in a team setting to maintain clarity and organization across various tasks.
How to install Comet Classic
View source1. Install with the skills CLI
npx skills add rpamis/comet/comet-classic --agent claude-code2. Or install it manually
Download the skill folder and drop it into ~/.claude/skills/ for all projects, or .claude/skills/ to scope it to one repo. Restart Claude Code so it picks up the new skill.
Anthropic's agentic coding CLI, and the reference implementation of Agent Skills. Drop a skill folder into ~/.claude/skills and Claude Code loads it automatically whenever a task matches the skill's description. Claude Code docs
Inside SKILL.md
Written by rpamisComet Classic — OpenSpec + Superpowers Dual-Star Development Workflow
Before starting or recovering, read and follow comet-classic/reference/classic-layout.md. Every OpenSpec CLI call in this file must use the adapter, and every file path must use the <classic-*> logical roots bound by that protocol.
OpenSpec and Superpowers orbit the same goal like a binary star system.
OpenSpec handles WHAT — outline, proposal, spec lifecycle, archive
Superpowers handles HOW — technical design, planning, execution, closing
Core principle: brainstorming cannot be skipped. Every change must undergo deep design (except hotfix and tweak presets).
Decision Core
Agents need only read this section for decision-making. Refer to the Reference Appendix as needed.
Output Language Rule
Use the configured Comet artifact language as the output language for every OpenSpec and Superpowers artifact. The configured value is a normalized language id, en or zh-CN. For an existing change, read language from <classic-change-dir>/.comet.yaml using comet state get <name> language. Before .comet.yaml exists, read classic.language from project .comet/config.yaml, then fall back to global ~/.comet/config.yaml; if neither exists, fall back to the current user request language. Include the resolved language explicitly in every prompt or ARGUMENTS passed to external OpenSpec/Superpowers skills.
Automatic Phase Detection
Step 0: Active Change Discovery and Intent Resolution
- First follow
comet-classic/reference/scripts.mdand run the publiccometCLI command directly. - Run
comet classic openspec -- list --jsonto collect active changes. - Fill a
CometIntentFramefrom the user request, active change list, and necessary repository state. - Prefer
comet classic intent route --stdinto pass the frame JSON and get the runtime-normalized route.CometIntentFrame + runtime scoreris the source of truth; this prose is only for intent recognition slot extraction. - Handle the runtime route:
hotfix→ invoke/comet-hotfixtweak→ invoke/comet-tweakfull→ follow the active-change table to invoke/comet-openor ask for confirmationresume→ continue to Step 1 and read the selected change.comet.yamlask_user→ pause throughcomet-classic/reference/decision-point.mdand wait for the user's choiceout_of_scope→ explain that the input is not a Comet workflow start/resume request and do not initialize a change
After the runtime route, Ambient Resume, or user choice resolves one explicit change, bind the current execution context before entering its phase Skill:
comet state select <change-name>
When multiple active changes exist and the user has not selected one, do not bind early; keep the existing ask_user decision point.
Comet Ambient Resume
When the user did not explicitly invoke /comet-classic, but this repository may already have an active Comet change, run the read-only probe before starting work that may need code changes or investigation:
comet resume-probe . --stdin --json
The probe only reads repository state. Follow the returned action:
auto_resume: print one line,[COMET] Detected active change <name>; resuming via <nextCommand>., then enternextCommand.ask_user: ask one short question and wait.out_of_scopeornone: do not enter the Comet workflow.
Never attach unrelated work to an active Comet change only because .comet.yaml exists.
Minimal CometIntentFrame Skeleton:
{
"schema_version": "comet.intent.v1",
"utterance": "<user request>",
"intent": { "name": "start_change", "confidence": 0.8 },
"slots": {
"requested_action": "start",
"workflow_candidate": "full",
"user_explicit_workflow": null,
"change_id": null,
"existing_behavior": null,
"new_capability": null,
"public_api_change": null,
"schema_change": null,
"cross_module_change": null
},
"context": {
"active_changes_count": 0,
"active_change_names": []
},
"evidence": [],
"proposed_route": {
"name": "ask_user",
"confidence": 0.5
}
}
Intent Recognition Slot Extraction:
See comet-classic/reference/intent-frame.md for complete field meanings; normal routing only needs the minimal skeleton above.
fix_bug+existing_behavior: true+ no new capability/public API/schema/cross-module signal → preferhotfix- User explicitly describes a lightweight/medium change that can fit in a single OpenSpec change, should be executed through OpenSpec apply, and does not need full
/comet-classicdeep design/plan → prefertweak - Copy, config, docs, prompt, or a lightweight/medium single OpenSpec change → prefer
tweak - New capability, public API, schema change, cross-module coordination, or architecture work → prefer
full - Multiple active changes without an explicit change →
ask_user - Low confidence, missing key evidence, or explicit workflow conflicting with risk signals →
ask_user
| Active changes | User input | Behavior |
|---|---|---|
| None | full route | → Invoke /comet-open |
| Exactly 1 | /comet-classic <description> | → Ask: continue this change or create a new change |
| Multiple | /comet-classic <description> | → Ask: continue existing or create new; if continuing, list changes for selection |
| Exactly 1 | /comet-classic with no description | → Auto-select, enter Step 1 |
| Multiple | /comet-classic with no description | → List changes for user selection |
Step 1: Read .comet.yaml state metadata
Prefer reading <classic-change-dir>/.comet.yaml. If not available, fall back to comet classic openspec -- status --change "<name>" --json, <classic-change-dir>/tasks.md, and <classic-superpowers-root>/ file checks.
Resume rules:
- On every context resume, rerun Step 0 and Step 1; do not trust conversation history for phase detection
- If there is an active change and the worktree has uncommitted changes, handle them through
comet-classic/reference/dirty-worktree.md. That protocol defines checks, attribution, and prohibitions; this file does not repeat them - If
phase: build, first checkbuild_pause,plan,isolation,build_mode,tdd_mode, andreview_mode(see details below):- If
build_pause: plan-readybutisolation,build_mode,tdd_mode, andreview_modeare all already set, treat as stale pause: first output[COMET] Detected stale pause (build_pause=plan-ready but isolation/build_mode/tdd_mode/review_mode are set), auto-clearing and continuing, then runcomet state set <name> build_pause null, then read the next unchecked task from tasks.md and resume execution perbuild_mode - If
build_pause: plan-readyand the plan file exists, butisolation,build_mode,tdd_mode, orreview_modeis not yet set, return to the/comet-buildplan-ready resume point, prompt the user to complete/confirm workspace isolation, execution method, TDD mode, and code review mode, and do not regenerate the plan - If
build_pause: plan-readybut the plan file is missing, return to/comet-buildto handle corrupted state or regenerate the plan - If
isolation,build_mode,tdd_mode, orreview_modeis unset, return to the corresponding/comet-buildstep to supplement before executing - If all are set, read the next unchecked task from tasks.md and continue:
- If
build_mode: subagent-driven-development, do not execute tasks directly in the main window; return to/comet-build's background subagent dispatch rules, main window only coordinates - Other execution modes follow
/comet-build's corresponding rules
- If
- If
- If
verify_result: fail, readverify_failures. At 3 or fewer failures, invoke/comet-builddirectly to continue the recorded repair loop without re-asking. Above the automatic limit, return to/comet-verifyfor the exception decision. User input is required only to accept a WARNING/SUGGESTION deviation or choose a strategy after the retry limit - If
phase: openbut OpenSpecapplyRequiresis complete, runcomet guard <change-name> open --applyto repair state, then continue detection - If
phase: archive, only invoke/comet-archive; confirm first, archive, commit exact archive paths, then handle the branch and run the archive guard
Step 2: Phase Determination (check in order, first match wins)
archived: trueor change moved to archive → Workflow completeverify_result: passandarchivedis nottrue→ Invoke/comet-archive(first perform final archive confirmation)verify_result: fail→ Invoke/comet-buildautomatically to continue repair. Ifverify_failuresexceeds the automatic limit, enter/comet-verify's retry-limit strategy decisionphase: verifyor tasks.md all checked → Invoke/comet-verifyphase: buildor has Design Doc but plan/execution incomplete → Route by workflow:hotfix→/comet-hotfix,tweak→/comet-tweak,full→/comet-buildphase: designor has change but no Design Doc → Invoke/comet-designphase: openor active change exists but.comet.yamlis missing → Invoke/comet-open- No active change → Invoke
/comet-open
If metadata conflicts with file state, use verifiable file state as source of truth and correct .comet.yaml before continuing.
Preset Upgrade Assessment
hotfix/tweak scope assessment uses a three-layer division of labor, avoiding "using pure file count as a hard upgrade condition" that wrongly blocks normal small changes:
- Qualitative-change signals (agent semantic recognition; hitting any one pauses and delegates a two-choice decision to the user): cross-module coordinated change, new capability needed, database schema change, introduces new public API, hits deep architecture issues (each preset reuses this core signal set and may add its own context-specific signal, such as tweak's "needing to split into multiple OpenSpec changes")
- File-count tripwire (user decides; not an automatic upgrade): when changed files exceed a hint threshold, pause and let the user decide whether to continue the preset or upgrade to full; do not auto-kick
- Verification weight (scale script decides):
comet state scaleonly decidesverify_mode(verification weight); it does not block the flow or trigger an upgrade
Upgrade decision point (user chooses one of two):
- Continue the preset lightweight flow (user confirms scope is manageable)
- Upgrade to full
/comet-classic(usecomet state transition <name> preset-escalateto legally rewind to design and clear preset-only build settings; after the Design Doc, choose the full workflow configuration again in one joint decision)
See the "Upgrade Assessment" section of each comet-hotfix / comet-tweak for detailed rules.
Error Handling Quick Reference
| Scenario | Handling |
|---|---|
comet classic openspec -- list --json fails | Check whether OpenSpec is installed; if the artifact root is missing or damaged, prompt the user to run comet update --scope project or rerun comet init --scope project |
| Sub-skill unavailable | Stop workflow, prompt to install or enable the corresponding skill |
.comet.yaml missing | Enter the relevant preset's /comet-open initialization, then run comet state select; never skip initialization |
.comet.yaml malformed | Stop and report the parse error; repair from version control, backup, or verifiable artifacts, never overwrite it with comet state set |
| Build/test fails | Return to build phase for fixes, do not enter verify |
| Incomplete change directory structure | Fill missing files according to comet-open artifact requirements |
Phase Transitions
<IMPORTANT> A single `/comet-classic` invocation starts from the detected phase and advances to the next phase when exit conditions are met.Flow chain: open → design → build → verify → archive
Continuous execution requirement: starting from the detected phase, the agent automatically continues through all later phases. But auto-advancing only applies at transition points without user decisions. When encountering user decision points, pause, present clear options, and wait for the user's explicit response. Must not use recommendation rules, defaults, or historical preferences to substitute for user confirmation, and must not just output a text prompt and then continue executing.
Distinguish phase advancement vs automatic handoff: each sub-skill runs phase guard --apply before exit to advance the .comet.yaml phase field. This step always happens and is not controlled by auto_transition. After that, the sub-skill runs comet state next <name> to resolve the next action: when auto_transition is not false, output is NEXT: auto (auto-invoke next skill); when auto_transition is false, output is NEXT: manual (do not invoke next skill; return control with HINT). NEXT: manual is not a user decision point and must not ask whether to continue. Therefore auto_transition only controls next skill invocation, not phase advancement. Regardless of auto_transition, genuine user decision points below remain blocking.
Decision points are blocking points: whenever reaching any of the following nodes, the current /comet-classic invocation must stop, and follow the comet-classic/reference/decision-point.md protocol to obtain the user's explicit choice. Only after the user explicitly chooses can the corresponding state fields be written and operations executed, then auto-advance resumes.
Nodes requiring user participation (pause only at these nodes):
- Workflow target selection: multiple active changes, continue an existing change versus create a new one, or choose which completed batch item starts first
- Open-phase final proposal/design/tasks review, including the change name and scope; clear requests have no pre-artifact summary/name confirmation
- Confirm the design approach during brainstorming
- One joint build decision: plan-ready pause or all workflow settings (workspace isolation + execution method + TDD mode + code review mode, plus branch name when branch is selected)
- Verify-phase acceptance of WARNING/SUGGESTION deviations, Spec drift handling, or continue/stop after the 4th failure; the first 3 clearly repairable failures close automatically
- Archive phase final confirmation before running the archive script
- Choose finishing-branch handling after exact archive changes are committed
- Encounter an upgrade-assessment signal (hotfix/tweak → user chooses one of two: continue preset / upgrade to full workflow)
- Build phase scope expansion requiring redesign or new change split
- Open phase large PRD split confirmation
Agents should not skip these decision points; other unambiguous phase transitions must proceed automatically, must not exit midway. At decision points, must not skip user confirmation or choose automatically — ask clear options and wait for the user's explicit choice before continuing.
Red Flags — when these thoughts appear, STOP and check:
| Agent Thought | Actual Risk |
|---|---|
| "The user would probably agree with this approach" | Cannot decide for the user — present the choice and wait for the reply |
| "This is a small change, confirmation isn't needed" | Decision points have no size exception — blocking points must wait |
| "The user chose A last time, so A again" | Historical preference cannot substitute for current confirmation |
| "I explained the plan and the user didn't object" | No objection ≠ consent — must use tool to get explicit choice |
| "The flow has reached this point, should be fine" | Verification not passed ≠ passed — check verify_result |
Subcommand Quick Reference
| Command | Phase | Owner | Artifacts |
|---|---|---|---|
/comet-open | 1. Open | OpenSpec | proposal.md, design.md, tasks.md |
/comet-design | 2. Deep Design | Superpowers | Design Doc, delta spec |
/comet-build | 3. Plan and Build | Superpowers | Implementation plan, code commits |
/comet-verify | 4. Verify | Both | Verification report |
/comet-archive | 5. Archive and Close | OpenSpec | delta→main spec sync, design doc markup, archive commit, branch handling |
/comet-hotfix | Preset path | Both | Quick fix (skip brainstorming) |
/comet-tweak | Preset path | Both | OpenSpec-chained medium change (delta spec is first-class, skip brainstorming and full plan) |
/comet-classic
↓ Auto-detect
/comet-open ──→ /comet-design ──→ /comet-build ──→ /comet-verify ──→ /comet-archive
(OpenSpec) (Superpowers) (Superpowers) (Both) (OpenSpec)
/comet-hotfix (preset, skip brainstorming)
open ──→ build ──→ verify ──→ archive
↑ Upgrade-assessment signal hit → user chooses one of two (continue preset / upgrade full) → if upgrade, transition preset-escalate → supplement Design Doc → return to full workflow
/comet-tweak (lightweight preset, chains OpenSpec, delta spec is first-class)
open ──→ build ──→ verify ──→ archive
↑ Upgrade-assessment signal hit → user chooses one of two (continue preset / upgrade full) → if upgrade, transition preset-escalate → supplement Design Doc → return to full workflow
Reference Appendix
State Machine Hard Constraints
- Before full-workflow
build → verify,isolationmust bebranchorworktree; hotfix/tweak may truthfully usecurrent - Before
build → verify,build_modemust be selected build_mode: subagent-driven-developmentmust also havesubagent_dispatch: confirmed- Before full workflow leaves build phase,
tdd_modemust be selected astddordirect - Before full workflow leaves build phase,
review_modemust be selected asoff,standard, orthorough build_mode: directis allowed by default only forhotfix/tweak; full workflow requiresdirect_override: truebuild_pauseis not an execution method and must not be written tobuild_mode- These constraints are enforced by both
comet guard <name> build --applyandcomet state transition <name> build-complete
.comet.yaml Field Reference
See comet-classic/reference/comet-yaml-fields.md for complete field reference with examples and descriptions.
File Structure
See comet-classic/reference/file-structure.md for the complete directory layout and artifact organization.
Auto-Transition Protocol
See comet-classic/reference/auto-transition.md for the complete automatic handoff workflow.
Context Recovery
See comet-classic/reference/context-recovery.md for structured recovery after context compression.
Decision Point Protocol
See comet-classic/reference/decision-point.md for the complete user decision point protocol.
Debug Gate Protocol
See comet-classic/reference/debug-gate.md for the complete debug gate protocol.
Public CLI
Follow comet-classic/reference/scripts.md once per session and use only the public comet CLI. Do not search for or invoke internal bundles. Key entry points:
comet guard <change-name> <phase> --apply # phase guard + state update
comet state transition <change-name> <event> # open-complete | design-complete | build-complete | verify-pass | verify-fail
comet state next <change-name> # NEXT: auto|manual|done + SKILL: <skill-name>
comet archive <change-name> # full archive in one command
Frequently asked questions about Comet Classic
Similar skills
Spring Boot Testing
Master testing techniques for Spring Boot 4 applications.
GitHub Issues
Manage GitHub issues efficiently with MCP tools.
Geofeed Tuner
Optimize your IP geolocation feeds in CSV format.
Batch Files
Master Windows batch scripting for automation and task management.
Adobe Illustrator Scripting
Automate your Illustrator workflows with ExtendScript.
Plugin Structure
Create and organize Claude Code plugins effectively.
