skill
rigger skill <PROJECT> [--install] [--dir <DIR>] [--replace] [--template <FILE>]rigger skill --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 |
{{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 description of the Cargo.toml or package.json at the root |
{{file:NAME}} |
the contents of NAME in the hub - for what only this project can say |
{{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.
--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.
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.