Skip to main content
The six packaged skills arrive with a project. decktalk init DIR writes them by default, and there is no separate command that installs them, because a skill is read from the project an agent is working in.
The skills live inside the Python package, so the skills a project gets always match the CLI that wrote them. decktalk init --json reports which way it went in its skills_written field, and every file it wrote in written.

​
The two folders

The skills are written once into one generic folder, and a second folder points at it. The six folders are decktalk-script, decktalk-slide, decktalk-cues, decktalk-build, decktalk-fix and decktalk-revise, in the order an author meets them. On a machine where a link cannot be made, which is usually Windows without the privilege for one, init writes a copy instead of a link. The copy holds the same files, and it has to be written again when the skills change. Do not commit a second copy of a skill under another name. Several harnesses read both folders, and two copies of one skill is the case where a harness has to guess which one it is loading.

​
Leaving the skills out

decktalk init DIR --no-skills writes neither folder. Nothing else about the project changes, so a project written that way still builds, and skills_written is false in the result. Use it when your repository installs skills its own way, or when the project is built by a person and read by no agent at all.

​
Getting newer skills into a project that already has one

Nothing upgrades in place. decktalk init refuses a directory that already holds files, with the error code APPROVAL and a hint naming the flag that would answer it.
--overwrite writes the whole packaged project over what is there, which replaces script.md, cues.json, decktalk.toml and the deck. It is not a way to refresh the skills alone. The one file it leaves untouched is AGENTS.md, because a file the author wrote is theirs. To take newer skills into a project you care about, write a fresh project in an empty directory and copy .agents/skills/ across, or install DeckTalk’s newer version and write the new project somewhere else first and compare.

​
Which harness reads which folder

Every harness below loads a SKILL.md natively. The folders are the ones each harness documents for a project. The two folders init writes reach every harness in that table. .agents/skills/ reaches eight of them, and .claude/skills reaches the one harness that does not read the generic folder.
One harness is tested here and the rest are documented as untested. The skills are held to the open format so that any of them can load the files. If a skill misfires on another harness, open an issue that names the harness and its version, because it cannot be reproduced here without them.

​
Why the skills carry no harness-specific field

A packaged skill’s front matter carries only name, description, compatibility and metadata, and the repository’s own test refuses any key outside name, description, license, compatibility and metadata. Several harnesses add fields of their own, and a field that one harness honours and another ignores gives one skill two behaviours. Some services also reject a skill whose front matter carries a key they do not know. The same test refuses a vendor, model or harness name anywhere in a skill, for the same reason: the files ship to whoever reads them. The cost of the choice is that no front-matter field can mark a skill as user-only, so the guards against buying live in the skill text and in the CLI. Agent skills lists them.
  • Agent skills for what each of the six skills covers.
  • AGENTS.md for the file init writes beside them.
  • Reference card for the page to hand an agent that loads no skill at all.