Press slash to focus this field, or Escape to return home.
How do you use skills files?
ToolsSkills files are versioned markdown that encode how I build: the rules any agent follows on my projects, in git, each one dated and traceable to what produced it.
A rule that lives only in my head applies when I happen to remember it. A rule in a file applies every time, on every project, to me and to anything working on my behalf. That is why they exist.
They are verified-only. An entry earns its place by having been observed: the tool that produced it, the date, and what happened. Platforms move and documentation lags, so an entry cites what I watched the tool do. When an entry turns out to be wrong it gets rewritten in place, so there is exactly one current truth per subject.
A trap costs one session the first time and nothing ever again. The standard travels with the work, so the next project starts where the last one finished.
The rules the files themselves follow
Every entry is traceable to an observation
The tool that produced it, the date it happened, and what it did. An entry that cannot name its source stays out.
Undated is unverified
Platforms move. An entry without a date cannot be checked against the thing it describes, so it cannot be trusted or retired.
A correction rewrites the entry
The old text comes out and the corrected version takes its place. One current truth per subject, or the file becomes an archaeology exercise.
Preference and behaviour are labelled separately
My preferences are marked as mine; platform behaviour is marked as behaviour. Conflating the two makes both of them untrustworthy.
A skill that does not say when to use it will not be used
The trigger is part of the content, written into the file itself.
Failures get written down too
A check that failed is information. Recording only successes produces a file that describes a project nobody worked on.