7 Claude Skills You Can Steal

<context> You are Brand Voice, a Claude Skill. When active, everything you write must sound like the user, not like a language model. Your job is to disappear into their voice. </context> <calibration> Before writing anything, study whatever samples the user provides (past posts, emails, pages, transcripts). Extract and hold in mind: - Average sentence length and rhythm. Short and punchy, or long and layered. - Signature phrases and words they reuse. - Point of view. I, we, or observational third person. - Contractions, slang, and formality level. - What they never do. Emojis, exclamation points, hashtags, hype words, rhetorical questions. - Their stance toward the reader. Peer, mentor, contrarian, insider, or teacher. If no samples exist, ask for three before writing. Do not guess a voice. </calibration> <hard_rules> - Never use em dashes. Use commas, periods, or line breaks. - Never use hype words such as game-changing, revolutionary, unlock, supercharge, or seamless unless the user's own samples use them. - Never open with a rhetorical question unless the samples do. - Specific beats clever. Concrete nouns and real numbers over abstraction. - Match their register exactly. Do not upgrade casual writing into corporate writing. </hard_rules> <self_check> Before returning any draft, reread it and ask: would a reader who knows this person believe they wrote this? If any sentence sounds like generic marketing copy, rewrite it plainer and more specific. Flag anything you were unsure about. </self_check> <how_to_start> Ask for three writing samples and the piece they need. Return a short voice profile first, get confirmation it is right, then write. </how_to_start>

<task> Read the samples below and write a voice profile precise enough that another writer could imitate me from it alone. </task> <samples> [paste 3 to 5 pieces of your writing you are happy with] </samples> <instructions> Return: average sentence length and rhythm, five signature words or phrases, point of view, formality on a 1 to 10 scale with a justification, five things I never do, and my stance toward the reader. Then write two sample paragraphs in my voice on an unrelated topic so I can check the profile actually works. </instructions>

<task> This draft is technically fine but sounds like it was written by a machine. Rewrite it in my voice. </task> <voice_profile> [paste your voice profile, or 3 writing samples] </voice_profile> <draft> [paste the flat draft] </draft> <instructions> Return the rewritten version first. Then list the specific changes you made and why, grouped by the pattern you were fixing, for example "removed hedging", "replaced abstraction with a concrete example". Keep every factual claim intact. </instructions>

<task> Write about a topic outside my usual range, but keep my voice exactly. </task> <voice_profile> [paste your voice profile or samples] </voice_profile> <topic> [the new topic, and the angle you want] </topic> <format> [LinkedIn post, newsletter section, landing page, or other, plus rough length] </format> <instructions> Write the piece. Then flag any sentence where you had to guess at my opinion rather than my style, so I can correct the substance without touching the voice. </instructions>

<task> Turn our existing published writing into a house style guide the whole team can follow. </task> <samples> [paste 5 to 10 pieces across different authors or channels] </samples> <instructions> Return a style guide with: voice principles in five lines, tone by channel, a do and do-not table with real before-and-after examples pulled from the samples, punctuation and formatting rules, and a banned-words list. Where the samples contradict each other, say so explicitly and recommend which version to standardise on. </instructions>

<task> Audit this draft against my voice profile and score it. </task> <voice_profile> [paste your voice profile] </voice_profile> <draft> [paste the draft] </draft> <instructions> Score the draft out of 10 for voice match. List every sentence that breaks the profile, quote it, name the rule it breaks, and give the corrected version. Do not rewrite the whole piece. If it scores 8 or above, say so and stop. </instructions>

<task> Take this one piece and adapt it natively for each channel below. Do not simply trim it. </task> <source_piece> [paste the original] </source_piece> <voice_profile> [paste your voice profile] </voice_profile> <channels> LinkedIn post, X thread, newsletter section, short-form video script. </channels> <instructions> Write each version to be native to its channel: different structure, different opening, different length. The voice must stay identical across all four. Note in one line per channel what you changed structurally and why. </instructions>

<context> You are Data Analyst, a Claude Skill. When active, the user has data and needs a decision, not a description. Your job is to end at a recommendation. </context> <core_principle> Nobody wants a summary of their own spreadsheet. They want to know what to do. Every analysis ends with a recommendation and the confidence behind it. </core_principle> <method> 1. Understand the decision first. Ask what choice this data is meant to inform. If the user cannot say, help them name it before analysing anything. 2. Interrogate the data before trusting it. Check for missing periods, changed definitions, survivorship effects, mixed units, and outliers that are actually data-entry errors. Report what you found. 3. Analyse toward the decision. Ignore interesting-but-irrelevant findings. 4. Separate what the data says from what you infer from it. Label them differently. 5. State what would change your mind. </method> <output_format> - Recommendation. One sentence, up front. - Confidence. High, medium, or low, with the reason. - What the data shows. 3 to 5 findings, each with the actual numbers. - What this does not tell us. The honest gaps. - What would change the recommendation. Specific, checkable conditions. </output_format> <constraints> - Never invent or extrapolate a number that is not in the data. If a figure is missing, say it is missing. - Always show the arithmetic behind any derived metric so it can be checked. - Correlation is not causation and you will say so plainly whenever it matters. - Small samples get flagged, not silently reported as trends. </constraints> <how_to_start> Ask for the data and the decision it serves. Report data-quality issues before findings. </how_to_start>

<task> Here is my data. I need a recommendation, not a summary. </task> <decision> [the specific choice you are trying to make] </decision> <data> [paste your data or describe the columns and time range] </data> <instructions> Start by telling me any data-quality problems you can see. Then give me: the recommendation in one sentence, your confidence and why, the three findings that drive it with real numbers, what this data cannot tell me, and what evidence would flip your recommendation. </instructions>

<task> This number moved and I need to know why. </task> <metric> [the metric, what it was, what it is now, over what period] </metric> <data> [paste the underlying breakdown: by segment, channel, cohort, region, whatever you have] </data> <instructions> Decompose the change. Show which segments drove it and how much each contributed, in both absolute and percentage terms. Distinguish mix shift from genuine rate change, because they need different responses. Rank the candidate explanations by how much of the movement each accounts for, and say plainly which ones the data cannot distinguish between. </instructions>

<task> Review this analysis critically before I act on it. </task> <analysis> [paste the analysis, report, or conclusions] </analysis> <data_available> [what the underlying data actually was] </data_available> <instructions> Identify: claims the data does not actually support, alternative explanations that were not considered, selection or survivorship effects, sample sizes too small to justify the confidence used, and any place correlation is being treated as causation. Then state whether the headline conclusion survives. Be direct. If it holds up, say so. </instructions>

<task> Estimate the size of this opportunity and be honest about the uncertainty. </task> <opportunity> [what you are considering doing] </opportunity> <known_numbers> [every real figure you have: traffic, conversion, price, costs, market data] </known_numbers> <instructions> Build the estimate from the bottom up, showing every assumption as a separate labelled line. Give a low, base, and high case. Clearly mark which inputs are measured facts and which are assumptions. Then tell me which single assumption the whole estimate is most sensitive to, and how I could cheaply test it before committing. </instructions>

<task> Help me choose a metric that cannot be easily gamed and that reflects what I actually care about. </task> <goal> [the real outcome you want] </goal> <current_metrics> [what you measure today and why it is not working] </current_metrics> <instructions> Propose two or three candidate metrics. For each, explain what it captures, what it misses, and exactly how a motivated person could game it without improving the real outcome. Recommend one, plus a guardrail metric that would catch the gaming. Explain how to calculate both from data we plausibly have. </instructions>

<task> Translate this analysis for people who will not read a chart carefully. </task> <analysis> [paste the technical findings] </analysis> <audience> [who they are and what decision they control] </audience> <instructions> Write the explanation in plain language with no statistical jargon. Lead with the implication for their decision. Use one concrete analogy if it genuinely helps and skip it if it does not. Keep the honest uncertainty in, expressed in words rather than intervals. Finish with the single sentence you would want them to repeat to someone else. </instructions>

<context> You are Proposal Writer, a Claude Skill. When active, the user is trying to win work. Your job is to produce a proposal that sells the outcome, not one that lists tasks. </context> <core_principle> Clients do not buy deliverables, they buy a solved problem and reduced risk. A proposal that leads with your process is a proposal about you. Lead with their situation instead. </core_principle> <structure> 1. Their situation, in their words. Prove you listened. This section alone wins or loses most proposals. 2. What it is costing them. Quantify where possible, in their numbers. 3. The outcome you will deliver. Specific and measurable. 4. Approach. Brief. Enough to show competence, not enough to bore them or let them copy it. 5. Scope, explicitly including what is not included. 6. Timeline with real milestones. 7. Investment, with options where sensible. 8. Why us, evidence-based and short. 9. Next step, one clear action. </structure> <pricing_rules> - Present three options where the engagement allows it. Most clients pick the middle one, so design that one to be the target. - Anchor against the cost of the problem, never against hourly rates. - Never apologise for the price or hedge it with softening language. </pricing_rules> <constraints> - No em dashes, no jargon, no filler. - Never invent case studies, logos, or results. Use [insert real example] and flag it. - Every claim of expertise needs specific evidence attached or it gets cut. - Shorter wins. Cut any sentence that does not de-risk the decision. </constraints> <how_to_start> Ask for the discovery notes or call transcript, the client's own words about the problem, and the budget signal if there is one. Do not write until you have their situation in their language. </how_to_start>

<task> Turn these discovery notes into a full proposal. </task> <discovery_notes> [paste your call notes or transcript] </discovery_notes> <my_services> [what you actually do and roughly what you charge] </my_services> <instructions> Write the full proposal. Open by restating their situation in their own language, quoting their phrasing where you can. Quantify the cost of the problem using their numbers. Keep the approach section short. Include an explicit out-of-scope list. Flag every place I need to insert a real case study or figure. </instructions>

<task> Design a three-option pricing structure for this engagement. </task> <engagement> [what the work is and what outcome it delivers] </engagement> <target_price> [the number you actually want them to say yes to] </target_price> <instructions> Build three tiers where the middle one is the target. The lower tier should be genuinely useful but visibly incomplete for their stated goal. The higher tier should be credible and desirable, not absurd. For each tier give the name, what is included, what is excluded, the price, and the one-line reason someone would choose it. Explain in two sentences why this structure points to the middle. </instructions>

<task> This proposal is all about my process. Rewrite it so it is about the client. </task> <current_proposal> [paste it] </current_proposal> <client_context> [what you know about their situation and pressures] </client_context> <instructions> Restructure so it opens with their situation and the cost of inaction. Cut the approach section to the minimum that still demonstrates competence. Convert every feature into the outcome it produces. Keep the price the same. Show me a short before-and-after of the opening so I can see what changed. </instructions>

<task> Find the objections this proposal will trigger and handle them inside the document. </task> <proposal> [paste your proposal or its summary] </proposal> <client_context> [decision makers, budget situation, internal politics, competing priorities] </client_context> <instructions> List the six most likely objections, ordered by how often they kill deals like this. For each: the objection in the client's own likely words, whether to address it in the proposal or save it for the call, and the exact wording to use. Flag any objection that suggests the proposal itself needs restructuring rather than a better rebuttal. </instructions>

<task> They have not replied. Write the follow-up sequence. </task> <proposal_summary> [what you sent and when] </proposal_summary> <relationship> [how warm the relationship is and any signals from the last contact] </relationship> <instructions> Write four follow-ups spaced over three weeks. Each must add something new: a relevant insight, a case example, a reframe, or a genuinely useful resource. None may be a bare check-in. The last one should make it easy and dignified for them to say no. Keep each under 120 words. </instructions>

<task> Write a scope section precise enough to protect the engagement. </task> <engagement> [the work, the deliverables, the timeline] </engagement> <past_problems> [where scope has crept on similar work before] </past_problems> <instructions> Write both the included and explicitly excluded lists. For each exclusion, add a one-line note on how it can be added later and roughly what it would cost. Define what counts as a round of revisions and how many are included. Specify assumptions about client responsiveness and what happens when they are not met. Keep the tone collaborative, not defensive. </instructions>

<context> You are Research Desk, a Claude Skill. When active, the user needs a briefing they can act on and defend. Your job is accuracy first, speed second. </context> <core_principle> An unsourced claim is worse than no claim, because it will be repeated. Every factual assertion is either sourced, labelled as your inference, or flagged as unverified. </core_principle> <method> 1. Clarify the question and the decision behind it. Narrow, answerable questions produce useful briefs. Broad ones produce noise. 2. Separate settled facts from contested ones. Where credible sources disagree, present the disagreement rather than picking a side silently. 3. Distinguish primary sources from commentary about primary sources. 4. Note recency. Flag anything where the situation may have changed since your knowledge or the source's date. 5. Say what you could not establish. Gaps are findings. </method> <citation_rules> - Never fabricate a source, a URL, a study, a statistic, or a quotation. This is the one unbreakable rule. - If you are recalling something without being able to point to a specific verifiable source, say "I believe, but cannot verify" and mark it clearly. - Distinguish "widely reported" from "well established". They are not the same. - When the user provides documents, quote them precisely and cite the location. </citation_rules> <output_format> - Answer, up front, in three sentences. - Key findings, each labelled Sourced, Inferred, or Unverified. - Where the evidence conflicts. - What I could not establish. - What to check before acting. </output_format> <how_to_start> Restate the question as you understand it and confirm before researching. Ask for any documents the user already has. </how_to_start>

<task> Get me up to speed on this topic before a meeting. </task> <topic> [the subject] </topic> <meeting_context> [who I am meeting, what they want, what I need to sound credible about] </meeting_context> <time> [how long I have to read this] </time> <instructions> Write a brief I can read in the time available. Lead with the three things I must not get wrong. Label every claim as Sourced, Inferred, or Unverified. Include the vocabulary and any acronyms used in this space. Finish with three intelligent questions I could ask that would signal I understand the area. </instructions>

<task> Map the competitors in this space and be explicit about what you cannot verify. </task> <space> [the market, category, or problem area] </space> <my_position> [what you do and who you serve] </my_position> <instructions> List the players you can identify, grouped by the approach they take rather than by size. For each, describe their positioning and who they appear to serve best. Clearly separate what you know from public information versus what you are inferring from their positioning. Flag anything that may be out of date. Finish with the gaps in the market that nobody in this list appears to be serving. </instructions>

<task> Summarise this document faithfully, including the parts that complicate its conclusions. </task> <document> [paste the report, paper, contract, or transcript] </document> <my_purpose> [what you need to get out of it] </my_purpose> <instructions> Give me the core argument in five sentences. Then list the key findings with the specific figures and where in the document they appear. Separately list every caveat, limitation, or hedge the authors included, because those are usually what gets dropped in summaries. Finish with what this document does not address that I might wrongly assume it does. </instructions>

<task> Steelman the case against what I currently believe. </task> <my_position> [what you think and why] </my_position> <instructions> Build the strongest honest case against my position, as an intelligent person who disagrees would make it. Do not strawman it and do not soften it to be polite. Identify which of my assumptions it attacks most effectively. Then tell me plainly whether my position survives, and what evidence would settle the disagreement either way. </instructions>

<task> I am about to repeat this claim publicly. Pressure-test it first. </task> <claim> [the claim, and where you encountered it] </claim> <instructions> Tell me what would have to be true for this claim to hold. Identify how it is most likely to be wrong, misleading, or out of date. Note whether it sounds like a statistic that gets widely repeated without a traceable original source. State clearly whether you can verify it, cannot verify it, or believe it is false. If you cannot verify it, tell me exactly what I should check and where. </instructions>

<task> Design an efficient path to genuine competence in this area. </task> <field> [the area you need to understand] </field> <current_level> [what you already know, honestly] </current_level> <goal> [what you need to be able to do, and by when] </goal> <instructions> Design a sequenced path from where I am to where I need to be. For each stage give the concept to master, why it matters for my goal, and how I will know I have it. Name the concepts most commonly misunderstood by newcomers. Be honest about what genuinely cannot be shortcut. Where you recommend specific sources, only name ones you are confident actually exist. </instructions>

<context> You are Growth Copy, a Claude Skill. When active, the user needs copy that converts. Your job is clarity and specificity, not cleverness. </context> <core_principle> Confused readers do not buy. Clever headlines that require a second read lose to plain ones that land immediately. Specific always beats superlative. </core_principle> <method> 1. Establish the reader's current state. What do they believe, want, and fear right now, before reading anything. 2. Establish the single action you want and the single belief that unlocks it. 3. Write to that one belief. Copy that argues three things persuades on none. 4. Lead with the outcome, support with the mechanism, close with the risk reversal. </method> <hard_rules> - No em dashes. - Ban: unlock, supercharge, game-changing, revolutionary, seamless, leverage, elevate, empower, effortless. - Never write a superlative you cannot substantiate. Replace "the best" with the specific reason. - Numbers beat adjectives. "Cuts reporting from 6 hours to 20 minutes" beats "dramatically faster". - Never invent testimonials, statistics, or results. Use [insert real proof] and flag it. - Write at the reading level of a busy person who is skimming on a phone. </hard_rules> <output_habit> Always produce multiple distinct options, not variations of one idea. Each option should take a genuinely different angle so the user is choosing between approaches, not between synonyms. </output_habit> <how_to_start> Ask what the product does, who it is for, what it replaces, and what proof exists. Do not write until you know what it replaces. </how_to_start>

<task> Write ten headline options for this, each from a different angle. </task> <product> [what it is and what it does] </product> <audience> [who it is for and what they currently do instead] </audience> <proof> [any real numbers, results, or specifics you can use] </proof> <instructions> Give me ten headlines using ten different angles: outcome, specific number, contrarian, before-and-after, question, objection-first, speed, comparison against the current alternative, cost of inaction, and identity. Label each with its angle. Then name the two you would test first and why. </instructions>

<task> This page argues too many things. Rewrite it around a single belief. </task> <current_page> [paste your copy] </current_page> <audience> [who they are and what they currently believe] </audience> <instructions> Identify the one belief that, if the reader accepted it, would make the purchase obvious. Rewrite the page to argue that belief and nothing else. Tell me what you cut and why. Keep every real proof point. Flag any place the page needs proof it does not currently have. </instructions>

<task> Convert this feature list into outcome-led copy. </task> <features> [list your features] </features> <audience> [who they are and what they are trying to get done] </audience> <instructions> For each feature give: the feature as written, the outcome it produces for this specific audience, and the one-line copy version that leads with the outcome. Then flag any feature that produces no outcome this audience cares about, because that one should come off the page entirely. </instructions>

<task> Write copy that handles the real reasons people do not buy. </task> <product> [what it is and the price] </product> <known_hesitations> [anything you have heard from prospects or churned users] </known_hesitations> <instructions> List the eight real objections in the reader's own likely words, ordered by how often they stop a purchase. For each, write the copy that addresses it honestly, without dismissing the concern. Mark which belong on the page, which belong in an FAQ, and which signal a genuine product problem that copy cannot fix. </instructions>

<task> Write a sequence where each email earns the next one. </task> <offer> [what you are selling and to whom] </offer> <sequence_length> [number of emails and over what period] </sequence_length> <proof> [real results, examples, or specifics available] </proof> <instructions> Write the full sequence. Each email must deliver something useful on its own, so it is worth opening even if the reader never buys. Vary the structure between emails. Give me the subject line and preview text for each, plus a one-line note on the job that email is doing in the sequence. No fake urgency. </instructions>

<task> Traffic is fine but conversion is not. Diagnose the page. </task> <page> [paste the copy] </page> <numbers> [traffic, conversion rate, where visitors come from, what they did before landing] </numbers> <instructions> Work through the likely causes in order: message-to-traffic mismatch, unclear offer, missing proof, unaddressed objection, weak or ambiguous call to action, and friction in the next step. For each, say whether it applies here and quote the specific copy that shows it. Rank the fixes by expected impact against effort, and tell me which single change to test first. </instructions>

<context> You are Inbox Triage, a Claude Skill. When active, the user is drowning in email and needs decisions made, not messages summarised. </context> <core_principle> The value is in the sorting, not the summarising. Most email needs no reply, some needs a two-line reply, and a small number needs real thought. Your job is to tell them which is which and draft the easy ones. </core_principle> <triage_categories> - Needs you, now. Time-sensitive and only the user can handle it. - Needs you, not now. Real but can wait. Give a suggested date. - Two-line reply. Draft it in full so it can be sent as-is. - Delegate. Say to whom and draft the handoff. - No reply needed. Say so explicitly so it can be archived without guilt. - Trap. Looks urgent, is not, or is a request that should be declined. Explain why and draft the decline. </triage_categories> <drafting_rules> - Match the user's normal tone. If unknown, write plainly and warmly without being effusive. - Short. Most good email replies are under four sentences. - No em dashes, no corporate filler, no unnecessary apologising. - Never commit the user to a deadline, a meeting, or a price on their behalf. Leave those as bracketed decisions. - If a reply requires information you do not have, write the reply with a clearly marked gap rather than inventing the detail. </drafting_rules> <output_format> Group by triage category, most urgent first. For each message: sender, one-line summary, why it is in this category, and the drafted reply where applicable. </output_format> <how_to_start> Ask the user to paste the messages and tell you anything they have already decided. </how_to_start>

<task> Sort these messages into decisions and draft what can be drafted. </task> <messages> [paste your emails] </messages> <my_context> [your role, current priorities, and anything already decided this week] </my_context> <instructions> Sort into: needs me now, needs me later with a suggested date, two-line reply drafted in full, delegate with a drafted handoff, no reply needed, and trap. For anything in the trap category, explain why in one line. Draft every reply that can be sent as-is. Leave dates, prices, and commitments as bracketed decisions for me. </instructions>

<task> I have been putting off this reply. Write it. </task> <message> [paste the email] </message> <situation> [why it is awkward, and what outcome you actually want] </situation> <instructions> Write the reply directly, without over-apologising for the delay. Address the difficult part in the first two sentences rather than burying it. Keep it under 150 words. Then give me a shorter and a warmer variant so I can pick. Tell me in one line what I am risking with each version. </instructions>

<task> Write a decline that keeps the relationship intact. </task> <request> [what they asked for] </request> <relationship> [who they are to you and how much it matters] </relationship> <reason> [the real reason you are declining] </reason> <instructions> Write a clear no, in the first two sentences, with no false hope and no vague maybe-later. Where honest, offer something genuinely useful in its place, a referral, a resource, or a narrower version you would do. Keep it under 120 words. Then give me a firmer version for the case where they push back. </instructions>

<task> This thread has gone on too long. Tell me where it actually stands. </task> <thread> [paste the full thread] </thread> <instructions> Give me: what was actually decided, what is still open, who owes what to whom with any stated dates, and where people are talking past each other. Flag any commitment I made that I may have forgotten. Then draft a short message that closes the loop, restates the decisions, and assigns the remaining items clearly. </instructions>

<task> Turn my repetitive email into reusable templates. </task> <examples> [paste 5 to 10 replies you find yourself rewriting constantly] </examples> <instructions> Identify the recurring types. For each, write a template with clearly marked variable slots, plus a one-line note on when to use it and when not to. Keep my voice from the examples. Flag any template where a personal touch genuinely matters more than speed, because those should stay hand-written. </instructions>

<task> Write my weekly update from these raw notes. </task> <notes> [paste your raw notes, wins, blockers, and numbers] </notes> <audience> [who reads it and what they need to know] </audience> <instructions> Lead with anything that needs a decision or is off track, not with the wins. Keep it under 250 words. Use a consistent structure that will work every week: decisions needed, off track, on track, and what is next. Be specific with numbers. Flag anywhere my notes are too vague to report honestly. </instructions>