Create My Skill

Analyze the request

1. Check for an existing skill that covers the job. If one exists, stop and report that. If the user asked to change that skill, edit it.
2. If the agent already does the whole job without extra instructions, stop and say so.
3. Don't make strategic decisions for the user, suggest only.

Principles to write a skill

• Use a short, action-oriented name: lowercase letters, digits, and hyphens, under 64 characters. Match the folder name.
• Include YAML frontmatter with name and description. The description tells the agent when to use the skill, specifically enough to select that job, and leaves out unnecessary detail. Always double-quote the description. Do not add argument-hint.
• Include only what the agent would get wrong without the instruction: project conventions, domain procedures, non-obvious edge cases, and which tool or API to use.
• Pick one default. Mention an alternative only as the escape hatch for a named case.
• Keep detail moderate. Prefer concise steps, and one working example, over a catalog of edge cases.
• Put concrete surprises in SKILL.md, so they are read before the agent hits them. State the fact and what goes wrong.
• When steps depend on each other or on a check, give a checklist. For batch or destructive work, require a plan, validate the plan against the source of truth, then execute.
• Keep SKILL.md under 500 lines and 5,000 tokens. Move longer reference into references/ and say when to read each file. Use scripts/ for deterministic operations to reduce token usage. When the output must follow a format, give a template: a short one inline, a long or conditional one in assets/. Use assets/ for other files the output uses. Create none of these without a concrete need.
• Use your own words which you think fit the best, don't copy the user's phrases from the request.
• Follow DRY principle. A need to duplicate rules or instructions is a sign of poorly structured text.
• Distinguish requirements from preferences. Don't turn a single example or past failure into a universal rule.
• When mentioning a skill, quote its name in backticks and omit the word "skill" after it.
• Follow the style guide at https://google.github.io/styleguide/docguide/style.html. Use 2 spaces for a single indent.

Collaborate with the user

1. Report that you're done with "✅". Extend the answer from the single emoji only if there's something important to report or discuss, no need to write empty phrases like "the skill is done and waiting for your review".
2. After the user makes changes or asks to commit, review every sentence against the rules above. Enforce the rules strictly unless the user explicitly disagrees with them.