10 ready-to-use Claude skills for your job

---
name: weekly-status-report
description: Turns raw weekly notes into the team's standard status report with wins, blockers, metrics and next steps. Use when the user pastes rough notes, bullet points or a brain dump and asks for the weekly, the status report or the Monday update.
---
# Weekly status report

## Inputs
The user pastes unstructured notes. They may be incomplete. Never invent progress, metrics or dates that are not in the notes.

## Steps
1. Sort everything in the notes into four buckets: shipped this week, in progress, blocked, and next week.
2. Pull out any numbers mentioned and put them in the metrics line. If a metric is missing a comparison, ask for it once rather than guessing.
3. Write the summary line last, in one sentence, so it reflects what actually matters in the report.
4. For every blocker, name who or what unblocks it. A blocker with no owner is not finished.
5. List anything in the notes that was too vague to place, under "needs a decision from you", so nothing is silently dropped.

## Output format
**Summary:** one sentence.
**Shipped:** bullets, each starting with a verb, each with the outcome not the activity.
**In progress:** bullets with a percentage or a stage and an expected date.
**Blocked:** bullets, each with the blocker and the unblocker.
**Metrics:** [replace with your team's three or four numbers].
**Next week:** three bullets maximum, ranked.

## Rules
- Plain and factual. No filler, no adjectives doing the work of evidence.
- Keep the whole thing under [300] words. A status report nobody finishes is not a status report.
- Match the user's terminology for products, clients and internal systems exactly.
- If the week was bad, say so plainly and move to the unblock. Do not soften it into vagueness.

---
name: meeting-notes-to-actions
description: Converts a meeting transcript or rough notes into decisions, owned action items with due dates, and open questions. Use when the user pastes a transcript, meeting notes or a recording summary and asks for actions, follow-ups or next steps.
---
# Meeting notes to actions

## Steps
1. Read the whole input before writing anything, because decisions are often reversed later in the conversation.
2. Extract decisions first. A decision is something that was settled, not something that was discussed.
3. Extract action items. Every action needs a verb, an owner and a due date.
4. Where an owner was not named, write "owner not assigned" rather than guessing from who spoke.
5. Where a date was not given, infer from context only if the context is explicit, otherwise write "no date agreed".
6. Collect everything raised but not resolved into open questions, with who raised it.
7. Flag anything where two people appeared to agree to different things. This is the highest-value part of the output.

## Output format
**Decisions:** numbered list, one line each.
**Actions:** a table with columns action, owner, due date, source (a short quote or timestamp).
**Open questions:** bullets, each with who raised it.
**Possible misalignment:** bullets, or "none spotted".

## Rules
- Never invent an owner or a deadline. Missing is more useful than wrong.
- Keep each action to one sentence starting with a verb.
- Quote the source line for any action that could be contested later.
- Do not summarise the discussion. The user wants what happens next, not a recap.

---
name: brand-voice-drafting
description: Drafts and rewrites copy in the company's brand voice for emails, posts, landing pages and internal comms. Use when the user asks for a draft, a rewrite, or says to make something sound like us or on brand.
---
# Brand voice drafting

## Who we sound like
We are [warm, direct and specific]. We write for [describe your reader in one sentence, including what they already know]. We would rather be clear than clever.

## Always
- Sentence case in headings and subject lines.
- Short sentences. One idea each.
- Concrete nouns and real numbers over adjectives.
- Second person. Talk to the reader, not about them.
- Lead with what changes for the reader, then the detail.

## Never
- Em dashes. Use commas, full stops, parentheses or colons.
- Words on the banned list: [leverage, seamless, robust, delve, unlock, empower, game-changing, revolutionise].
- "It's not X, it's Y" constructions, or three-item lists used as a reflex.
- Exclamation marks outside genuine good news.
- Claims we cannot evidence. If a number is not supplied, leave a bracketed placeholder rather than inventing one.

## Steps
1. Ask what the piece is, who reads it, and what you want them to do, unless the user already said.
2. Draft it.
3. Re-read your own draft against the never list and fix anything that slipped through before showing it.
4. Give one alternative opening line, because the opening is the part most worth choosing between.

## Rules
- Match the length the user asked for. If they did not say, keep it shorter than feels right.
- Preserve every fact, name and number the user supplied, exactly.
- If the user pastes examples of our past writing, treat those as the highest authority on voice, above this file.

---
name: pre-send-review
description: Reviews a draft email, message, document or post before it is sent, checking clarity, tone, accuracy risk and how it could be misread. Use when the user pastes a draft and asks for a check, a review, a sanity check, or whether it is ready to send.
---
# Pre-send review

## Steps
1. Read the draft once for meaning and state, in one sentence, what you think the sender is asking for. If that does not match their intent, the draft has a clarity problem and everything else is secondary.
2. Check tone against the audience the user named. Flag anything that reads as passive aggressive, defensive, over-apologetic or unintentionally blunt, and quote the exact line.
3. Check for factual and commitment risk: dates, numbers, promises, anything that creates an obligation the sender may not be able to meet.
4. Check for the worst reasonable misreading. Assume the reader is busy, slightly stressed and skimming.
5. Check the ask. Is there exactly one, is it at the top, and is it obvious what happens next.

## Output format
**Verdict:** send as is, send with edits, or rework.
**What it currently asks for:** one sentence.
**Issues:** numbered, each with the quoted line, the problem in a few words, and a suggested replacement line.
**Worst reasonable misreading:** one short paragraph.
**Cleaned version:** the full revised draft.

## Rules
- Be direct. A review that tells the user it is fine when it is not is worthless.
- Never change the substance of what the sender is saying, only how clearly it lands.
- If the draft is genuinely good, say so briefly and stop, rather than manufacturing issues.

---
name: client-brief-builder
description: Turns a messy client or stakeholder request into a structured brief with objective, scope, deliverables, assumptions and the questions that still need answering. Use when the user pastes an email, call notes or a request and asks for a brief, a scope or a kickoff doc.
---
# Client brief builder

## Steps
1. Separate what was actually asked for from what was implied. Implied items go in assumptions, never in scope.
2. Write the objective as an outcome for the client's business, not a description of the deliverable.
3. List deliverables as countable things with a format and a quantity, for example "3 landing page variants, Figma".
4. Write an explicit out of scope list. This is the section that prevents the argument later, so make it specific.
5. Turn every gap into a numbered question, ordered by how much it blocks the work.
6. Estimate effort only as a range with the assumptions it depends on, and say clearly when there is not enough information to estimate.

## Output format
**Client and date**
**Objective:** one sentence, outcome-shaped.
**Success looks like:** two or three measurable statements.
**Deliverables:** numbered, with format and quantity.
**Out of scope:** bullets.
**Assumptions:** bullets, each flagged as confirmed or unconfirmed.
**Open questions:** numbered, blocking ones first.
**Rough effort:** a range plus what it assumes, or "cannot estimate until questions 1 to N are answered".

## Rules
- Never fill a gap with a plausible guess. An unconfirmed assumption clearly labelled is useful, a silent invention is not.
- Use the client's own words for their product, market and internal terms.
- Keep the whole brief on one page.

---
name: spreadsheet-cleanup
description: Cleans, deduplicates and summarises messy spreadsheet or CSV data, then reports what changed and what the numbers actually say. Use when the user uploads a spreadsheet or CSV and asks to tidy it, dedupe it, analyse it or summarise it.
---
# Spreadsheet cleanup and summary

## Steps
1. Profile the file first: row count, column names, data type per column, and the percentage of blanks in each. Report this before changing anything.
2. Flag structural problems: merged headers, multiple tables in one sheet, totals rows mixed into the data, dates stored as text, numbers stored as text.
3. Clean in this order: trim whitespace, standardise casing in category columns, parse dates to a single format, coerce numeric columns, then deduplicate.
4. For deduplication, state the key you matched on and show a sample of what was removed. Never drop a row without saying so.
5. Summarise: totals and averages for the numeric columns, the distribution of the main category column, and the three things in the data that are most likely to matter.
6. List data quality caveats that would make the summary misleading, for example a partial final month or a category that changed name mid-file.

## Output format
**Profile:** the before picture.
**Changes made:** numbered, each with how many rows or cells it affected.
**Clean file:** the cleaned data as a downloadable file.
**What the data says:** three to five findings, each with the number behind it.
**Caveats:** bullets.

## Rules
- Never delete data silently. Every removal is reported with a count.
- Never fill a blank with an assumed value unless the user asks. Blanks are information.
- If a finding could be explained by a data quality issue, say that alongside the finding.
- Show the calculation behind any number you quote.

---
name: internal-docs-answering
description: Answers questions about internal processes, policies and tools using only the team's uploaded documentation, and says clearly when the answer is not covered. Use when the user asks how something works here, what our policy on something is, or how to do an internal process.
---
# Internal docs answering

## Sources
Answer only from the documents in this project or the files the user has attached. General knowledge about how companies usually work is not a source and must never be presented as our policy.

## Steps
1. Search the available documents for the answer before writing anything.
2. Answer in two or three sentences first, then the detail. New starters need the answer at the top.
3. Cite the document name and section for every claim.
4. Where two documents disagree, show both, say which is more recently dated, and flag it as needing an owner to resolve.
5. Where the documents do not cover it, say "this is not covered in our docs" and suggest who is most likely to know, based on the ownership listed in the documents.
6. Note anything the user asked that suggests a gap worth documenting, at the end, under "worth adding to the docs".

## Output format
**Short answer:** two or three sentences.
**Detail:** the steps or the policy, quoted or closely paraphrased.
**Source:** document name and section.
**Not covered:** anything in the question the documents do not answer.

## Rules
- Never guess at a policy. An honest "not covered" protects people.
- Never soften a compliance, security or legal requirement into a suggestion.
- Keep the tone the way you would talk to someone on their first week: plain, unhurried, no internal jargon without a short definition.

---
name: customer-reply-drafting
description: Drafts replies to customer emails and support tickets in the team's support voice, ready for a human to review and send. Use when the user pastes a customer message and asks for a reply, a response or a draft.
---
# Customer reply drafting

## Steps
1. Identify what the customer actually wants, which is often not what they asked. Someone asking for a refund policy usually wants to know whether they are getting their money back.
2. Classify the message: question, complaint, bug report, cancellation risk, or feature request. The classification changes the shape of the reply.
3. Open by acknowledging the specific thing that happened to them, in their words, not a generic apology template.
4. Answer the actual question in the second paragraph. Do not bury it under context.
5. State clearly what you are doing next and by when. If you cannot commit to a date, say what you can commit to.
6. Where the reply depends on information you do not have, insert a bracketed placeholder rather than a plausible guess, and list those placeholders at the end for the human to fill.

## Output format
**Classification and sentiment:** one line.
**Draft reply:** the full email, subject line included.
**Placeholders to fill:** bullets, or "none".
**Escalate?** yes or no, with one sentence of reasoning.

## Rules
- This skill drafts. A person reviews and sends. Never present a draft as sent.
- Never promise a refund, a credit, a deadline or a fix that is not already policy.
- Never quote our terms unless the exact wording was provided. Cite the source if it was.
- Match the customer's formality level and language. Keep it under [180] words unless the issue genuinely needs more.

---
name: project-kickoff-plan
description: Turns a loosely defined project into a kickoff plan with goal, scope, milestones, risks, owners and a first week of concrete work. Use when the user describes a new project or initiative and asks for a plan, a kickoff doc or where to start.
---
# Project kickoff plan

## Steps
1. Restate the project as a goal with a measurable outcome and a date. If the user gave neither, ask for both once before planning.
2. Define done. Write the specific observable state that means this project is finished, in two or three sentences.
3. Break the work into milestones, not tasks. Each milestone is a thing that exists at the end of it.
4. For each milestone, list the two or three tasks that unblock everything else, and mark the dependency chain.
5. Write the risk register: what could stop this, how likely, and the specific early warning sign for each. Include the risk that the project turns out not to be worth doing.
6. Write week one as a concrete list of actions someone could start on Monday morning without asking a question.
7. Name the decisions that must be made by a human before work starts, and who should make them.

## Output format
**Goal:** outcome plus date.
**Done means:** two or three sentences.
**Milestones:** numbered, each with a target date and the unblocking tasks.
**Dependencies:** a short list of what must happen before what.
**Risks:** a table with risk, likelihood, early warning sign, mitigation.
**Week one:** five concrete actions.
**Decisions needed from a human:** numbered, with who decides.

## Rules
- Prefer fewer, larger milestones. Five is usually right and ten is usually a task list wearing a costume.
- Do not invent resourcing, budget or headcount. Ask.
- If the project as described cannot hit the date, say so in the first line rather than planning around a fiction.

---
name: promotion-evidence-log
description: Turns a week of work into structured promotion evidence with impact, scope and named beneficiaries, and assembles the entries into a review-ready case. Use when the user describes what they did this week, asks to log an achievement, or asks to prepare for a performance review.
---
# Promotion evidence log

## Steps
1. For each thing the user did, find the impact, not the activity. "Built a reporting skill" is activity. "Cut the weekly reporting cycle from 90 minutes to 10 for six people" is impact.
2. Push for numbers. If the user did not give one, ask a single specific question that would produce one, for example how long the task used to take or how many people it affects.
3. Classify each entry against the levels below, because promotion is about scope, not effort.
4. Name who else benefited. Work that made other people better is the strongest evidence there is, and it is the category people forget to record.
5. Write each entry in one sentence, in the format: what changed, for whom, by how much, evidenced by what.
6. When the user asks to prepare for a review, group all entries by level, lead with the highest scope, and draft the two-minute verbal version they will actually have to say out loud.

## Levels
- **Self:** made my own work better or faster.
- **Team:** made my team's work better or faster.
- **Org:** changed how people outside my team work.
- **External:** visible to customers, partners or the market.

## Output format
**Entry:** one sentence, with the number.
**Level:** self, team, org or external.
**Beneficiaries:** named people or teams.
**Evidence:** the doc, dashboard, thread or artefact someone could check.
**Gap:** what would move this entry up a level, or "none".

## Rules
- Never inflate. An unverifiable claim in a review is worse than a modest true one, because it invites a question you cannot answer.
- Every entry needs an artefact someone could actually open.
- Keep a running file. At review time, output the top eight entries by scope and a two-minute spoken version.

Above is a SKILL.md I want to adapt for my own job. I work as a [job title] at a [size and type of company], and the version of this task I actually do looks like this: [describe it honestly, including the format your team expects and the bits that always go wrong].

Before you rewrite anything, ask me the four questions you most need answered to make this genuinely fit my situation, and wait for my answers. Ask about my real output format, my audience, the rules I cannot break, and the failure mode I most want prevented.

Then rewrite the whole SKILL.md. Keep the frontmatter valid: a lowercase hyphenated name with no reserved words, and a third-person description that says both what it does and when to use it. Keep the body tight, cut anything that does not apply to me rather than leaving it in as an option, and add anything specific to my team that a stranger would not know.

Finish by packaging it as a zipped folder I can upload, and tell me one real task I should test it on first.