Skill Creator

Skill creator

Help the user turn an intent or a workflow from this conversation into a personal skill they can trigger later. A skill is only as good as its description (which decides when it fires) and its body (which decides what happens when it does). Optimize both deliberately.

Steps

1. Interview briefly. Ask only what you cannot infer:
   • What task should the skill perform?
   • What phrases or situations should trigger it?
   • What should the output look like? Ask for an example of a good output if one exists. If the current conversation already contains the workflow ("turn this into a skill"), extract the steps, formats, and corrections from the history first and only ask about the gaps. Match the user's technical level; not everyone knows what "frontmatter" means, and they do not need to.
2. Check for collisions. Call skills_list. If a similar personal skill exists, suggest updating it instead of creating a near-duplicate. Curated skill names cannot be shadowed; pick a different name if there is a clash.
3. Draft the skill: name, description, body, per the guidance below.
4. Show the full draft in the chat and ask for approval. Invite edits; the description and output format are the parts most worth the user's eyes.
5. Persist with skill_manage, action "create", passing name, description, and body. Confirm to the user that the skill is live, that it will route automatically when relevant, and that they can also invoke it explicitly by typing "/" plus the name in the composer.
6. Offer a dry run: take a realistic prompt the skill should handle, follow the new skill's body yourself, and show the result. If it misses, revise and update via skill_manage action "update".

Naming

Short kebab-case, easy to type after "/". "weekly-report", not "generate-my-weekly-status-report-skill". Two or three words maximum. The name should read naturally as a command.

Description

The description does double duty: it drives automatic routing (matched by meaning against incoming messages) and it is what the user sees in their catalog. Write it in third person, one to three sentences, stating what the skill does AND when it should trigger, including concrete trigger phrases or situations. Err on the side of explicit triggers; vague descriptions cause the skill to sit unused. Also state what it is not for when an adjacent skill could be confused with it.

Weak: "Helps with reports." Strong: "Draft the user's Monday status report from bullet points they paste. Use when they mention a weekly report, Monday update, or status summary."

Body

The body is instructions the assistant will follow when the skill fires.

• Imperative voice, addressed to the assistant: "Ask for the raw bullets, then group them by project."
• Concrete output formats. If the output has a fixed shape, spell out the exact template or section headings.
• Include one small input-to-output example when the format is not obvious.
• Keep it lean: aim well under a few thousand characters. Cut anything not pulling its weight; a skill that rambles gets followed loosely.
• Explain why a rule matters when it is not obvious, rather than stacking all-caps musts.
• Reference only capabilities that exist here: web search, attachments, the code sandbox, connectors, artifacts. No local files, scripts, or CLIs.

Rules

• Never persist without showing the draft and getting an explicit yes.
• Keep skills general. The user iterates on one example, but the skill must work on the next hundred variations; avoid overfitting to the sample.
• One skill, one job. If the interview reveals two unrelated tasks, propose two skills.
• No secrets, credentials, or personal data in the body.