Menü
Use when creating, writing, or authoring a new Cursor agent skill, or when asking about skill structure, SKILL.md format, or skill best practices.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
| name | create-skill |
| description | Use when creating, writing, or authoring a new Cursor agent skill, or when asking about skill structure, SKILL.md format, or skill best practices. |
Categorize before writing -- this determines structure, degrees of freedom, and testing approach:
Infer from conversation context when possible. If clarification is needed, use AskQuestion (or ask conversationally if unavailable). Capture:
~/.cursor/skills/) or project (.cursor/skills/)create-skill > skill-creation, analyze-sessions > session-analysishelper, utils, tools, miscThe description determines whether the agent loads this skill. Max 1024 chars, third person.
Start with "Use when..." -- describe ONLY triggering conditions (symptoms, situations, contexts).
NEVER summarize the skill's workflow or process. Testing shows agents follow descriptions as shortcuts, skipping the full skill body. A description saying "does X then Y" causes agents to do exactly X then Y without reading the actual detailed instructions.
Include concrete triggers: error messages, symptoms, tool names, synonyms.
# BAD: workflow summary -- agent will shortcut to this
description: Analyzes code diffs, generates commit messages, and pushes to remote.
# BAD: too vague
description: Helps with documents.
# GOOD: triggering conditions only
description: Use when reviewing pull requests, examining code changes, or when asked for a code review.
# GOOD: specific triggers with keywords
description: Use when tests have race conditions, timing dependencies, or pass/fail inconsistently.
skill-name/
├── SKILL.md # Required -- main instructions
├── reference.md # Optional -- detailed docs (progressive disclosure)
└── scripts/ # Optional -- utility scripts
└── validate.py
The context window is shared. Only add what the agent doesn't already know. Challenge each paragraph: "Does this justify its token cost?"
# GOOD (~50 tokens): assumes agent knows what PDFs are
## Extract PDF text
Use pdfplumber:
import pdfplumber
with pdfplumber.open("file.pdf") as pdf:
text = pdf.pages[0].extract_text()
# BAD (~150 tokens): explains what a PDF is
PDF (Portable Document Format) files are a common file format...
Keep SKILL.md under 500 lines. Put detailed reference material in separate files the agent reads only when needed. Keep references one level deep from SKILL.md -- deeply nested references may be partially read.
## Advanced features
**Form filling**: See [FORMS.md](FORMS.md) for complete guide
**API reference**: See [REFERENCE.md](REFERENCE.md) for all methods
For reference files over 100 lines, include a table of contents at the top.
Match specificity to task fragility:
--help flags or reference filesBrief summary below. See best-practices.md for detailed examples with good/bad comparisons.
When including utility scripts:
analyze.py") or read it as reference ("See analyze.py for the algorithm")Always use fully qualified names: ServerName:tool_name
Use the GitHub:create_issue tool to create issues.
Use the Atlassian:getJiraIssueTypeMetaWithFields tool to discover custom fields.
When incorporating content from web sources or OSS into a skill:
Skills are TDD applied to process documentation. If you didn't watch an agent fail without the skill, you don't know if the skill teaches the right thing.
Run a representative scenario WITHOUT the skill. Document:
Write the skill addressing those specific failures. Run the same scenario WITH the skill. The agent should now comply.
Agent found a new rationalization? Add an explicit counter. Re-test until the skill is robust.
For skills that enforce rules, agents will rationalize under pressure:
| Excuse | Reality |Before finalizing:
scripts/helper.py)helper, utils, tools -- name by what the skill doesContent in this skill and best-practices.md incorporates material from:
Use when asked to rewrite or format text in the user's voice, "make this sound like me", "match my voice", "de-stiffen this", when text "reads too corporate / businessy / stiff", to "strip the em-dashes / agent typography", or to draft a Slack announcement, PR body, or doc in the user's voice. Also /match-voice.
Use when writing or rewriting reader-facing technical text — documentation, READMEs, runbooks, procedures, error messages, release notes, incident reports, API guides, agent/system prompts — or when asked to "de-slop", "make this readable", "simplify this doc", "write for non-native readers", "apply STE", "Simplified Technical English", or "ASD-STE100", or to prepare text for translation. Also use to CHECK such text for clarity violations. Do NOT use for chat replies, PR/review comments, or commit messages (that is terse-output), nor for marketing, brand, or personal-voice writing (that is match-voice) — this skill deletes persuasion by design.
Use when the user asks for a deep review, full review, comprehensive review, production readiness assessment, full audit, multi-domain audit, "security and reliability and code review", or "review everything". Also use when the user explicitly requests performance review alongside the comprehensive request (e.g. "include perf", "review including performance", "deep review with perf"); without that explicit phrasing, performance is excluded. Do NOT use for narrow single-domain reviews (use the matching review-* skill directly).
Review code architecture (SOLID, design patterns, package design, coupling, testability), Go best practices, and protobuf/API design using manual analysis and static analysis tools (gocyclo, staticcheck, buf). Use when the user asks for a code review, architecture review, Go review, protobuf review, SOLID review, or design pattern review.
Use when the user wants to execute an approved implementation plan and says any of "do it" (with a plan in scope), "lets do it" / "let's do it", "confirmed" (as approval to proceed on a plan), "implement the plan", "implement this", "execute the plan", "start implementing", "work through the plan", "implement the next phase", "build it out", "knock out the plan", or "/implement-plan PATH". Also use when a plan file (`./.plans/PLAN.md`, any `./.plans/*.md`, or legacy `./PLAN.md` / `./docs/plans/*.md`) is present and the user signals readiness to begin coding. Do NOT use when the user is still discussing, refining, or asking questions about the plan, nor when no plan exists — short imperatives like "do it" or "confirmed" alone are ambiguous; verify a plan is in scope before activating.
Use when the user asks to review the plan, sanity-check the plan, vet the plan, evaluate the plan, "is this plan ready", feasibility check on a plan, "review-plan PATH", or when another skill (like implement-plan) requests pre-flight plan evaluation before execution. Do NOT use when no plan file is in scope (the user is likely asking for a summary — use Read instead), nor when the user is asking about source code (use review-code), nor when the user wants documentation review (use review-documentation).