Skip to main content
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.
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.

​
Create a skill

1

Create the directory

For a shared local skill, create:
Named agents also receive a workspace-specific skills/ directory, which takes precedence over shared discovery paths.
2

Add frontmatter

A prompt skill needs a stable name and a description the model can use for selection:
3

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:
Model selection is probabilistic. Check traces when you need to confirm whether the model actually read and followed the skill.

​
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.
Replacing discoveryPaths replaces the default shared pool unless you include it again. Use absolute, reviewed paths in production.

​
Selection controls

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, Tool Policy, and 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.

Manifest Reference

Supported frontmatter and metadata

Examples

Complete skill files to adapt

Tool Policy

Enforce agent-level tool restrictions

Security Scanning

Understand content checks and their limits