You've written a skill, it works, and now you're staring at the next one wondering what else is worth the effort. The answer is usually whatever you've pasted into a chat three times this month.
Here are ten complete SKILL.md files, six for non-code work and four for code. Every one is a full file you can save and run. I took the format from Anthropic's Claude Code docs and the open Agent Skills spec, then pulled the frontmatter out of this post's source and parsed each file with a YAML parser, checking the name, description length and field names against the spec's rules. I did not run the skills themselves inside a live Claude session, so treat the instructions as drafts to tune on your own material. If you haven't written one before, start with how to write your first Claude skill, which covers where files go, how to test them and why a skill won't trigger. I won't repeat that here.
How to install any of these
Each skill is a folder with one SKILL.md inside. Save the file at ~/.claude/skills/<name>/SKILL.md for every project, or .claude/skills/<name>/SKILL.md inside a repo. The folder name must match the name line. Then type /<name> to run it directly, or ask in plain words and let Claude match the description.
A note on fields. Skills 1 to 7 use only name and description, which every skills-capable product accepts. Skills 8 to 10 use Claude Code extras (argument-hint, arguments, disable-model-invocation). Per the Claude Code docs, uploading a file with those keys to claude.ai or the Skills API fails validation, so keep them to Claude Code.
Which of these skills should you start with?
| # | Skill | Use it when | Works outside Claude Code |
|---|---|---|---|
| 1 | meeting-to-actions | You have a transcript or messy notes | Yes |
| 2 | reply-in-my-voice | You answer the same kinds of email daily | Yes |
| 3 | weekly-update | A manager wants a Friday status | Yes |
| 4 | proofread-only | You want errors fixed, not your style rewritten | Yes |
| 5 | contract-red-flags | You're reading a vendor or freelance contract | Yes |
| 6 | feedback-themes | You have a pile of survey or support comments | Yes |
| 7 | pr-description | Your branch is ready for review | Claude Code (uses a shell line) |
| 8 | explain-failing-test | A test is red and you don't know why | Claude Code |
| 9 | release-checklist | A deploy needs the same checks every time | Claude Code |
| 10 | fix-issue | You want a bug worked in isolation | Claude Code |
Pick the one matching a task you did this week. Skip the rest until you need them.
1. Meeting transcript to decisions and owners
Most meeting summaries fail the same way: they retell the conversation. This one extracts only what someone has to do something about, and refuses to assign an owner nobody named.
---
name: meeting-to-actions
description: Turns a meeting transcript or rough notes into decisions, action items with owners and dates, and open questions. Use when the user pastes a transcript, call notes, or says "what came out of the meeting", "action items", or "summarise this call".
---
# Meeting to actions
Read the transcript or notes the user provided. Output exactly these sections, in this order.
## Decisions
Things the group agreed on. One line each. Only include something if the transcript shows agreement, not just discussion.
## Actions
A table with columns: Action | Owner | Due | Source line.
- Owner is a person named in the transcript as taking it on. If nobody claimed it, write "Unassigned", never guess.
- Due is a date only if one was said. Otherwise write "No date".
- Source line is a short quote (under 12 words) so the user can find it.
## Open questions
Things raised but not resolved, and who was supposed to find out.
## Rules
- Do not summarise the discussion. If it isn't a decision, action or open question, leave it out.
- If the transcript is too garbled to tell who said what, say so at the top and mark affected rows "Check".
- Keep names as written. Do not infer job titles.
The "Source line" column is the part that earns its keep. It makes every row checkable in about two seconds, which is how you catch the one action the model invented.
2. Email replies that sound like you
The skill below only works if you fill in the voice section with real habits from your sent folder. Generic rules ("be warm but professional") produce generic email.
---
name: reply-in-my-voice
description: Drafts email replies in the user's own writing style from the message they paste. Use when the user says "reply to this", "draft a response", or pastes an email and asks for an answer.
---
# Reply in my voice
Draft a reply to the email the user pasted. Do not send anything.
## My voice (edit this part)
- I open with the answer, then the reason. No "I hope this finds you well".
- Short paragraphs, 1 to 3 sentences.
- I sign off with just my first name, no "Best regards".
- I say "no" plainly and offer one alternative.
- I use contractions. I never use exclamation marks to sound friendly.
## Process
1. Work out what the sender is actually asking. If there are two questions, answer both.
2. If a fact is needed that isn't in the email (a price, a date, a decision), put it in [square brackets] for the user to fill in. Never invent it.
3. Write the reply. Under 120 words unless the email needs more.
4. After the draft, list in one line anything you assumed.
## Never
- Promise a deadline, discount or commitment the user hasn't stated.
- Match an angry tone. Stay level.
Rule 2 is the safety net. A model asked to reply to "can you do it by Friday?" will cheerfully say yes unless told the date is yours to decide.
3. A weekly status update that doesn't pad
---
name: weekly-update
description: Writes a short weekly status update from the user's rough notes, commit log or task list. Use when the user asks for a weekly update, status report, Friday summary, or "what did I do this week".
---
# Weekly update
Turn the user's raw notes into a status update a busy manager reads in 30 seconds.
## Format
**Done:** 3 to 5 bullets. Outcomes, not activities ("Shipped invoice export", not "Worked on invoices").
**Next:** up to 3 bullets for next week.
**Blocked / need from you:** only real blockers, each with who can unblock it. If none, write "Nothing".
**Risk:** one line, only if a date or scope is genuinely at risk. Omit otherwise.
## Rules
- Use only what is in the notes. If the notes are thin, produce a thin update and say "Notes were short, add detail if this is incomplete".
- No adjectives like "great progress" or "significant".
- Numbers go in only if the user supplied them.
- Keep the whole thing under 150 words.
4. Proofreading without rewriting your voice
This is the skill for people who've been burned by "fix my grammar" turning their draft into someone else's prose.
---
name: proofread-only
description: Corrects spelling, grammar, punctuation and typos in the user's text without changing wording, tone or structure. Use when the user says "proofread", "fix typos", "check grammar" or "clean this up but keep my wording".
---
# Proofread only
Fix errors. Do not improve the writing.
## Allowed changes
- Spelling, typos, wrong homophones (their/there)
- Punctuation and capitalisation
- Clear grammar errors (subject-verb agreement, tense slips, missing words)
## Not allowed
- Rephrasing a sentence because you'd write it differently
- Swapping words for "better" ones
- Reordering, cutting or adding sentences
- Changing the user's dialect (keep British or American spelling as written)
## Output
1. The corrected text, complete.
2. Below it, a list of every change as: "original" -> "corrected". If you made more than 25 changes, say so and list the first 25.
3. If something reads awkwardly but isn't an error, mention it in one line under "Not changed" and leave it alone.
The change list matters. If you can't see what was touched, you can't trust that nothing else was.
5. A first pass over a contract
This one needs a blunt disclaimer built in, and it has one. It finds the clauses worth asking a professional about. It doesn't tell you whether to sign.
---
name: contract-red-flags
description: Reads a contract, NDA or freelance agreement and flags clauses that deserve a closer look (payment, termination, liability, IP ownership, auto-renewal, exclusivity). Use when the user pastes or uploads a contract and asks what to watch out for. Not legal advice.
---
# Contract red flags
You are doing a first-pass read for a non-lawyer. You are not giving legal advice, and you must say so once, briefly, at the top.
## Check each of these and quote the clause
1. **Payment:** amount, due date, late fees, who pays expenses.
2. **Term and renewal:** start, end, automatic renewal, notice period to cancel.
3. **Termination:** who can end it, for what reason, with how much notice, and what is owed afterwards.
4. **Liability and indemnity:** caps, and whether one side carries risk the other doesn't.
5. **IP ownership:** who owns the work product, and when ownership transfers (on creation or on payment).
6. **Exclusivity and non-compete:** what the user is stopped from doing, for how long.
7. **Anything unusual:** clauses that don't look like standard boilerplate.
## Output
A table: Clause | What it says (plain English) | Why it matters | Question to ask.
Rate each row Low / Medium / High concern.
## Rules
- Quote the exact words for every clause you flag, with the section number if there is one.
- If a topic above isn't covered in the document, say "Not addressed". Silence can be a risk too.
- Never say a contract is "fine" or "safe". Say what you found and what you couldn't assess.
- If the document refers to schedules or exhibits that weren't provided, list them as missing.
6. Survey comments to themes
For a pile of customer or user comments. The key instruction is counting: without it you get "users want better onboarding" with no sense of how many said so.
---
name: feedback-themes
description: Groups a batch of customer feedback, survey comments, reviews or support messages into themes with counts and example quotes. Use when the user pastes or attaches feedback and asks what people are saying, what the top complaints are, or for a themes summary.
---
# Feedback themes
Work through every comment the user provided.
## Process
1. Read all comments first. Draft 4 to 8 themes from what is actually there, not from what a product usually gets.
2. Assign each comment to its main theme. A comment with two issues counts once per issue.
3. Count them. Report counts as "n of total".
## Output
For each theme, in descending order of count:
- **Theme name** (n of total)
- One sentence on what people are saying.
- Two verbatim quotes, shortest ones that make the point.
Then:
- **Praise worth protecting:** what people like, with counts.
- **Unclear or off-topic:** how many comments you couldn't place.
## Rules
- Quotes must be copied exactly, never tidied.
- If there are fewer than 20 comments, say the counts are too small to trust and focus on the quotes.
- Do not recommend product changes unless asked. Report what people said.
If you've got more than a few hundred comments, ask Claude to do the counting with a script instead of reading them all by eye. Counting by reading is where models drift.
7. A pull request description from your actual diff
This is the first skill in the list that runs a command. The line starting with ! is executed by Claude Code before Claude reads the skill, so the diffstat in the prompt is real. Per the docs, if that command fails the whole invocation aborts, so change main to your base branch. I ran git diff --stat main...HEAD on this site's repo to confirm the syntax prints a diffstat.
---
name: pr-description
description: Writes a pull request title and description from the current branch's changes. Use when the user asks for a PR description, PR summary, or says the branch is ready for review.
---
# PR description
## Files changed on this branch
!`git diff --stat main...HEAD`
## Task
Write a pull request description for the changes above. If you need more detail than the diffstat gives, read the specific files or run `git log main..HEAD --oneline` yourself.
## Format
**Title:** under 70 characters, imperative mood ("Add CSV export to invoices").
**What and why:** 2 to 4 sentences. Lead with the problem, then the change.
**How to test:** numbered steps a reviewer can follow. Only include steps you can justify from the code you read.
**Risk:** what could break, and what you did not change on purpose. If you don't know, say "Unknown".
## Rules
- Describe what the code does, not what you assume the author intended.
- Do not claim tests pass unless you ran them in this session.
- No emoji, no "This PR".
8. Explain a failing test (and take the test name as an argument)
This is where $ARGUMENTS earns its place. Type /explain-failing-test tests/test_billing.py::test_refund and the argument lands in the prompt. The docs give argument-hint as the field that shows a hint in autocomplete.
---
name: explain-failing-test
description: Diagnoses why a specific test fails and proposes the smallest fix. Use when the user names a failing test, pastes a test failure, or asks why a test is red.
argument-hint: "[test path or name]"
---
# Explain failing test
Target: $ARGUMENTS
If no target was given, ask which test, or look at the failure output the user pasted.
## Process
1. Run the target test once and read the real failure. Do not guess from the test name.
2. Read the test, then the code it exercises.
3. Decide which it is, and say so first: **bug in the code**, **bug in the test**, or **environment/flaky**.
4. Explain the cause in under five sentences, citing file and line.
5. Propose the smallest change that fixes it. Show it as a diff. Do not apply it until the user agrees.
## Rules
- Do not delete, skip or loosen an assertion just to make the test pass. If you think the assertion is wrong, explain why and ask.
- If it passes when you run it, run it three times and report whether it is flaky.
- Never touch files outside the area under test without saying so.
The "do not loosen an assertion" rule is the one I'd keep even if you cut everything else. Without it, "make the test pass" has an easy and wrong answer.
9. A release checklist that only you can start
Anything with side effects should be manual-only. disable-model-invocation: true means Claude can't decide that now seems like a good time to ship. This one also uses named arguments, so /release-checklist staging fills $env.
---
name: release-checklist
description: Walks through pre-release checks for a deploy to the named environment and reports what passes and what needs a human. Manual only.
disable-model-invocation: true
argument-hint: "[environment]"
arguments: env
---
# Release checklist for $env
Work through these in order. Stop and report at the first failure. Do not deploy anything yourself.
1. Working tree is clean and on the expected branch (`git status`, `git branch --show-current`).
2. Tests pass. Run the project's test command and report the real result.
3. Lint and type checks pass.
4. No uncommitted migrations, and any migration files in this branch are listed for human review.
5. The changelog or release notes mention the changes in `git log --oneline` since the last tag.
6. No `TODO`, `console.log` or debug flags added in the diff against the last tag.
## Output
A table: Check | Result (Pass / Fail / Could not check) | Evidence.
End with one line: "Ready for $env" or "Not ready: <first failing check>".
## Rules
- "Could not check" is a valid result. Never write Pass for something you didn't run.
- If $env is empty, ask which environment before starting.
10. Work a bug in isolation
The docs describe context: fork as running the skill in a forked subagent that gets the skill content as its prompt, without your conversation history. That's useful when you want a bug investigated without your half-finished chat polluting it. agent: Explore is one of the subagent types the docs list. I picked Explore because this skill should investigate and report, not edit; the instructions also say not to write files, so it holds even if you swap the agent.
---
name: fix-issue
description: Investigates a bug report or issue number in a fresh context and reports root cause and a proposed fix. Use when the user gives an issue number or bug description to investigate.
argument-hint: "[issue number or description]"
disable-model-invocation: true
context: fork
agent: Explore
---
# Investigate issue
Issue: $ARGUMENTS
You are starting with no prior conversation. Work only from the issue text and the code.
1. Restate the symptom in one sentence, using the issue's own words.
2. Find where in the code that behaviour is produced. List the files and functions you read.
3. Identify the most likely root cause. Give your confidence (low, medium, high) and the evidence for it.
4. Propose a fix and the test that would prove it. Do not write to any file.
5. List what you could not determine and what you would check next.
Report back in under 300 words. The parent session will decide what to implement.
What do these skills have in common?
Look back across them and the same five habits show up. They're the part worth stealing even if you never use my skills.
- A fixed output shape. Sections, tables, word limits. Vague output comes from vague asks.
- A rule for "I don't know". Unassigned owner, "Not addressed", "Could not check". Without it the model fills the gap with something plausible.
- Evidence in the output. Source lines, quoted clauses, file and line. You verify faster than you could re-do the work.
- A short "never" list. Three to five lines naming the failure you've actually seen.
- Descriptions written in your own words. Each one starts with what the skill does, then "Use when" with phrases a person would type.
When a skill needs a rule to hold every time, not most times, move it out of the skill and into a hook; the skills, hooks and subagents guide explains the trade-off. For standing preferences that apply to everything, a CLAUDE.md is the better home.
A note on the older lesson
The site's skills and reusable workflows lesson uses a single flat markdown file with no frontmatter. That isn't the folder-plus-SKILL.md layout in Anthropic's current docs. Take its ideas, and take the file format from this post.
Sources: Anthropic's Claude Code skills documentation and the open Agent Skills specification, both read on 2026-10-08. Claude Code ships often, so if a field behaves differently on your version, the docs win over this post.
