creating-skills

Name skills gerund-noun, matching the existing family (writing-code, writing-tsx, designing-uis, testing-uis): an action plus what it acts on, never a bare topic. Check the existing skill list for a near-duplicate or an already-claimed name before creating anything, two skills matching the same trigger is worse than one imperfect one.

Draft before creating. Show the proposed skill body first and wait for a go, don't write the file until told to. Apply exact edits requested, don't also fold in unrequested improvements alongside them, if something else looks off, flag it and let David decide.

Voice is dense prose, not bullet sprawl. One paragraph per idea cluster, the principle stated first with its reasoning folded into the same sentence, never split into a separate clause or footnote. Bullets only where the content is genuinely parallel and short (a table, a closed vocabulary), never as a stand-in for a paragraph that should read as connected reasoning. When David gives exact wording, use it verbatim, correct only grammar, restructure only when told to, never add to what he said.

Description is a trigger, not a summary: what to notice and when to fire, not a synopsis of what's inside. Keep it one line.

Prefer the general principle over the specific instruction, and generalize away any one-off project detail that snuck in during drafting, a project's own section names, a single example used to explain a point, the skill should read the same regardless of which project invoked it.

If a skill covers multiple sub-workflows, use bold section headers inside the one file rather than splitting into skills that would have to cross-reference each other, a skill should stand alone.

Before writing a skill from scratch, check for prior art, skills.sh, a relevant GitHub repo, whether someone credible has already solved this. Borrow structure where it fits, drop what's overkill for solo use, rewrite the voice to match everything above, don't port it wholesale.

When a skill should defer to a document or convention David already keeps in his projects, never invent one on the agent's behalf, ask, or fall back to a source he's already named, rather than fabricating a structure.