LatentCodeCustomize
Skills
A skill is a folder of instructions, and optionally scripts and reference files, that the agent loads only when a task needs it.
How skills work
The agent sees each skill's name and description, and loads a matching skill's full instructions before it starts the work. Skills cost almost no context until they're used, so you can install many. You can also run a skill yourself: /skills lists them, and /<skill-name> runs one.
LatentCode also checks each message you send against your skills' names and descriptions. When a skill matches, the agent's first attempt to edit a file or run a shell command in that turn is held back with a Load <skill> first notice, so it reads the skill before acting. If the skill doesn't apply, the agent says so and carries on. This happens at most once per message.
Write a skill
Create a folder containing a SKILL.md. The front matter needs a name, and should have a description that says when to use it.
---
name: release-notes
description: Write release notes from merged pull requests. Use when asked for release notes, a changelog or a summary of what shipped.
---
# Release notes
1. Find the previous tag with `git describe --tags --abbrev=0`.
2. List merged pull requests since then with `gh pr list --state merged --search "merged:>=<date>"`.
3. Group them under Features, Fixes and Internal. Skip dependency bumps.
4. Follow the format in `template.md` in this folder.Other files in the folder, such as templates, examples or scripts, are available to the agent: when it loads the skill, it's told the folder's location.
Write the description with the words people use when they ask for the task: matching relies on them. A skill without a description is never matched or shown to the agent.
Where skills are found
| Location | Scope |
|---|---|
| .latentcode/skills/<name>/SKILL.md | This project. Commit it to share with your team. |
| ~/.config/latentcode/skills/<name>/SKILL.md | All your projects. |
| Bundled | Skills bundled with LatentStack. Turn them off with "skills": { "native": { "enabled": false } }. |
| .claude/skills and .agents/skills | Skills written for other agents, in your home directory and in the project and its parents. |
paths in skills.paths | Any other folders you list, searched for SKILL.md files. |
URLs in skills.urls | Skills downloaded from a web server. Each URL is a folder with an index.json listing its skills. |
If two skills have the same name, the one found first in this order wins. skill/ works as the folder name as well as skills/. List everything LatentCode found with:
latentcode debug skill{
"skills": {
"paths": ["~/team-skills", "tools/skills"],
"urls": [
"https://example.com/.well-known/skills/",
{ "url": "https://skills.example.com/team/", "headerEnv": { "X-API-Key": "TEAM_SKILLS_KEY" } }
]
}
}Skills you add while LatentCode is running show up within a few seconds, with no restart. Skills from URLs are checked for updates every 15 minutes; give a skill a version in index.json and LatentCode downloads it again when the version changes.
Skill servers that need a key
Use the object form, as in the second urls entry above. headerEnv maps each request header to the name of an environment variable, so the key never goes in your config file. Export the variable before starting LatentCode (or later: it's read on every request). If it isn't set, the header is left out. The header is only sent to that server, never to another site it redirects to.
LATENTCODE_DISABLE_EXTERNAL_SKILLS=1 to ignore .claude/skills and .agents/skills, or LATENTCODE_DISABLE_CLAUDE_CODE_SKILLS=1 to ignore only .claude/skills.Control which skills are used
Loading a skill is a permission, matched against the skill's name:
{ "permission": { "skill": { "*": "allow", "deploy-*": "ask" } } }Denying the skill permission entirely also turns off skill matching.
- Two skills come with LatentCode:
customize-latentcode, which helps the agent change LatentCode's own configuration, andl-spec, for spec-driven changes. - See Permissions for how rules combine.