> ## Documentation Index
> Fetch the complete documentation index at: https://comis-fix-skill-import-vetting-gate.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Prompt Skills

> Create discoverable Markdown procedures that agents can select and read

Prompt skills are `SKILL.md` files containing reusable instructions. Comis
discovers eligible skills and exposes their name, description, and location to
the agent's capability index. The model can then select a relevant skill and
read its instructions with its existing file tools.

<Warning>
  The current daemon does not wire `/skill:name` to direct skill loading. Do not
  build user workflows or scheduled messages around that syntax. Ask the agent in
  ordinary language to use a named skill, or describe the task so the model can
  select it from the capability index.
</Warning>

## Create a skill

<Steps>
  <Step title="Create the directory">
    For a shared local skill, create:

    ```text theme={}
    ~/.comis/skills/greeting/SKILL.md
    ```

    Named agents also receive a workspace-specific `skills/` directory, which
    takes precedence over shared discovery paths.
  </Step>

  <Step title="Add frontmatter">
    A prompt skill needs a stable name and a description the model can use for
    selection:

    ```markdown theme={}
    ---
    name: greeting
    description: "Welcome a new user and explain how the agent can help"
    ---

    When greeting a new user:

    1. Use their name when it is available.
    2. Briefly explain the agent's scope.
    3. Ask what they want to do first.
    ```
  </Step>

  <Step title="Verify discovery">
    Restart or reload the skill registry as appropriate, then inspect the
    available skills through the CLI, API, or dashboard. In chat, use an
    ordinary-language request such as:

    ```text theme={}
    Use the greeting skill to welcome Moshe.
    ```

    Model selection is probabilistic. Check traces when you need to confirm
    whether the model actually read and followed the skill.
  </Step>
</Steps>

## Discovery order

Comis discovers root Markdown files and recursive `SKILL.md` files from the
configured `skills.discoveryPaths`. A named agent's workspace
skills directory is prepended, so an agent-specific skill wins when duplicate
names are encountered. Eligibility filters can exclude a skill by name,
operating system, required binary, or required environment name.

<Note>
  Replacing `discoveryPaths` replaces the default shared pool unless you include
  it again. Use absolute, reviewed paths in production.
</Note>

## Selection controls

| Field                          | Current effect                                                                       |
| ------------------------------ | ------------------------------------------------------------------------------------ |
| `description`                  | Helps the model understand when the skill is relevant                                |
| `disableModelInvocation: true` | Hides the skill from the model-facing capability index                               |
| `userInvocable`                | Parsed and exposed by the registry, but direct chat invocation is not wired          |
| `argumentHint`                 | Metadata for invocation-capable consumers; it does not enable chat dispatch          |
| `allowedTools`                 | Parsed restriction metadata for consumers; do not treat it as an OS sandbox          |
| `comis.requires`               | Filters skills whose OS, binaries, or named environment requirements are unavailable |

If `disableModelInvocation` is true, the current chat path has no deterministic
`/skill:name` fallback. Such a skill needs another integration that explicitly
loads it.

## Security boundaries

* Skill content is untrusted input. Content scanning and sanitization reduce
  common risks but cannot prove a skill safe.
* The default agent tool-policy profile is `full`. Configure a narrower policy
  independently of the skill manifest.
* `allowedTools` and manifest `permissions` are not kernel isolation.
* `system.exec` has a separate optional OS sandbox; MCP stdio servers and
  in-process tools run outside it.
* Dynamic content or executable dependencies should be enabled only for skill
  sources you review and trust.

See [Skill Sandboxing](/security/sandbox), [Tool Policy](/skills/tool-policy),
and [Security Scanning](/skills/security-scanning) for the boundaries.

## Writing effective skills

* Give the skill a narrow purpose and an accurate description.
* Write explicit steps, inputs, stop conditions, and expected output.
* Name the tools the procedure expects, but also enforce access in the agent's
  tool policy.
* Treat external text the skill retrieves as untrusted.
* Test with representative prompts and inspect whether the skill was selected.

<CardGroup cols={2}>
  <Card title="Manifest Reference" icon="file-code" href="/skills/manifest">
    Supported frontmatter and metadata
  </Card>

  <Card title="Examples" icon="lightbulb" href="/skills/examples">
    Complete skill files to adapt
  </Card>

  <Card title="Tool Policy" icon="toolbox" href="/skills/tool-policy">
    Enforce agent-level tool restrictions
  </Card>

  <Card title="Security Scanning" icon="shield-check" href="/skills/security-scanning">
    Understand content checks and their limits
  </Card>
</CardGroup>