write-contributing
write-contributing
CONTRIBUTING.md is the one document that tells a contributor how work is done in this repo — which branch to start from, which command has to pass, how a commit is worded, where a bug goes. This skill owns that convention: one house structure, the same in every repo, with the repo-specific values read out of the repo rather than typed in. Structure catalogue, derivation recipes and reconcile rules: REFERENCE.md. Skeleton to copy: templates/CONTRIBUTING.template.md.
It is the guide's generator and its linter — the same skill scaffolds a missing one and reconciles an existing one, because the failure this exists to prevent is not a missing guide but a stale one.
Derived, not retyped
Almost nothing in a contributing guide is the guide's own fact. Split every statement in two, and the whole skill follows:
| Kind | What it is | This skill |
|---|---|---|
| Derived | A fact some other file decides — the branch base, the gate command, the commit convention, the runtime floor, an intake link | owns it: reads the owner every run and writes what it says |
| Authored | The project's own prose — what a good PR looks like, the review bar, what this project is picky about | never rewrites it; may report it as suspect |
A derived statement is re-derived on every run, never carried over from the existing text and never copied from another repo's guide. That is the entire mechanism: a guide assembled from the files it describes cannot contradict them, and a guide reconciled against them stops being able to drift silently.
A fact with no owning file is asked about, never assumed. "The default branch is main" is exactly the assumption that puts a contributor on the wrong branch — and it is the shape of every derivation failure here. Where two candidate owners disagree, that is a prompt, not a judgement call (reconcile).