Skills

• Progressive disclosure every skill’s name + one-line description sits in the system prompt at near-zero token cost; the full instructions body only loads when the model calls use_skill, keeping a large skill library cheap to carry
• Shared by chat and Orchestrator one skill library, ~/.coder/skills/<name>/SKILL.md, available to the interactive chat agent and every Orchestrator stage (PM, builders, reviewer) alike
• Managed in the Prompts panel a “Skills” section lists every skill with its description, alongside a create (+) button and per-skill delete; clicking a skill opens its SKILL.md for editing like any other file
• Just markdown a skill is a folder with a SKILL.md (YAML frontmatter for name/description, then free-form instructions below); no code or registration required to add one

​

Layout

~/.coder/skills/
  my-skill/
    SKILL.md        # frontmatter: name, description, then free-form instructions
    reference.md     # optional bundled reference file
    templates/
      foo.md          # bundled files can be nested in subfolders

​

Built-in skills

​

Adding a built-in skill for code quality or a Coder feature

• Code-quality skills — e.g. lint, which dispatches to the real linter per language (ESLint, PHPStan, golangci-lint, Clippy, RuboCop) rather than approximating one tool’s rules with another. These matter most when a user asks the agent to “scope a new project” — a good default skill here means the agent reaches for the real tool with a sane starter config instead of guessing.
• Coder-feature skills — teaching the agent to use a capability specific to this app (e.g. writing a .mindmap.md, generating LaTeX for KaTeX rendering). Skip this path for anything the agent should have access to unconditionally rather than only when a task matches a skill description — see the docs-tool note below.

​

Custom overrides

~/.coder/skills/
  engineering/          # shipped copy — kept in sync automatically
    SKILL.md
  custom-engineering/    # user's fork — wins whenever both exist
    SKILL.md

• First edit forks automatically. Editing a pristine shipped skill in the Prompts panel deep-copies it to custom-<name> and the original underneath is left untouched as the sync target — you never edit the shipped copy directly.
• The custom directory always wins. Both the model’s use_skill lookup and the Skills sidebar resolve <name> to custom-<name> when it exists; nothing else needs to know a fork exists.
• Sync respects the fork. A background/manual sync from coder-skills only updates the shipped copy underneath a fork, never the custom- directory — your edits are never overwritten by an upstream change. If you create a brand-new skill whose name collides with one newly added upstream, the sync skips it rather than overwriting your work.
• A skill you create fresh (no built-in with that name) is just a plain ~/.coder/skills/<name>/ directory — the custom- prefix only matters for overriding something built-in.

​

How the model sees skills

1. Listing (always in context) — every skill’s name + description, one line each, injected into the system prompt. Both built-in and custom skills are included, already collapsed to whichever one wins per the override rule above — the model never sees “shipped vs custom,” only the winning name and description.
2. use_skill({name}) — loads the full SKILL.md body (frontmatter stripped) on demand, once the model decides a skill’s description matches the task at hand.
3. read_skill_file({skill_name, path}) — fetches a bundled reference file a skill body links to (e.g. engineering’s PHP.md). Read-only: a skill can bundle a script or template, but the agent can only read it, never execute it — if a skill needs a command run, its SKILL.md should instruct the agent to run that command directly via its normal tools, not rely on a bundled script being executable.