Two files, one set of rules
Every scaffolded project contains aCLAUDE.md and an AGENTS.md with identical
content, written together so they cannot drift. AGENTS.md is the vendor-neutral name
other tools look for. Both carry the full rules rather than one linking to the other,
because an assistant that has to follow a link often does not.
A .claude/settings.json is scaffolded alongside them, pre-approving the read-only
commands an assistant needs.
These files are a starting point. Add your project’s own domain rules and preferences
as the app grows.
Rules an assistant can verify
What makes the conventions useful is that they are checkable. An assistant can confirm its own work instead of hoping:feather check
Are the conventions being followed? Reports a file, a line and a remedy for each
problem.
feather components
What arguments does this macro take? Read from the macros themselves, so it is right
even when documentation is not.
feather routes
What is actually registered?
feather test
Does it still work?
Why the conventions are strict
The rules inCLAUDE.md are not only advice. feather check enforces
the ones that can be enforced and exits non-zero on any error, so it works as a
pre-commit hook or a CI step.
A route that is deliberately public is exempted with a # feather: public comment in
its module, which records the decision rather than hiding it. When a rule is wrong about
a specific line, an inline marker silences it for that line only and asks you to write
the reason — a rule with no way to say “not here” is one people turn off altogether.