Overview of Skill Creator (Advanced)

When creating, optimizing, or combining Skills, calling /comet-any in the Agent and confirming prompts is enough in most cases. Evaluation, publishing, distribution, and recovery are guided by the flow. Unless you are troubleshooting or building automation integration, you do not need underlying commands, internal state, or package structure first. This page is advanced content. For a fast path, start with Quick Start: Combining Any Skill.

/comet-any is Comet’s Skill creation entry point (also known as Skill Creator). You describe the desired Workflow that reads the real local Skill, compiles the target into a Workflow Contract, and regenerates into a ** verifiable, reviewable, and distributable ** Skill Bundle And hide the back-end complexity (Bundle, Factory, composition, resolved skills) internally.

Core design principles

The key to understanding /comet-any is a ** two-layer separation **

layer	”Content	Who will come into contact with it
”User layer	Three starting points + the adjusted vocabulary of `Retain/Add/Replace/Close` + the responsibility description of each node	All users
”Inner layer	Bundle、Factory、composition、Workflow Protocol、resolved-skills.json	View only during auditing/troubleshooting

The only entry point that users need to remember is /comet-any. When it is necessary to restore the creation state, use comet creator; After entering the release, use comet publish; comet bundle is only reserved as an advanced backend for auditing and troubleshooting.

Main path

/ Comet-any to create → comet eval to verify → comet creator to check status → comet publish and distribute

The expanded sequence is:

Created by /comet-any
→ comet eval --collect / --html (Verification)
comet creator status/next (readiness and the only next step)
→ comet publish review/approve/run
→ comet publish distribute --preview
→ comet publish distribute

comet creator inspects and resumes the /comet-any creation workflow. comet bundle is the advanced Bundle backend. comet skill is a low-level Skill tool, suitable for local debugging and Engine Run. None of them are the main entry points for creating skills on a daily basis.

Three starting points

The user only needs to choose one of the three starting points at the first level. They correspond to three **Skill Creator intents ** (skillCreatorIntent), and the back end compiles each path to the same Workflow Contract:

Starting point (User layer	Skill Creator Intent	Meaning	Typical scenarios
”Five-stage customization based on Comet’s existing Skill.	`customize-comet`	Make incremental adjustments within the protected boundary of `/comet`	Add the `grill-me` requirement clarification Skill to `/comet`
Create a brand-new workflow Skill	`new-skill`	Generate a new workflow-kernel from the target description	Establish a team-specific process
Organize existing skills	`upgrade-existing`	Organize the existing skills into releasable standard packages	Standardize the scattered skills

Workflow Contract: A common model for all paths

No matter which starting point you choose, /comet-any will eventually compile the target into the same Workflow Contract. This is the core concept for understanding the entire Skill Creator:

Concept	Meaning
Workflow Node	Recoverable nodes in the process, such as `open`, `design`, `plan`, `execute`, `review`, `verify`, `archive`
Node Responsibility	The responsibilities of this node in the Agent workflow are to explain why it exists, what it needs to produce, and whether it can be replaced
Skill Binding	The implementation Skill or auxiliary Skill of a certain node
Required Skill Call	It is required that a certain Skill must be called within the node, but the implementation of the node should not be replaced. For example, if `open` is required, `grill-me` must be called to clarify the requirement
Output Schema	The files, statuses or evidence that nodes must produce. Scripts, eval, and readiness only recognize the Output Schema, not the Skill name
Guardrail	Inspections that block or allow the advancement of nodes
Handoff	evidence that must be brought back when a sub-agent or cross-node handover occurs
workflow-protocol.json	The single source of truth for the runtime state of the generated package is read by runtime/eval/review/readiness

Xiaoyu organized the three starting points of new creation, upgrade and combination into the same Workflow Contract template

Whether you start by creating, upgrading, or composing, the result is the same Workflow Contract.

Two types of Workflows

`comet-five-phase-overlay`

Make incremental adjustments based on the classic five-stage framework of Comet. Retain the main process of /comet and the state semantics of .comet.yaml, with 8 built-in nodes.

`workflow-kernel`

Brand-new custom workflow. When declaring nodes, Output Schema, Guardrail and Handoff from zero, the state needs to be redeclared.

Protected boundary: Five-stage customization based on Comet’s existing Skill

When you choose “Five-stage Customization based on Comet’s existing Skill”, /comet is regarded as the “protected boundary”. comet-five-phase-overlay has these 8 built-in nodes:

Node	Duties	Type	Available operations
`open`	Receive the requirements, select the change form, and initialize Comet state	control	`require`、`augment`
`design`	Transform the confirmed requirements into design products and OpenSpec delta	producer	`require`、`augment`、`override`
`plan`	Produce an executable implementation plan	producer	`require`、`augment`、`override`
`execute`	Directly implement the execution plan	control	`require`、`augment`
`subagent-execute`	Appoint a sub-agent to execute and request the return of evidence	handoff	`require`、`augment`
`review`	Check the implementation with the review Skill before verification (optional)	guardrail	`require`、`augment`、`disable`
`verify`	Run verification, harmonize branches, and determine whether it is completed	control	`require`、`augment`
`archive`	Archive OpenSpec changes and synchronize delta	control	`require`、`augment`

There are clear rules in the normal mode:

Rules	Explanation
The control node cannot override	`open`, `execute`, `verify`, and `archive` can only be implemented in `require`/`augment` (for example, when a certain Skill is required to be called), and cannot be replaced
The producer node can be overridden	`design` and `plan` can be implemented interchangeably, but the corresponding Output Schema of `satisfies` must be used
Optional nodes can be disabled	`review` is marked as `optional` and can be turned off
Required Skill Call does not replace implementations	It requires a node to internally invoke a certain Skill, while the implementation Skill of the node itself remains unchanged

Want to replace the control node (open/execute/verify/archive)? Normal mode does not allow it. At this point, you need to switch to the advanced workflow-kernel and re-declare the state, Output Schema, and Guardrail.

8 built-in Output schemas

/comet-any has 8 built-in Output schemas. runtime/eval/readiness determines whether a node meets the standards based on the Schema. Skill names are only used for identification.

Output Schema	Node	Output
`comet.intake.v1`	`open`	Comet state initialization
`comet.design.v1`	`design`	Design document + OpenSpec delta
`comet.plan.v1`	`plan`	Implementation plan + tasks
`comet.execution-evidence.v1`	`execute`	Implement summary + test evidence
`comet.handoff.v1`	`subagent-execute`	Transfer request + return result
`comet.review.v1`	`review`	Review summary (blockers are optional)
`comet.verify.v1`	`verify`	Verification command + verification result
`comet.archive.v1`	`archive`	Archived summary + Archived status

When a producer node performs override, it must declare in satisfies which Output Schema it satisfies. For example, to replace the design implementation, you must satisfies: [“comet.design.v1”], otherwise the verification will report producer-missing-output-schema.

Solution example: Add Gray-Me requirement clarification to /comet

The following plan.json uses Required Skill Call to force the invocation of grill-me on the open node, allowing /comet to clarify the requirements before entering the design - ** without replacing any node implementation ** :

{
  "goal: "Based on the five-stage customization of Comet's existing Skill, add Gray-ME clarification requirements at the open node.",
  "skillCreatorIntent": "customize-comet",
  "workflow": {
    "kind": "comet-five-phase-overlay",
    "name": "comet-with-grill-me",
    ""goal":" In the open node, request to call Grilling-me to clarify the requirements.",
    "nodes": {
      "open": {
        "requiredSkillCalls": [
          {
            "skill": "grill-me",
            "reason: "Clarify the objectives, boundaries, and acceptance criteria before creating the OpenSpec change."
          }
        ]
      }
    }
  }
}

Key point: The implementation Skill of open remains unchanged. It only forces the invocation of the additional Skill within the node and retrievates the clarification evidence through the Output Schema.

Custom Node (workflow-kernel

workflow-kernel allows the declaration of brand new nodes. Each node must define its responsibilities with responsibility and declare the Output Schema and Guardrail:

{
  "id": "delegate-notes",
  "label": "Delegate Notes",
  "kind": "handoff",
  "responsibility": "Delegate release note drafting and require returned evidence.",
  "implementation": { "skill": "handoff-coordinator", "scope": "handoff" },
  "requiredSkillCalls": [
    { "skill": "release-notes", "scope": "handoff" }
  ],
  "operations": ["require", "augment"],
  "outputSchemas": ["release.notes.v1"],
  "guardrails": [
    { "id": "handoff-returned", "label": "Handoff returned evidence", "validation": "semantic" }
  ]
}

What does comet-any do

A complete call to /comet-any will do these things in sequence:

First, try to restore the current creative state; Create only when there is no recoverable state.
Read the preference order in .comet/skill-preferences.yaml (advisory/strict mode).
Use find-skill ** to parse the real Skill content **, including SKILL.md, references, rules, scripts and hooks; The name is only used to locate the candidates.
When dealing with ** missing or ambiguous ** candidates, it is necessary to suspend asking the user.
Compile the target into a Workflow Contract (Workflow Nodes, Skill Bindings, Output Schemas, Guardrails, Handoffs).
** Verify ** Workflow Contract (control cannot override, producer override must satisfy, Output Schema must exist, etc.).
First, display the **Skill Creator Solution Confirmation Page **, and write the draft only after the user’s confirmation.
Generate entry skills, internal skills of each node, reference/workflow-protocol.json, scripts and platform agent definitions through authoring lane.
Generate the comet/eval.yaml evaluation list (including the Engine Package when Engine is enabled).
Check readiness through comet creator status/next, then proceed to review, approval, publish and distribute.

When to use /comet-any

I want to turn the team process into a reusable Skill.
We want to optimize the existing skills to make them evaluable and releasable.
Want to add, replace or close certain links on the basis of the five stages of /comet.
Want to combine multiple skills and ** retain genuine source evidence **.
I want to distribute the products to platforms such as Claude Code and Codex.

/comet-any output

After a complete generation or optimization, the product includes:

<bundle-draft>/
Bundle.yaml # Bundle list
  skills/<entry-skill>/
SKILL.md # The entry point that users actually invoke
    comet/
skill.yaml # Engine Runtime Plan (when Engine is enabled)
guardrails.yaml # Runtime constraints
checks.yaml # runtime check (Runtime)
eval.yaml # Creation Period Evaluation manifest (Pre-release Evidence)
    reference/
Workflow - protocol. Json # single source of truth for runtime state (shared by runtime/eval/review/readiness)
resolved-skills.json # Real Skill Source Evidence + workflow Node Information
composition-report.md # Composition Scheme and Deviation explanation
decision-points.md # Decision Points
Recovery.md # recovery path
skill-review.md # Self-review by the author
authoring-lanes.json # Create Lane Records (including protocolHash)
subagents/ # Portable Sub-Agent Role Description
    scripts/                          # required control plane
      workflow-state.mjs
      workflow-guard.mjs
      workflow-handoff.mjs
      comet-plan.mjs
      comet-check.mjs
      comet-hook-guard.mjs
agents/claude/ # Claude Code custom agents (distributed when supported by the target platform)
  rules/                              # required control plane
  hooks/                              # required control plane（portable hook descriptor）

Responsibilities of key documents

”File	Life cycle	Duties
`SKILL.md`	Creation period + runtime period	The entry point that the user actually invokes
`reference/workflow-protocol.json`	Creation period + runtime period	Single source of truth for runtime state : node, edge, Output Schema, state, evals
`reference/resolved-skills.json`	Creation period	Real Skill source, hash, workflow node binding, preference evidence
`reference/composition-report.md`	Creation period	Combination scheme, deviation explanation, risk and review evidence
`comet/skill.yaml`	Operating period	Internal operation plans (goals, orchestration, steps) are not handwritten entry points by users
`comet/guardrails.yaml`	Operating period	Constraints generated by preferences and risk strategies (allowed lists, budgets)
`comet/checks.yaml`	Operating period	runtime check（progress/step/completion）
`comet/eval.yaml`	Creation period	Eval manifest (input for `comet eval`)

workflow-protocol.json is the core. runtime, eval, review, and publish readiness all read this protocol to ensure that “validation at creation time” and “recovery at runtime” point to the same fact.

required capability set

The required capability set of the stable combination Skill Bundle is skills/scripts/rules/hooks/references/agents:

skills: Entry Skill and internal Skill of each node.
scripts/rules/hooks: required control plane, not an appendage file that can be deleted at will. They handle state advancement, guards, and handovers deterministically.
references: Genuine source evidence and creation audit.
agents: Native agent definition of the platform. Claude Code distribution writes the generated custom agents to the target platform preview.

hooks/*.yaml is the Comet portable hook descriptor, and it will only take effect after being compiled to the target platform configuration through comet publish distribute.

/comet-any should not be used as the user’s main process for manual comet bundle commands. Bundle is a deterministic backend for internal use that /comet-any calls automatically.

hard gates

/comet-any has several uncompromising hard rules. Understanding them can help you avoid falling into traps:

The user only invokes this Skill, and the CLI is the internal backend.
It is necessary to ** parse the real Skill with find-skill **, and it is not allowed to infer the ability merely by name.
Missing or ambiguous candidates must be paused. Ask the user and never silently ignore or select for the user.
The confirmation page of the proposal must be displayed first. Only after the user’s confirmation can the draft be written.
Required Skill Call ** does not replace ** node implementations.
producer override must declare the Output Schema of satisfies.
The normal mode of the control node cannot override.
eval, review, and publish readiness must read ** the same workflow-protocol.json.
The products must not retain the AUTHORING PENDING mark. If the entry Decision Core or substance node is not completed, the release will be blocked.
The sub-agent Handoff must require the sub-agent to load the Required Skill Call and return the evidence.
The script only reads the protocol and state, and does not take the Skill name as the verification basis.
“Eval skipped or failed → Never enter ready.”
“Lack of manual approval → Never ready.”
“preview is necessary before distribution. Only after user confirmation can it be written.”
Before installation, the user must be consulted. Automatic installation is not allowed.

validation findings code

/comet-any will verify when compiling the Workflow Contract. If it fails, a clear finding code will be given:

finding code	Meaning
`unknown-node`	The patch references the node where the current kind does not exist
`unsupported-operation`	The node does not support this operation (for example, overriding the control node).
`control-node-override`	The normal mode of the control node is overridden
`producer-missing-output-schema`	producer override does not declare the Output Schema of satisfies
`missing-output-schema`	The node references an undefined Output Schema
`orphan-output-schema`	The Output Schema has been defined, but it has not been attached to any Workflow Node
`duplicate-node`	Nodes with the same id were repeatedly defined
`disabled-required-node`	Required nodes are disabled (only optional nodes can be disabled)

Next step

The complete process of creating a Skill ](/en/skill-creator/workflow) - from preparing preferences to generation, evaluation, release, and distribution
Skill Preferences and Real sources - Configuration .comet/skill-preferences.yaml
publish and distribute Skill](/en/skill-creator/publishing) - readiness, approval, publish and distribute
Skill and Engine](/en/skill-creator/engine) - Skill package structure and Engine runtime
Overview of the Evaluation System ](/en/eval/overview)-Eval: How Does eval Provide Evidence for Release

Quickstart

Advanced

Related commands

Overview of Skill Creator (Advanced)

Core design principles

Main path

Three starting points

Workflow Contract: A common model for all paths

Two types of Workflows

`comet-five-phase-overlay`

`workflow-kernel`

Protected boundary: Five-stage customization based on Comet’s existing Skill

8 built-in Output schemas

Solution example: Add Gray-Me requirement clarification to /comet

Custom Node (workflow-kernel

What does comet-any do

When to use /comet-any

/comet-any output

Responsibilities of key documents

required capability set

hard gates

validation findings code

Next step

​Core design principles

​Main path

​Three starting points

​Workflow Contract: A common model for all paths

​Two types of Workflows

​comet-five-phase-overlay

​workflow-kernel

​Protected boundary: Five-stage customization based on Comet’s existing Skill

​8 built-in Output schemas

​Solution example: Add Gray-Me requirement clarification to /comet

​Custom Node (workflow-kernel

​What does comet-any do

​When to use /comet-any

​/comet-any output

​Responsibilities of key documents

​required capability set

​hard gates

​validation findings code

​Next step

Core design principles

Main path

Three starting points

Workflow Contract: A common model for all paths

Two types of Workflows

`comet-five-phase-overlay`

`workflow-kernel`

Protected boundary: Five-stage customization based on Comet’s existing Skill

8 built-in Output schemas

Solution example: Add Gray-Me requirement clarification to /comet

Custom Node (workflow-kernel

What does comet-any do

When to use /comet-any

/comet-any output

Responsibilities of key documents

required capability set

hard gates

validation findings code

Next step