Contributing skills

Use these conventions when adding or changing skills in this collection.

• Put each skill in skills/<name>/SKILL.md. Use a lowercase, hyphenated name that matches the folder and a description explaining the task and when it applies.
• Keep the entry point short enough to read in one pass. State the outcome, the decisions that matter, and how to verify the result.
• Write for a capable agent. Prefer specific failure modes and reasons over generic instructions to be careful or thorough.
• Move substantial conditional guidance into relative reference files. Say when to read each one. Avoid copying the same rules into several files.
• Include executable helpers only when they save repeated work or enforce a meaningful invariant. Give them explicit inputs, bounded effects, and runnable checks.
• Keep instructions portable. Use ordinary Markdown and common frontmatter; isolate host-specific features and provide a fallback when a named tool is unavailable.
• Preserve the user's task and existing authorization. A skill must not turn an explanation into an implementation or a local change into publication. Ask only for missing choices that materially affect the work.
• Use primary sources for technical requirements. Link the source near the claim; distinguish documented requirements, project conventions, and observations from one device or version.
• For imported skills, preserve the upstream license inside each independently installable folder and record its source commit and local changes in THIRD_PARTY.md. Review upstream changes manually; keep optional companion routing usable when only one skill is installed.
• Do not turn a copied example's version numbers into a support promise. Check current documentation and the actual project before prescribing toolchain or API details.
• Give new skills representative task prompts, a nearby task that should not trigger them, and observable pass criteria. Check decisions and artifacts, not exact phrasing.
• Test helpers locally. Distinguish syntax checks, mocked checks, model evaluations, and live-environment validation. Do not claim one proves the others.
• Keep the repository small: a short README, this file, the template, skills, and checks or sources that serve a concrete purpose. Add dependencies, CI, plugins, or publishing automation only when needed.

Use templates/SKILL.md.template as a starting point, not a required outline. Improve instructions from demonstrated failures and remove rules that no longer help.