skillkitlisted

# skillkit Authoring skill for this collection. It turns a rough idea ("I want a skill that does X") into a lean, conventions-compliant `skills/<name>/SKILL.md`, then dev-links it so you can try it live. Every skill here is authored from scratch — never forked — and obeys [`AGENTS.md`](../../../AGENTS.md); skillkit exists so you don't re-derive those rules each time. ## Invocation `/skillkit` — or any natural "create/author/scaffold a skill" request. If the user hasn't said what the skill should *do*, ask before anything else. Drive the procedure below one step at a time; don't jump ahead to drafting before intent, visibility, provenance, and name are settled. ## Procedure ### 1. Gather intent Ask what the skill should do and *when it should trigger* (the real user phrasings). Optionally ask for example skill links; if given, skim them for structure ideas — non-blocking, and only if fetching is available. Capture: the job, the trigger conditions, and any hard constraints (tools it needs, things it must not do). ### 2. Visibility (internal or public?) Ask whether this is an **internal** repo-only skill or a **public** publishable one — it changes the rules for everything downstream (see `AGENTS.md` → *Visibility*). - **internal** (like skillkit): a maintenance/meta skill for this repo. Repo coupling is fine — it may reference `AGENTS.md`, `make`, and use repo-relative links. Stamp `metadata.internal: true`. skills.sh hides it from discovery. - **public** (like commitkit,