skill-authoringlisted

# Skill Authoring Write a skill that actually loads, does one thing, and stays maintainable. Selection happens on the description, so most skill failures are description failures. ## When to use - Writing a new skill - A skill exists and never fires - The wrong skill fires on a request - A skill set has grown past a dozen and collisions started ## Inputs - Reads: `workspace/agents/<name>/brief.md`, the context portfolio - Needs from user: the procedure, the phrases a real person uses to ask for it, and the output shape ## Workflow ### 1. Get the description right, because nothing else matters if it is wrong Selection happens on the description alone. The body is invisible until after selection. A description needs three things: ```yaml description: <what it does, in one clause>. Use when the user says "<literal phrase>", "<literal phrase>", "<sloppy real-world phrase>". <What it produces and where it writes.> ``` **Use the literal phrases people actually type, including the ungrammatical ones.** "our data is a mess" is a real trigger. "when the user requires data quality remediation" is not, because nobody says that. **State the output.** A description that says what it writes helps both selection and the reader. ### 2. Write the negative boundary Half of trigger problems are over-firing, not under-firing. ``` Do NOT use this skill when: - <adjacent case> → use <other skill> - <adjacent case> → do it inline, no skill needed ``` If two descriptions in your se