The old harness scored occurrences of words like VERIFICAR, so its score measured wording, and it failed on a fresh clone. The lint checks frontmatter, size limits, references and links; test_gate.py exercises the gate and hooks on a throwaway repo; check_upstream.py flags vendored skills behind upstream. Co-Authored-By: Claude Opus 5.5 <[email protected]>
1.2 KiB
1.2 KiB
Contributing
Open an issue to discuss first, then send a small, focused PR.
Rules
- Grounded. Every command, path and claim in a skill or README traces to a real fact. No invented commands or badges.
- Short skills.
SKILL.mdstays under 150 lines; details go toreferences/next to it. - Proportional. Each phase says from which tier it runs. Nothing is mandatory for every request unless it is cheap (the tier 0 gate).
- Checks are tools, not keyword counts. A verification step runs something that can fail (tests, scanners, the gate).
grep -cof a word proves nothing. - No AI-isms in docs and skills (no em-dash runs, no "robust/seamless/leverage").
- Vendored skills are copied 1:1 with their license, and recorded in
skills/NOTICE.md(origin, commit, license).
Local checks before a PR
python3 qa/lint_skills.py
python3 qa/test_gate.py
claude plugin validate --strict .claude-plugin/plugin.json
A new skill referenced by a workflow goes into its metadata.dev-workflows.uses (vendored) or
external (listed in docs/SKILLS.md); the lint checks both.
Process
- Fork and branch:
git checkout -b feat/your-change. - Make the change and run the checks above.
- Open a PR saying what changed and why.