skill
rigger skill <PROJECT> [--install] [--dir <DIR>] [--replace] [--template <FILE>]rigger skill --line [--install] [--dir <DIR>] [--replace] [--template <FILE>]rigger skill --print-template [<PROJECT>]rigger skill --line --print-templateWrites the skill file an assistant reads before it reads anything else about a project - from one template, filled with what the record knows.
$ rigger skill sample---name: sampledescription: sample - A sample product. Code in C:\dev\sample. Triggers on "work on sample", ...---
<!-- generated by rigger skill; edit the template, not this file -->
# sample
The record knows where this project stands; the skill only says how to ask it.
## Start
1. `rigger context sample` - the packet: the current stage, what waits on the owner, recent events, the next step. ...Why a skill is thin
Section titled “Why a skill is thin”The skills a line keeps by hand grow. Each one carries a product summary, the ritual for starting a session, the ritual for starting a stage, the rules for working, the ritual for shipping, the ritual for ending, a table of where things are, and the commands to run - sixteen kilobytes, seventeen times over, nearly identical, and every change to the ritual is seventeen edits. More often it is one edit and sixteen skills quietly out of date.
Most of what they hold is held better elsewhere now. The state of the work is the context packet. The rituals are the same for every project and belong in one place. What is left for a skill to say is how to ask the record, and that is a template with the project’s name in it.
The template
Section titled “The template”rigger ships one in English. --print-template prints it, to start your own from:
$ rigger skill --print-template > skill.mdA template named skill.md in the data directory is used for every project from then on; --template <FILE> names another for one run. The placeholders:
| Placeholder | Filled with |
|---|---|
{{name}} |
the project’s name |
{{path}} |
the checkout, or the folder the work lives in |
{{remote}} |
- and the origin URL, or nothing when the repository has none |
{{hub}} |
where the hub is, once one was imported or exported |
{{about}} |
the line about the project: the description of a manifest at the root - a Cargo.toml’s [package], then its [workspace.package], then a package.json - else of the workspace member that ships; where none says one, the line project set --about recorded |
{{file:NAME}} |
the contents of NAME in the hub - for what only this project can say |
Both built-in templates end their start with one more sentence: a skill called with a word after its name - /sample release, /stories sync - is being asked for the ritual of that name in rules, and runs it whole. A project’s own rituals live in the record, so the word is all the skill has to carry.
The description is measured, as the line’s is: a skill whose description is over 1024 characters, or carries < or >, is refused rather than written (see below). A line about a project is now something a person can write into the record, which is what makes the check worth having here too.
A folder with no repository
Section titled “A folder with no repository”A folder - work made of files, with no repository - has a template of its own. A repository’s skill speaks of code, of commits and of a gate before each one, and every one of those sentences is wrong about a folder of texts; a conditional inside one template would have been a language to learn for a single difference.
$ rigger skill stories---name: storiesdescription: stories - A library of short stories, one idea each. The work lives in C:\notes\stories, a folder with no repository. Triggers on "work on stories", ...---skill.folder.md in the data directory replaces it, the way skill.md replaces the repository’s. A folder never falls back to skill.md: a line that wrote its own template for repositories wrote about code and commits, and the built-in folder template is nearer the truth than that. --print-template <PROJECT> prints the built-in template of that project’s kind. A place the record keeps for itself (project service) has nothing in it to work on, and is refused a skill.
{{file:...}} is how a project keeps a ritual of its own - a deployment that has to happen after the tag, a week of use before a version counts as shipped - without every skill of the line carrying it. The file lives in the hub, written by hand, and the skill quotes it. A file that is not there leaves the section empty and says so on stderr; a placeholder rigger does not know is an error, because a skill with a hole in it would be read by every session before anyone noticed.
Under --json it prints what was done and the skill’s text:
| Field | Type | Meaning |
|---|---|---|
action |
string | wrote or rewrote (the file was installed), unchanged (it already said this), printed (nothing installed; the text only), or template (--print-template). |
path |
string or null | The file written or checked; null when nothing was installed. |
text |
string | The skill’s text, or the template’s with --print-template. |
--install
Section titled “--install”Writes the skill where the assistant reads it - ~/.claude/skills/<project>/SKILL.md for the default one, or under RIGGER_SKILLS_DIR; --dir <DIR> names a directory for one run.
$ rigger skill sample --installWrote C:\Users\me\.claude\skills\sample\SKILL.md from C:\Users\me\AppData\Local\lacodda\rigger\data\skill.md.A skill rigger wrote is rewritten whenever the template or the record changed, and left alone when nothing did. A skill a person wrote is not replaced because a command was typed:
$ rigger skill sample --installerror: C:\Users\me\.claude\skills\sample\SKILL.md was written by hand and rigger has not written it before.Move what it says that only this project can say into the hub, then run again with `--replace`.The marker after the front matter is how the next run knows the file is rigger’s. It carries no timestamp: a stamp would make an unchanged skill a diff on every run.
--line: one skill instead of one per project
Section titled “--line: one skill instead of one per project”A skill per project is still a file per project, and a line with seventeen of them has seventeen descriptions in the assistant’s catalogue saying nearly the same thing. --line writes one:
$ rigger skill --line --installWrote C:\Users\me\.claude\skills\line\SKILL.md from the built-in template: 18 projects, description 512 of 1024 characters.It is named after the profile, because a line of products and a ticket desk are different ways of working and should not answer to one skill. The project is named in the request, or taken from the working directory - every recorded path is one rigger knows. A request that names none - “what is next”, “get on with the line” - is sent to rigger pick, which names the project and the reason.
The body carries the table of projects, and project add rewrites it when a skill is already installed. A project added after the skill was written would otherwise leave it describing a line one short, and an assistant asked to work on that project would read a skill that has never heard of it.
The description is measured
Section titled “The description is measured”Every assistant loads all of its skills’ descriptions at once, to decide which one a request belongs to. Anthropic’s limit is 1024 characters, and a description over it is not truncated - the skill is rejected whole. The failure is silent: the skill does not announce itself, it simply never matches anything.
So --line measures what it writes, and refuses a description that is too long or that carries < or >, which break the catalogue’s parse. The names of the projects go into the description while they fit - a router matching “continue midda” has to see that word somewhere - and the rest of the list is in the body, which is not loaded until the skill is already chosen.
The line template’s placeholders are its own: {{line}}, {{description}} and {{projects}}. A project’s {{name}} would have to pick a project arbitrarily, so it is an error instead. --line --print-template prints the template; a skill.line.md in the data directory replaces it.
Moving a project onto rigger
Section titled “Moving a project onto rigger”Two commands. adopt records the repository, reads its hub and its tags; skill --install replaces the skill that used to carry all of that by hand.