Cursor Skill Foundation
Overview
Build course-quality skills that are easy to trigger, concise in context, and practical in real projects. This is the meta-agent for turning knowledge into reusable agent behavior.
Decide the right artifact
Choose the smallest artifact that solves the problem:
| Need |
Use |
Example |
| Always-on project conventions |
Cursor rule in .cursor/rules/*.mdc |
Lint config, import order, naming |
| Reusable multi-step workflow |
Skill folder with SKILL.md |
PRD agent, debug agent, test agent |
| Bundle of several installed skills |
ASM expertise |
"Full-stack dev" combining 4 skills |
| One-off instruction for a single chat |
Plain prompt in chat |
"Refactor this function" |
If the workflow needs examples, checklists, or repeated steps across projects, prefer a skill.
Course defaults
- Cursor project rules live in
.cursor/rules/*.mdc
.cursorrules is legacy; keep only for compatibility
- Skill bundles are grouped with ASM via
asm create expertise ...
- Read references/course-defaults.md for the short decision list
Workflow
1. Define the job precisely
Before writing anything, answer:
- What job does the agent perform?
- What input does it expect (file, diff, idea, error)?
- What output must it produce (doc, code, report)?
- What phrases should trigger it?
- What is explicitly out of scope?
Write one sentence in this pattern:
This skill helps the agent [do X] when the user asks for [Y/Z] and should not be used for [A].
2. Design for triggers, not prose
The frontmatter description is the trigger surface. Pack it with:
- What the skill does (verb-first)
- When to use it (contexts)
- Common user phrases and synonyms
- Key artifacts or file types involved
Strong trigger terms:
- Domain:
PRD, architecture, test cases, debug, SQLite, design system, security, code review
- Actions:
create, improve, review, plan, refactor, implement, ship
Do not hide trigger terms only in the body.
3. Structure the body for execution
Put only the reusable workflow in SKILL.md. Use this skeleton:
- Gather first — what the agent must confirm before acting
- Workflow — numbered steps with decision points
- Output — exact deliverable shape (template or format)
- Quality checks — pass/fail criteria
- Common mistakes — top 3-5 failure modes
Rules for the body:
- Decision rules over background explanations
- Checklists over paragraphs
- Concrete output templates over vague guidance
- Failure modes the model actually hits, not theoretical warnings
- Max ~120 lines for the whole file; if longer, move reference material to
references/
4. Merge overlapping skills into one stronger skill
When several source skills cover the same domain:
- Keep the best workflow (fewest steps, clearest decisions)
- Keep the strongest checklist (most actionable gates)
- Keep the clearest output template (most concrete shape)
- Add unique techniques from each source (specific tools, patterns, frameworks)
- Remove tool-, repo-, or vendor-specific noise
- Rewrite for the learner's level, not the original repo
Result: one course-native skill stronger than three fragmented upstream ones.
5. Package for real student use
Every finished skill must answer:
- What should the agent ask first?
- What does it produce?
- What does "done" look like?
- What mistakes does it guard against?
- What specific tools or frameworks does it default to?
- What language should the agent use? Every skill must include a
## Language section instructing the agent to detect the user's language from the first message and use it for all questions and output. If the language is unclear, ask once before proceeding.
If a student can drop the skill into any project and immediately use it, the skill is ready.
Recommended structure
skill-name/
SKILL.md # Main workflow (≤120 lines)
references/ # Deep detail, checklists, examples
assets/ # Templates, starter files
scripts/ # Scaffolding helpers
Quality checklist
Before finishing a skill, verify:
Common mistakes
- Writing a mini-essay instead of a workflow
- Listing many optional paths without a default
- Hiding trigger terms outside frontmatter
- Copying upstream repo paths that don't exist in the student's project
- Turning a one-time prompt into a full skill
- Leaving framework choices vague ("use a testing library") instead of specific ("use Vitest for unit, Playwright for E2E")
Output
When creating or improving a skill, produce:
- A final
name (hyphenated, specific)
- A final trigger-rich
description (what + when + user phrases)
- A short workflow with numbered steps and decision points
- A concrete output shape with markdown template
- Framework/tool defaults stated explicitly
- A short list of mistakes to avoid
1---2name: cursor-skill-foundation3description: Create or improve Cursor-ready skills, rules, and expertises for a project. Use when a user wants to author a new SKILL.md, merge several overlapping skills into one stronger workflow, migrate lesson guidance into a reusable agent skill, or decide whether something should be a skill, a Cursor rule, or an ASM expertise.4---56# Cursor Skill Foundation78## Overview910Build course-quality skills that are easy to trigger, concise in context, and practical in real projects. This is the meta-agent for turning knowledge into reusable agent behavior.1112## Decide the right artifact1314Choose the smallest artifact that solves the problem:1516| Need | Use | Example |17|------|-----|---------|18| Always-on project conventions | Cursor rule in `.cursor/rules/*.mdc` | Lint config, import order, naming |19| Reusable multi-step workflow | Skill folder with `SKILL.md` | PRD agent, debug agent, test agent |20| Bundle of several installed skills | ASM expertise | "Full-stack dev" combining 4 skills |21| One-off instruction for a single chat | Plain prompt in chat | "Refactor this function" |2223If the workflow needs examples, checklists, or repeated steps across projects, prefer a **skill**.2425## Course defaults2627- Cursor project rules live in `.cursor/rules/*.mdc`28- `.cursorrules` is legacy; keep only for compatibility29- Skill bundles are grouped with ASM via `asm create expertise ...`30- Read [references/course-defaults.md](references/course-defaults.md) for the short decision list3132## Workflow3334### 1. Define the job precisely3536Before writing anything, answer:3738- What job does the agent perform?39- What input does it expect (file, diff, idea, error)?40- What output must it produce (doc, code, report)?41- What phrases should trigger it?42- What is explicitly out of scope?4344Write one sentence in this pattern:4546`This skill helps the agent [do X] when the user asks for [Y/Z] and should not be used for [A].`4748### 2. Design for triggers, not prose4950The frontmatter `description` is the trigger surface. Pack it with:5152- What the skill does (verb-first)53- When to use it (contexts)54- Common user phrases and synonyms55- Key artifacts or file types involved5657Strong trigger terms:5859- Domain: `PRD`, `architecture`, `test cases`, `debug`, `SQLite`, `design system`, `security`, `code review`60- Actions: `create`, `improve`, `review`, `plan`, `refactor`, `implement`, `ship`6162Do not hide trigger terms only in the body.6364### 3. Structure the body for execution6566Put only the reusable workflow in `SKILL.md`. Use this skeleton:67681. **Gather first** — what the agent must confirm before acting692. **Workflow** — numbered steps with decision points703. **Output** — exact deliverable shape (template or format)714. **Quality checks** — pass/fail criteria725. **Common mistakes** — top 3-5 failure modes7374Rules for the body:7576- Decision rules over background explanations77- Checklists over paragraphs78- Concrete output templates over vague guidance79- Failure modes the model actually hits, not theoretical warnings80- Max ~120 lines for the whole file; if longer, move reference material to `references/`8182### 4. Merge overlapping skills into one stronger skill8384When several source skills cover the same domain:85861. Keep the best workflow (fewest steps, clearest decisions)872. Keep the strongest checklist (most actionable gates)883. Keep the clearest output template (most concrete shape)894. Add unique techniques from each source (specific tools, patterns, frameworks)905. Remove tool-, repo-, or vendor-specific noise916. Rewrite for the learner's level, not the original repo9293Result: one course-native skill stronger than three fragmented upstream ones.9495### 5. Package for real student use9697Every finished skill must answer:9899- What should the agent ask first?100- What does it produce?101- What does "done" look like?102- What mistakes does it guard against?103- What specific tools or frameworks does it default to?104- **What language should the agent use?** Every skill must include a `## Language` section instructing the agent to detect the user's language from the first message and use it for all questions and output. If the language is unclear, ask once before proceeding.105106If a student can drop the skill into any project and immediately use it, the skill is ready.107108## Recommended structure109110```text111skill-name/112 SKILL.md # Main workflow (≤120 lines)113 references/ # Deep detail, checklists, examples114 assets/ # Templates, starter files115 scripts/ # Scaffolding helpers116```117118## Quality checklist119120Before finishing a skill, verify:121122- [ ] `name` is short, hyphenated, and specific123- [ ] `description` says both **what** and **when**, includes trigger phrases124- [ ] Body is concise and procedural (no essays)125- [ ] One clear output shape with a concrete template126- [ ] Specific framework/tool defaults are stated (not "pick any")127- [ ] Usable without reading sibling files128- [ ] Repo-specific assumptions removed or labeled129- [ ] Gather-first section prevents premature action130- [ ] Common mistakes list reflects real agent failure modes131- [ ] `## Language` section present — agent detects user language and asks once if unclear132133## Common mistakes134135- Writing a mini-essay instead of a workflow136- Listing many optional paths without a default137- Hiding trigger terms outside frontmatter138- Copying upstream repo paths that don't exist in the student's project139- Turning a one-time prompt into a full skill140- Leaving framework choices vague ("use a testing library") instead of specific ("use Vitest for unit, Playwright for E2E")141142## Output143144When creating or improving a skill, produce:1451461. A final `name` (hyphenated, specific)1472. A final trigger-rich `description` (what + when + user phrases)1483. A short workflow with numbered steps and decision points1494. A concrete output shape with markdown template1505. Framework/tool defaults stated explicitly1516. A short list of mistakes to avoid