> ## Documentation Index
> Fetch the complete documentation index at: https://docs.comet.rpamis.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Compose Any Skill FAQ

> Answers to common questions about /comet-any's three starting points, plan confirmation, preference configuration, evaluation and publishing, and interruption recovery.

Frequently asked questions about the `/comet-any` Skill Creator's creation flow, preference configuration, publishing, and distribution.

## Basic Concepts

<AccordionGroup>
  <Accordion title="What is the difference between /comet-any and /comet">
    `/comet` is the entry point for Classic Spec Mode, used to complete a project change. `/comet-any` is the Skill Creator, used to create, optimize, or organize reusable Skills.

    If you want to build a product feature, fix a bug, or modify project code, use `/comet`. If you want to distill a workflow into a reusable Skill, or add team rules on top of the `/comet` five phases, use `/comet-any`.
  </Accordion>

  <Accordion title="How do I choose among the three starting points">
    Choose based on your goal:

    * **Five-phase customization based on existing Comet Skills**: You want to keep the `/comet` five phases and only add a component library, review rules, or team constraints.
    * **Create a brand-new workflow Skill**: You want to turn a new process into a reusable Skill.
    * **Organize an existing Skill**: You already have a Skill but want to add evaluation, publishing, recovery, and distribution capabilities.

    When unsure, just describe your goal first. `/comet-any` will explain the recommended starting point on the plan confirmation page.
  </Accordion>

  <Accordion title="Do I need to understand terms like Workflow Node and Output Schema">
    Not for everyday use. You only need to look at the plan confirmation page to see what each step does, which Skills will be invoked, and which capabilities will be added or disabled.

    These terms are for advanced design and troubleshooting. If you want to replace a phase's implementation, build an entirely new workflow, or audit why generated artifacts can recover and verify, then read the [Skill Creator Overview](/en/skill-creator/overview).
  </Accordion>

  <Accordion title="Why isn't it just generating a single SKILL.md">
    A lightweight single-step Skill can be very simple. But multi-step Skills often need recovery, verification, publishing evidence, scripts, or platform distribution previews. `/comet-any` generates a complete Skill package as needed so it can be evaluated, reviewed, published, and recovered.

    You don't need to maintain these internal files by hand. The normal entry points remain `/comet-any`, `comet creator status/next`, and `comet publish`.
  </Accordion>

  <Accordion title="What do keep/add/replace/disable mean on the confirmation page">
    This is the change summary `/comet-any` gives you before generating:

    * **Keep**: Continue using the original process steps.
    * **Add**: Require an additional call to a specified Skill within a step.
    * **Replace**: Replace an output step that is allowed to be replaced.
    * **Disable**: Turn off optional steps, such as certain review checkpoints.

    When customizing based on `/comet`, the core control steps cannot be replaced arbitrarily. The plan confirmation page will list what can and cannot be done.
  </Accordion>
</AccordionGroup>

## Preferences and Plan

<AccordionGroup>
  <Accordion title="What is .comet/skill-preferences.yaml">
    It is a project-level Skill preference file that tells `/comet-any` which Skills to prefer reusing, which Skills must be satisfied, and how to handle missing items, ambiguities, scripts, or hooks.

    You can skip it on first use. `/comet-any` will scan the current platform's Skills and suggest whether to save default preferences. Read [Skill Preferences and Source of Truth](/en/skill-creator/preferences) when you want to write it by hand.
  </Accordion>

  <Accordion title="What is the difference between advisory and strict modes">
    `advisory` is the default mode. It tries to compose based on preferences but allows supplementing with Skills the goal requires, and explains the reasons for any deviation.

    `strict` is suited for team standardization. Missing required Skills, ambiguous sources, or policy-prohibited scripts/hooks will block, requiring you to resolve them explicitly.
  </Accordion>

  <Accordion title="Why does the plan wait for my confirmation before generating">
    Because what `/comet-any` generates is a reusable Skill, not a one-off reply. It first shows a plan confirmation page so you can review the starting point, which Skills will be reused, missing or ambiguous candidates, executable capability disclosures, and the files that will be generated.

    It only writes to the draft after you confirm. If you choose to modify the plan or cancel, no generation state is written.
  </Accordion>

  <Accordion title="What if a candidate Skill is missing or has multiple sources">
    `/comet-any` will pause and ask you — it will never silently ignore it or pick a source for you.

    You can choose to specify a source, remove the missing item, update preferences, or explain why it should be ignored (where allowed). Only after you handle it will it continue generating the plan.
  </Accordion>

  <Accordion title="Can I specify that a certain Skill must be used">
    Yes. You can say so directly in your goal description, or write it into the `require` list of `.comet/skill-preferences.yaml`.

    If that Skill cannot be found or has multiple sources, `/comet-any` will stop and ask you to confirm. It must read the real `SKILL.md` and related references; it cannot guess capabilities by name alone.
  </Accordion>
</AccordionGroup>

## Evaluation and Publishing

<AccordionGroup>
  <Accordion title="Will it be automatically distributed to the platform after generation">
    No. After publishing, `/comet-any` will ask whether to distribute and must show a preview first. Only after you confirm the preview will it actually write to the target platform.
  </Accordion>

  <Accordion title="Can I publish directly once eval passes">
    No. A passing eval is only pre-publish evidence. You also need the current draft hash to match, manual approval to pass, and the target platform's capabilities to meet requirements.

    The easiest way to check is to run `comet creator next <name>` to see the next step, or `comet creator status <name>` to see the full readiness, blockers, and evidence.
  </Accordion>

  <Accordion title="Why is publishing blocked">
    Common reasons include: candidate Skills not yet resolved, the plan not yet confirmed, the current version not passing eval, missing manual approval, incomplete generated artifacts, platform capabilities not met, or executable capabilities not yet disclosed and confirmed.

    You don't need to judge internal state manually. First check `comet creator next <name>`, which gives the recommended next step; check `comet creator status <name>` when you need full context. See the blocker code table in [Publishing and Distributing Skills](/en/skill-creator/publishing#blocker-codes).
  </Accordion>

  <Accordion title="Why is a preview required before distribution">
    The preview shows the files that will be written, capabilities not supported by the target platform, executable disclosures such as scripts or hooks, and explicitly displays `No files were written`.

    This step is a hard gate against accidental writes. Only after confirming the preview result can the actual distribution proceed.
  </Accordion>

  <Accordion title="What environment do I need to run eval">
    You need `uv`, Python 3.11+, Docker, and `ANTHROPIC_API_KEY` (or `ANTHROPIC_AUTH_TOKEN`). The core Comet runtime does not require these; only `comet eval` does.

    See the full preparation steps in [Eval Quickstart · What you need to prepare before running](/en/eval/quickstart#what-you-need-to-prepare-before-running).
  </Accordion>
</AccordionGroup>

## Recovery and Troubleshooting

<AccordionGroup>
  <Accordion title="What if I get interrupted halfway through">
    Just say to the Agent: "Continue the previous Skill creation." `/comet-any` will first scan for resumable state, showing the name, status, next step, blocker reason, and the last confirmed plan summary.

    If you only want the next command, run `comet creator next <name>`. If you want the full status, run `comet creator status <name>`. See [Complete Skill Creation Workflow · Resuming an Interrupted Flow](/en/skill-creator/workflow#resuming-an-interrupted-flow).
  </Accordion>

  <Accordion title="If I changed the preference file, can I still use the old plan">
    It depends on the mode. `advisory` mode usually gives a warning and lets you choose to continue with the old plan or regenerate. `strict` mode is stricter and may block, requiring you to confirm whether to continue or regenerate.

    If unsure, run `comet creator next <name>` and follow the recommended next step.
  </Accordion>

  <Accordion title="What if I modified files after generation">
    Run `comet creator status <name>` or `comet creator next <name>` again. Comet will recompute the current version's state; old eval or approval results that no longer match the current version will not advance publishing.

    The safe approach is to re-evaluate, re-approve, or regenerate as prompted — do not hand-edit internal state files.
  </Accordion>

  <Accordion title="Can I hand-edit the creation state or internal JSON">
    Not recommended. `/comet-any` binds the plan, preferences, eval evidence, approval, and publishing state to the current version. Hand-editing internal JSON can easily invalidate hashes and readiness.

    Use `comet creator status` to view creation state, `comet creator next` to see the next step, and `comet publish review` for publishing review. Only deep audits or troubleshooting require looking at the advanced backend commands.
  </Accordion>

  <Accordion title="What if I don't want to run eval and publish commands myself">
    You can do everything by invoking `/comet-any` inside the Agent. It will proactively drive evaluation, review, publishing, and distribution previews, and stop where it needs your confirmation.

    The CLI commands in the docs are mainly for troubleshooting, automation, or quickly checking status after an interruption.
  </Accordion>
</AccordionGroup>