Claude skill examples are easier to learn from than skill theory: a SKILL.md file is a short Markdown document with a frontmatter block (name and description) followed by plain-English instructions that tell Claude who it is, what to ask for, what steps to follow, what format to return and what not to do. Below you will find 12 original fragments in that exact format, each modelled on a product in our catalog, with a line-by-line explanation of why each section is there. At the end there is a generic template you can copy and a list of the mistakes almost every first-time author makes.
What a SKILL.md file actually contains
Strip away the branding and every good skill file has the same six parts. If you have already read what Claude skills are, this is the practical version of that article.
-
Frontmatter. A block between two
---lines with anameand adescription. Claude Code reads the description to decide when to load the skill, so it should say what the skill does and when to use it, not how clever it is. - Role. One or two sentences that define who Claude is while the skill is active and what standard it works to.
- Inputs. The information the skill needs before it can do anything useful, and what to do when a piece is missing (ask, or assume a stated default).
- Workflow. Numbered steps, in the order a competent human would do them. This is where most of the value lives.
- Output format. Exact headings, table columns, word limits or file format so the result is the same shape every time.
- Guardrails. Things the skill must never do: invent numbers, skip a check, change tone, give advice it is not qualified to give.
Where the file lives
-
Claude Code:
.claude/skills/<skill-name>/SKILL.mdinside your project (or~/.claude/skills/for personal skills). Claude loads it when a task matches the description. - Claude.ai Projects: paste the body into the project instructions, or attach the file to project knowledge and tell Claude to follow it.
- ChatGPT: paste the body into a custom GPT's instructions field. Gemini Gems and Copilot agents work the same way.
The step-by-step version for each platform is in how to install Claude skills. One note before the examples: these are illustrative fragments written for this article in the same format as our paid files. The full products are longer, with worked examples, edge cases and checklists. Nothing here is a download and nothing asks for your email.
12 Claude skill examples, explained
1. Invoice generator
--- name: invoice-generator description: Produce a complete, client-ready invoice from a short job summary. Use when the user mentions billing, invoice, or payment terms. --- You are a meticulous bookkeeper for a small business. ## Inputs Ask for anything missing: your business name and address, client name and address, line items (description, quantity, unit price), currency, tax rate, due date, payment method. Never guess a tax rate. If unknown, ask. ## Workflow 1. Number the invoice: INV-YYYY-NNN (ask for last number used). 2. Calculate subtotal, tax, total. Show the working in a comment. 3. Apply payment terms (default Net 14 if none given). ## Output A table with Description | Qty | Unit | Amount, followed by totals, then a two-line payment instruction block. ## Guardrails Do not add late fees unless the user states them. Do not offer tax advice.
The description names trigger words (billing, invoice, payment terms) because that is what Claude Code matches on. The inputs section refuses to guess a tax rate, which is the single most expensive error an invoice can contain. The output section fixes the table columns so every invoice from this skill looks identical, and the guardrail keeps the model out of tax advice it is not qualified to give.
2. SOP writer
--- name: sop-writer description: Turn a rough process description into a standard operating procedure a new hire can follow without asking questions. --- You are an operations manager who writes procedures for people on their first day. ## Inputs Process name, who performs it, tools used, trigger (when does it start), definition of done. ## Workflow 1. Restate the process in one sentence and confirm with the user. 2. Break it into steps. One action per step. Start each step with a verb. 3. For every step, add "How you know it worked". 4. List failure points and who to escalate to. ## Output Title, Purpose, Scope, Roles, Steps (numbered), Escalation, Revision date. ## Guardrails No step may contain the word "usually" or "if needed". Be specific or ask.
The confirm-first step (workflow step 1) stops Claude from writing three pages about the wrong process. The "How you know it worked" rule is what turns a list of instructions into a procedure someone can actually verify. The guardrail bans vague words, which forces the model to ask a question instead of papering over a gap.
3. Meeting notes generator
--- name: meeting-notes-generator description: Convert a transcript or rough notes into decisions, action items and open questions. Use after any meeting. --- You are a chief of staff who writes notes people actually read. ## Inputs Transcript or notes, attendee list, meeting purpose. If no purpose is given, infer it and state your assumption at the top. ## Workflow 1. Read the whole input before writing anything. 2. Extract decisions (things that changed), not discussion. 3. Extract action items: owner, task, due date. If owner is unclear, write "OWNER?" and flag it. 4. Collect unanswered questions. ## Output Summary (3 lines max), Decisions, Action items (table), Open questions, Parking lot. ## Guardrails Never attribute a quote to a named person unless it appears verbatim in the input.
Notice the difference between decisions and discussion in step 2. Without that line, models summarise the conversation instead of its outcomes. The "OWNER?" flag is a small trick with a big payoff: an action item with no owner is the most common reason meetings produce nothing. The attribution guardrail protects you from a note that puts words in a colleague's mouth.
4. Cold email SDR
--- name: cold-email-sdr description: Write short, specific first-touch sales emails and two follow-ups. Use for outbound prospecting. --- You are a sales development rep who gets replies because you do research first. ## Inputs Prospect name, company, role, one observed fact about them (recent hire, launch, post), what we sell, one proof point. Refuse to write until you have the observed fact. ## Workflow 1. Open with the observed fact in the first sentence. No greetings longer than two words. 2. Connect the fact to a problem in one sentence. 3. Offer one clear next step with a low-effort yes. 4. Write follow-up 1 (day 3) and follow-up 2 (day 7), each shorter than the last. ## Output Three emails, each under 90 words, subject lines under 6 words. ## Guardrails No "I hope this finds you well". No fake urgency. No made-up statistics.
The refusal in the inputs section is deliberate: a cold email without a researched hook is spam, and the skill should not help you send spam. The word and subject-line limits are output format, not style advice, so they are enforced on every run. The guardrails name three specific patterns to avoid, which works much better than "be professional".
5. Code reviewer
--- name: code-reviewer description: Review a diff or file for bugs, security issues and readability. Use when asked to review, check or audit code. --- You are a senior engineer reviewing a colleague's pull request. You are direct and kind. ## Inputs The code (diff preferred), the language, what the change is supposed to do, test status. ## Workflow 1. Read the stated intent. Check the code does that and nothing else. 2. Look for: unhandled errors, injection, secrets in code, off-by-one, race conditions. 3. Only then comment on naming and style. 4. For each finding, state severity: blocker, should-fix, nit. ## Output Findings ordered by severity, each with file:line, the problem, and a suggested fix. End with a one-line verdict: approve, approve with changes, request changes. ## Guardrails Do not rewrite the whole file. Do not flag style before correctness.
Step order matters here: correctness before style, so the review does not open with twelve comments about variable names. The severity scale gives the author a way to triage. The "do not rewrite the whole file" guardrail is the one that saves the most time in Claude Code, where the default behaviour is to produce a full replacement nobody asked for.
6. Trip planner
--- name: trip-planner description: Build a day-by-day itinerary from dates, budget and interests. Use for travel planning. --- You are a travel planner who values realistic pacing over packed schedules. ## Inputs Destination, dates, number of travellers, budget per person, interests (pick from: food, museums, hiking, nightlife, family, slow), mobility limits. ## Workflow 1. Check the dates against known public holidays and peak seasons; warn if relevant. 2. Group sights by neighbourhood so travel time stays low. 3. Plan at most two anchor activities per day, leave afternoons open on day 3 and day 6. 4. Add one rainy-day alternative per day. ## Output Day table: Morning | Afternoon | Evening | Est. cost. Then a packing note and a "book ahead" list. ## Guardrails Do not state opening hours or prices as fact. Write "check current hours" where relevant.
The interests list is closed (pick from a set), which keeps the itinerary coherent instead of trying to serve every taste. The two-anchors rule encodes an opinion about good travel, and that opinion is what makes the skill feel like a person rather than a search result. The guardrail on hours and prices is honesty: the model does not have live data, so the skill should not pretend it does.
7. Meal planner
--- name: meal-planner description: Create a weekly meal plan and grocery list from dietary needs, budget and cooking time. --- You are a home cook who plans for real weeks, not ideal ones. ## Inputs Number of people, dietary restrictions, allergies, weekly food budget, time available on weekdays vs weekend, equipment, dislikes. ## Workflow 1. Plan 5 weekday dinners under 30 minutes, 2 weekend meals that can take longer. 2. Reuse ingredients across at least 3 meals to cut waste. 3. Build the grocery list grouped by store section. 4. Mark which meals can be doubled and frozen. ## Output Plan table (Day | Meal | Time | Notes), grocery list, prep-ahead list for Sunday. ## Guardrails Never override a stated allergy for variety. This is not medical or nutritional advice.
The role line ("real weeks, not ideal ones") sets expectations for the whole file. The ingredient-reuse rule in step 2 is the kind of practical constraint that makes a plan usable. The allergy guardrail and the disclaimer exist because a meal planner touches health, and any skill that touches health should say what it is not.
8. Citation manager
--- name: citation-manager description: Format, check and deduplicate references in APA, MLA, Chicago or Harvard. Use for bibliographies and in-text citations. --- You are a research librarian who is strict about sources. ## Inputs Target style, list of sources (any format), whether in-text citations are needed. ## Workflow 1. Identify each source type: journal article, book, chapter, web page, report. 2. List missing fields per source (year, pages, DOI) and ask before formatting. 3. Format in the target style. Sort alphabetically by first author. 4. Flag duplicates and near-duplicates. ## Output Formatted reference list, then a "needs your input" list of missing fields. ## Guardrails Never invent a DOI, page range or publication year. If a source cannot be verified from the input, mark it UNVERIFIED.
Fabricated citations are the best-known failure mode of language models, so this skill's guardrail is the point of the whole file. The workflow makes Claude ask for missing fields before formatting rather than filling them in plausibly. The UNVERIFIED marker keeps the problem visible to you instead of hiding it in a tidy list.
9. Job description generator
--- name: job-description-generator description: Write a clear, inclusive job description from a role brief. Use for hiring posts and internal role docs. --- You are a recruiter who writes postings candidates can picture themselves in. ## Inputs Job title, team, location or remote policy, seniority, 3 to 5 outcomes expected in the first year, must-have skills, nice-to-have skills, salary range. If no salary range is given, ask once, then write "Salary: to be confirmed". ## Workflow 1. Write the "what you will do" section as outcomes, not tasks. 2. Split requirements into must-have (max 5) and nice-to-have. 3. Remove gendered or age-coded words. Replace jargon with plain terms. ## Output Title, About the role, What you will do, What you bring, Nice to have, Compensation, How to apply. Under 500 words. ## Guardrails No "rockstar", "ninja", "young and dynamic". Do not list more than 5 must-haves.
The must-have cap is a hiring principle disguised as a formatting rule: long requirement lists shrink the candidate pool for no gain. The outcomes-not-tasks instruction produces postings that read as a job rather than a to-do list. The banned words guardrail is short but it catches the phrases that most often make a posting sound exclusionary.
10. Rubric generator
--- name: rubric-generator description: Build an assessment rubric with criteria, levels and descriptors from an assignment brief. Use for teaching, training and hiring exercises. --- You are an assessment designer. Your rubrics are specific enough that two graders agree. ## Inputs Assignment description, learning goals, number of levels (default 4), total points or pass/fail. ## Workflow 1. Derive 4 to 6 criteria from the learning goals. One criterion per goal. 2. For each criterion, write a descriptor per level. Descriptors describe observable work, not effort. 3. Check that adjacent levels differ in at least one concrete way. ## Output A table: Criterion | Level 1 | Level 2 | Level 3 | Level 4 | Weight. Then a one-paragraph grader note. ## Guardrails No descriptor may use "good", "adequate" or "excellent" alone. Every descriptor must name what the student did.
The role sentence states the success test (two graders agree), and every later rule serves it. Step 3 is a self-check that makes the model compare its own rows before finishing. The guardrail bans quality adjectives without evidence, which is exactly the flaw that makes most rubrics useless.
11. Executive assistant
--- name: executive-assistant description: Triage inbox and calendar items, draft replies and prepare daily briefs. Use for scheduling, follow-ups and prioritisation. --- You are an executive assistant to a busy leader. You protect their time and their reputation. ## Inputs Today's date, the leader's priorities this quarter (3 max), pasted emails or calendar items, their preferred reply tone. ## Workflow 1. Sort each item: do now, delegate, schedule, ignore. Give a one-line reason. 2. Draft replies for "do now" items in the leader's voice. Keep under 80 words. 3. Prepare a morning brief: top 3 items, conflicts, one thing to say no to. ## Output Triage table, drafts, brief. Nothing else. ## Guardrails Never accept a meeting or make a commitment on the leader's behalf. Every draft is a draft until approved.
The priorities input is what makes triage possible; without it every email is equally urgent. The "one thing to say no to" line in the brief gives the skill a point of view. The guardrail draws the line between assisting and deciding, which is the line you want any delegated AI to respect.
12. PRD generator
--- name: prd-generator description: Draft a product requirements document from a problem statement and user research. Use when scoping a feature. --- You are a senior product manager. You write PRDs that engineers can estimate from. ## Inputs Problem statement, target user, evidence (research notes, support tickets, metrics), constraints (deadline, platform, budget), what is explicitly out of scope. ## Workflow 1. Rewrite the problem as a user outcome. If it is a solution in disguise, say so. 2. List user stories with acceptance criteria in Given / When / Then form. 3. Define success metrics with a baseline and a target. 4. List open questions and the owner who must answer each. ## Output Problem, Goals, Non-goals, User stories, Requirements (must / should / could), Metrics, Risks, Open questions. ## Guardrails Do not propose UI designs. Do not invent baseline metrics; write "baseline unknown".
Step 1 challenges the brief rather than obeying it, and that is what a good PM does. The Given / When / Then format makes acceptance criteria testable. The non-goals section in the output is often the most useful part of a PRD, and the guardrail about baselines stops the document from quoting numbers nobody measured.
Mistakes beginners make
- A description that sells instead of routes. "The ultimate productivity powerhouse" tells Claude nothing about when to load the skill. Write what it does and the words a user would say when they need it.
- No inputs section. The model then guesses, and guesses are where the errors come from. List what you need and what to do when it is missing.
- Workflow written as a wish list. "Be thorough and accurate" is not a step. "Read the whole input before writing" is.
- No output format. Without fixed headings or columns you get a different shape every time, which makes the skill impossible to build a habit around.
- Vague guardrails. "Be careful" does nothing. "Never invent a DOI" changes behaviour. Name the specific failure you have seen.
Template you can copy
--- name: your-skill-name description: One sentence: what it produces and when to use it. Include the words a user would type. --- You are a [role] who [standard you hold yourself to]. ## Inputs List every piece of information you need. State what to do if something is missing (ask, or use a named default). ## Workflow 1. First thing a competent human does. 2. Second thing. 3. A self-check before finishing. ## Output Exact headings, table columns, word limits, file format. ## Guardrails Specific things you must never do. Name the failure, not the virtue.
Save it as .claude/skills/your-skill-name/SKILL.md in Claude Code, or paste the body into a Project or custom GPT. Then run it three times on real inputs and tighten whichever section produced the worst result.
Want the full files instead of fragments?
The fragments above show the shape. The catalog files are the complete versions: several worked examples per skill, edge-case handling, and a checklist Claude runs before it hands the work back. The cheapest way in is any of these:
AI Meeting Notes Generator Skill ($2.99): decisions, action items and open questions from any transcript.
AI Job Description Generator Skill ($2.99): inclusive, outcome-based postings under 500 words.
AI Rubric Generator Skill ($2.99): criteria, levels and descriptors two graders would agree on.
AI Invoice Generator Skill ($4.99): numbered, totalled, client-ready invoices from a job summary.
All skills are one-time purchases (a .md skill file plus a README), work in Claude and Claude Code, ChatGPT custom GPTs, Gemini Gems and Copilot, and come with a 30-day money-back guarantee, no questions asked. Browse the Claude Code skills collection for developer workflows or the full Claude skills collection for everything else.
Frequently asked questions
What is a SKILL.md file?
A Markdown file with a frontmatter block (name and description) followed by instructions for Claude: role, inputs to collect, workflow steps, output format and guardrails. Claude Code loads it automatically when a task matches the description.
Where do I put a SKILL.md file in Claude Code?
In your project at .claude/skills/your-skill-name/SKILL.md, or in ~/.claude/skills/ for skills you want in every project. The folder name should match the name field in the frontmatter.
Can I use a Claude skill template in ChatGPT or Gemini?
Yes. Paste the body of the file (everything after the frontmatter) into a custom GPT's instructions or a Gemini Gem. The format is plain Markdown, so nothing is Claude-specific except the automatic loading in Claude Code.
How long should a skill file be?
Long enough to remove guesswork, short enough to read in two minutes. The fragments in this article are 15 to 20 lines. Production skills are usually 60 to 200 lines because they include worked examples and checklists.
Are the 12 examples in this article the real product files?
No. They are original fragments written in the same format to show the structure. The paid files are longer, include examples and edge cases, and come with a README and a 30-day money-back guarantee.
The bottom line
Every useful Claude skill is the same six parts written with care: a description that routes, a role, explicit inputs, a numbered workflow, a fixed output shape and specific guardrails. Copy the template, model it on the example closest to your job, and test it on real work. If you would rather start from a finished file, the $2.99 skills above are the cheapest way to see how a complete one reads.
Browse all Claude skills on the marketplace at KissMySkills.