comet

Use when creating new skills, editing existing skills, or verifying skills work before deployment

Use when you have a spec or requirements for a multi-step task, before touching code

Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always

Use when starting feature work that needs isolation from current workspace or before executing implementation plans - ensures an isolated workspace exists via native tools or git worktree fallback

Use when implementing any feature or bugfix, before writing implementation code

Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes

Use when executing implementation plans with independent tasks in the current session

Use when completing tasks, implementing major features, or before merging to verify work meets requirements

Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation

Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup

Use when you have a written implementation plan to execute in a separate session with review checkpoints

Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies

You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.

Verify implementation matches change artifacts. Use when the user wants to validate that implementation is complete, correct, and coherent before archiving.

Sync delta specs from a change to main specs. Use when the user wants to update main specs with changes from a delta spec, without archiving the change.

Propose a new change with all artifacts generated in one step. Use when the user wants to quickly describe what they want to build and get a complete proposal with design, specs, and tasks ready for implementation.

Guided onboarding for OpenSpec - walk through a complete workflow cycle with narration and real codebase work.

Start a new OpenSpec change using the experimental artifact workflow. Use when the user wants to create a new feature, fix, or modification with a structured step-by-step approach.

Fast-forward through OpenSpec artifact creation. Use when the user wants to quickly create all artifacts needed for implementation without stepping through each one individually.

Enter explore mode - a thinking partner for exploring ideas, investigating problems, and clarifying requirements. Use when the user wants to think through something before or during a change.

Continue working on an OpenSpec change by creating the next artifact. Use when the user wants to progress their change, create the next artifact, or continue their workflow.

Archive multiple completed changes at once. Use when archiving several parallel changes.

Archive a completed change in the experimental workflow. Use when the user wants to finalize and archive a change after implementation is complete.

Implement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks.

Use when 用户要启动或恢复 Comet 工作流，需要根据 active change、.comet.yaml、hotfix/tweak 意图路由到对应阶段 Skill。