crontent

How to use Claude Skills to check your drafts

Claude can keep your writing rules in a folder and load them when a draft needs checking. The catch: writing those rules doesn't prove Claude will load them, or catch the errors you care about.

If you've shipped a product and write your own marketing, start with a narrow job: check a draft before you publish it. Build a Skill that flags unsupported claims and broken writing rules. Then test whether it actually does that job.

What are Claude Skills?

Claude Skills are folders of instructions, scripts, and reference files that Claude loads when a task calls for them. You can use them to teach Claude a repeatable process without pasting the same instructions into every conversation.

According to Anthropic's introduction to Skills, Claude scans available Skills for relevant matches. When it finds one, it loads only the information and files it needs. A Skill can also include executable code for work better handled by a program.

For a solo SaaS founder, that could mean a reusable process for checking a blog draft against your writing rules. You provide the rules once, then ask Claude to review new drafts against them. The same idea can apply to reviewing code or preparing documents.

Skills aren't limited to Claude Code. The introduction describes support across Claude apps, Claude Code, and the API. The folder format lets you package a process for use across those products, though you still need to set it up in the product you're using.

There are also built-in Skills. If you've used Claude to create a spreadsheet or presentation, you've already used capabilities powered by Skills. Custom Skills let you package your own instructions instead.

The useful distinction is between knowing your preferences and following a defined task. “Write well” leaves Claude guessing. “Check every numerical claim against the supplied sources and quote any unsupported passage” gives it a job you can inspect.

For your first content Skill, choose a task with a clear finish. A draft check ends with a list of problems you can review. That's easier to test than a broad request to make all your content better.

How do Skills differ from prompts and CLAUDE.md?

A Claude Skill loads when Claude matches your request to its description, rather than requiring you to paste the whole process again. That makes it useful for a task you repeat across separate conversations.

Claude Academy's introduction to agent skills distinguishes Skills from two other Claude Code options. CLAUDE.md loads into every conversation, while slash commands require explicit invocation. Skills load on demand when Claude recognizes a matching task.

Those differences help you decide where instructions belong:

  • Use a prompt for a one-off request whose instructions you're happy to supply each time.
  • Use CLAUDE.md in Claude Code for instructions you want present in every conversation.
  • Use a Skill for a repeatable task that should bring its own process and reference files.

For example, a permanent project rule might say that customer information must stay private. A draft-review Skill might contain a detailed process for checking claims, citations, and writing style. A one-off prompt might ask Claude to focus on the opening paragraph today.

Don't treat a Skill as proof that a process happened. It gives Claude instructions it can discover and use. You still need to check whether it loaded the right instructions and produced a useful review.

For a small content workflow, keep the first Skill separate from drafting. Ask it to inspect existing copy. You can judge its output against the words on the page, rather than arguing about whether a fresh rewrite sounds better.

You don't need to move every preference into a Skill. Start with the instructions you're tired of repeating and the errors you can clearly recognize.

What should go in your first draft-review Skill?

A draft-review Skill needs a clear task, explicit checks, and examples of what should get flagged. Keep the main instructions readable, and put longer writing rules and examples in reference files.

Anthropic's guide to building Skills describes Skills as folders that package instructions for specific tasks. It names documents that follow a style guide as one useful repeatable workflow. A draft checker fits that pattern.

A sensible starting folder could contain:

  • SKILL.md: the task description, review steps, and required output.
  • writing-rules.md: your banned phrases, sentence rules, and examples of acceptable edits.
  • claim-checking.md: what counts as support and what to do when evidence is missing.
  • review-examples.md: sample passages paired with the flags you expect.

These filenames are a suggested layout, apart from the Skill's SKILL.md file. You don't need scripts just because Skills support them. Start with instructions you can read and test yourself.

Make the review depend on the material you provide. If you supply a draft and a set of sources, tell Claude to compare them. If a source is missing or inaccessible, tell it to mark the claim as unverified rather than fill the gap from memory.

Be equally clear about customer quotes. Ask Claude to flag quotes that lack a supplied original or approval record. A reviewer can't establish that a customer said something just because the sentence sounds believable.

Keep examples short and direct. Pair a vague rule such as “avoid hype” with phrases you actually reject. Then show an acceptable edit that preserves the original meaning.

Your goal is a folder you can maintain between product work. If updating a writing rule requires untangling a giant prompt, simplify the folder before adding more checks.

A clear description gives Claude a task to match

Claude uses a Skill's description to decide whether it matches your request. A well-written review checklist won't help on a task where Claude never loads it.

Claude Academy's lesson on agent skills says each Skill has a SKILL.md file with a name and description in its frontmatter. Claude compares requests with those descriptions and activates matching Skills.

For a draft checker, describe both the work and the situations where it should run. Here's a suggested starting point, not a tested configuration:

---
name: saas-draft-review
description: Review SaaS blog drafts and social posts before publishing. Use when asked to check a draft, review a post, or assess whether copy is ready to publish. Flag unsupported claims, missing sources, banned phrases, and customer quotes without supplied evidence. Return flagged passages and suggested fixes rather than rewriting the full draft.
---

The description names a concrete task. It also includes ordinary requests you might type while rushing to publish. You shouldn't need to remember a special phrase every time you want a review.

Avoid descriptions such as “expert content assistant” or “helps with marketing.” They leave the job unclear. A review request should point toward a review process, not every possible task involving words.

Keep the detailed checks in the Skill's instructions and reference files. The description should make the match clear, without becoming your entire style guide.

Treat the first description as a draft. If “check this post” doesn't lead Claude to use the Skill in your setup, record that miss. Adjust the wording and test the same request again. Don't improve the checklist when the actual problem is that Claude never reached it.

Ask for flagged passages before asking for rewrites

A draft-review Skill should show you the exact passage it objects to and explain the problem before offering a fix. Otherwise, you have to compare two full drafts to discover what Claude changed.

Claude Academy's guide to working with Skills lists a brand voice review process as an example of a custom workflow. For a founder reviewing their own content, that process should produce a report you can act on.

Give the Skill a small set of checks:

  1. Flag factual claims that the supplied sources don't support.
  2. Flag claims whose citations are missing or don't support the attached sentence.
  3. Flag phrases that break your supplied writing rules.
  4. Flag customer quotes without a supplied original or approval record.

For each finding, request the quoted passage, the reason for the flag, and a suggested next action. That action could be adding evidence, weakening the wording, removing a claim, or asking you for the missing source.

Tell Claude to distinguish an unsupported claim from a false one. A claim can be true but unsupported by the files you supplied. The review should say what it could verify, not pretend it knows what happened inside your business.

A fluent replacement sentence isn't evidence. If the draft makes an unsupported promise, changing the wording doesn't establish that the promise is true. Ask for an explicit warning when a fix still needs your input.

You can request suggested edits without granting permission to rewrite the whole piece. That keeps your examples and point of view visible while you decide which changes to accept.

Finish the report with unresolved questions, if any. Don't let a clean-looking rewrite hide the fact that a customer quote still needs approval or a product claim still needs proof.

How do you verify that Claude uses the Skill?

Test the draft-review Skill with the requests you'll actually type, and check for evidence that Claude used it. A good result from one carefully worded prompt doesn't show that ordinary requests will work.

Anthropic's Skills introduction explains that Claude scans Skills for relevant matches and loads what it needs. That matching step deserves its own test, separate from judging the review.

Start with a short set of realistic requests:

  • “Check this post.”
  • “Is this ready to publish?”
  • “Review this SaaS draft against my writing rules.”
  • “Flag anything in this article that needs a source.”

Run each with a draft attached or included. Keep the draft unchanged while testing the wording of the request. Otherwise, you won't know whether a different result came from the request or the new copy.

Where your Claude interface exposes Skill use or file activity, inspect it. A reference to the relevant Skill or its files is stronger evidence than an answer that merely sounds like your usual editor.

If your interface doesn't expose enough detail, treat the result as uncertain. You can ask which instructions Claude used, but don't treat its reply alone as proof. Check for behavior tied to your reference files, such as applying a distinctive rule or using your required report format.

Record whether you observed Skill use, couldn't verify it, or saw no sign of it. Record review quality separately. Claude might produce useful feedback without using your Skill, or load the Skill and still miss a problem.

Test whether Claude loaded the Skill and whether it caught the errors as two separate questions. Combining them makes it harder to know what to fix when the review disappoints you.

Test planted errors before trusting the review

A draft-review Skill needs a test draft with known errors, so you can compare what Claude flags with what you deliberately put there. A tidy review report doesn't tell you what the reviewer missed.

Anthropic's guide to building Skills includes testing and iteration among the work involved in building effective Skills. For a content checker, use a small test you can judge by hand.

Create a clearly labelled test draft that will never enter your publishing queue. Plant these deliberate errors:

  • A made-up numerical claim, explicitly recorded as fabricated in your private answer key.
  • A factual claim with no citation in the draft.
  • A phrase that your writing rules explicitly ban.
  • A fictional customer quote with no supporting original.

You could use “Every customer doubled their search traffic” as a deliberately fabricated test claim. Don't present it as a real result. The purpose is to see whether Claude asks for evidence rather than accepting confident wording.

Include a supported claim and an acceptable sentence too. You want to know whether the Skill invents problems as well as whether it misses them. Save the expected findings before running the review.

Compare the result with that answer key. Did Claude quote the right passage? Did it explain the missing evidence? Did it suggest removing an unsupported claim, or merely make it sound more convincing?

Change one part of the Skill when you find a miss, then rerun the same draft. Keep the requests and expected findings so you can repeat the check after later edits.

Start with one draft, one source pack, and one review Skill. Before using it on your next real post, prove that it flags the errors you've planted. Then check the real draft yourself before publishing.

Sources