/comet, which selects Native or Classic from project configuration. After entering Classic Spec mode, you do not need to understand every Engine detail.
Where Skills live
Different Skill sources are discovered by different mechanisms. Project Skills can override built-ins, but invalid overrides fail closed.
Platform Skills are installed into a platform directory and become slash
commands. Project Skills live in
.comet/skills/ and are resolved by
Comet Engine at runtime.Project Skills
A project Skill is a Skill package installed under.comet/skills/<name>/. It belongs to the repository and can be committed to Git.
Discovery priority is explicit path -> project Skill -> built-in Skill. If a project Skill shadows a built-in Skill but fails validation, Engine fails instead of silently falling back. That protects teams from thinking they are using a custom workflow when the built-in one is actually running.
Why use project Skills
Install one with:
Local Skill commands
Built-in classic workflow Skills
These Skills ship with Comet and are installed into platform directories by Classic initialization. Normally, invoke
/comet; when configuration selects Classic, the internal /comet-classic entry detects state and invokes the appropriate phase Skill.
Creating reusable Skills with /comet-any
/comet-any is the user-facing Skill Creator path. It reads project preferences, resolves real local Skill content, presents a confirmation page, then generates a stable Skill Bundle with Skill text, references, scripts, rules, hooks, and evidence.
/comet-classic, create a new Skill, or upgrade an existing Skill.
Classic /comet-classic users do not need to understand Engine internals to use the five-phase workflow.
Next steps
- Workflow concepts — how
/comet-classicconnects the five phases - State and configuration
- Skill and Engine