How to Set Up Claude Code for Source-Checked Content

Your citation checklist can live in .claude/skills/source-check/SKILL.md, ready to run with /source-check. You don't need to paste it into every chat about your product.

For a solo founder, that's a useful place to start with Claude Code skills. Take a task you already repeat before publishing. Write down how you do it. Give Claude a clear way to find those instructions without dragging them into unrelated coding work.

What are Claude Code skills?

Claude Code skills are folders containing instructions that Claude can use for specific tasks. Each skill has a SKILL.md file, and you can call it directly with /skill-name.

The Claude Code documentation says Claude can also use a skill when it matches the task. Unlike the contents of CLAUDE.md, the skill's body loads only when Claude uses it. That difference makes skills useful for detailed procedures you don't need during every conversation.

Think about a source check before you publish a post. You might want Claude to:

• Find every claim that needs evidence.
• Compare each claim with the supplied source.
• Flag numbers or quotes the source doesn't support.
• Return specific edits rather than a vague approval.

Those instructions describe a job. They aren't facts about your product, and they don't help Claude fix a broken signup form.

A skill gives that job a home. You can keep using the same procedure without copying the checklist from an old conversation. When you change the procedure, you edit the file rather than hoping you remember the latest wording.

Skills also support more than a single instruction file. They can contain supporting resources and scripts. But a useful first skill doesn't require either. A clear checklist is enough to begin testing.

Don't mistake the packaging for proof that the work will be correct. A skill tells Claude how you want it to work. You still need to check whether it followed the instructions and whether the sources support the result.

For content work, the useful unit is a repeated task with a clear finish. “Check this draft against these sources” is easier to judge than “help me do marketing.”

Keep shared product facts in CLAUDE.md

CLAUDE.md supplies instructions across Claude Code conversations, while a skill's detailed instructions load when the skill is used. The Claude Code documentation explicitly recommends creating a skill when a section of CLAUDE.md has grown into a procedure rather than a fact.

For a small SaaS product, shared facts might explain who the product helps and what it actually does. Those details can matter whether you're changing the app or drafting its documentation.

A detailed publishing checklist has a narrower job. It might explain how to handle quotes, check dates, or rewrite a claim that overstates its source. You need those instructions during a content task, not necessarily during a database change.

A useful way to sort an existing file is to ask two questions:

• Does Claude need this fact across the work I do in this repository?
• Does this passage describe steps for completing one particular task?

Keep the broadly needed facts in CLAUDE.md. Move the task-specific steps into an appropriate skill. Some writing preferences may belong in shared instructions if you genuinely want them applied everywhere. A long editorial procedure usually has a more specific home.

Keep shared facts close at hand. Load detailed procedures when the task needs them.

Don't turn the cleanup into a writing project of its own. Start with the most obvious block: the checklist you keep scrolling past during coding conversations.

Move that block, give it a clear name, and try it on a real draft. You can sort the less obvious cases after you've seen whether the first skill helps. The goal is to stop repeating instructions, not to build a perfect filing system before you publish again.

How do you create a source-check skill?

Create .claude/skills/source-check/SKILL.md inside your repository and put your checking instructions in it. The Claude Academy lesson explains that project skills live in the repository's .claude/skills directory and that Claude uses each skill's description to decide when it fits a request.

Here's a starter example to adapt. It's a proposed checklist, not a built-in source-checking feature:

---
name: source-check
description: Check a content draft against supplied sources before publication. Use when asked to verify claims, numbers, quotes, dates, or citations.
---

Review the supplied draft against the supplied sources.

1. Identify factual claims that need support.
2. Compare each claim with the relevant source passage.
3. Check names, numbers, dates, and direct quotes exactly.
4. Flag claims that go beyond what the source says.
5. Never invent a citation or fill a gap from memory.
6. If a source can't be checked, say so.
7. Suggest narrower wording when evidence is limited.

Return a table with:
- Claim
- Source and supporting passage
- Status: supported, overstated, or unverified
- Suggested edit

End with any unresolved checks for the human reviewer.

The description names the task and the situations where you want Claude to use it. The body explains the actual work and the expected result.

Keep that distinction clear. A description that says “improve content” gives Claude less to match against than one that names checking claims and citations.

The output format matters, too. “Check this carefully” leaves you guessing what Claude checked. A table asking for a supporting passage makes the review easier to inspect. It also gives you somewhere to spot an empty answer.

Start with instructions you've already found useful by hand. Don't add rules just because a skill file looks too short. Add a rule when a real draft exposes a gap in the procedure.

How do you run a skill and choose where it lives?

Run /source-check to invoke a skill named source-check directly. The Claude Code documentation also says Claude can use relevant skills automatically, so the slash command isn't the only way to start the task.

For your first tests, call the skill yourself. That removes one question from the exercise: whether Claude chose the right procedure. You can focus on whether the procedure produces a useful review.

A request could look like this:

/source-check

Check the draft below against the supplied source excerpts.
Don't rewrite the full article.
Return unsupported claims and suggested fixes.

Draft:
[paste the draft]

Sources:
[paste the source URLs and relevant excerpts]

The skill stores the method. Your request still needs to identify the draft and the evidence for this particular check. Instructions to verify a claim don't supply the missing source passage.

Choose the location based on where you want the skill available. The Claude Academy lesson distinguishes personal skills in your home directory from project skills inside a repository. Personal skills follow you across projects. Project skills travel with the repository when someone clones it.

For product-specific editorial rules, a project skill is a sensible starting point. It keeps the procedure beside the work it describes. If you use the same review format across unrelated projects, a personal skill may fit better.

Automatic matching is worth testing after direct use works. Ask Claude to check a draft in normal language and see whether it selects the intended skill. A good description should explain when to use the procedure, not merely give the folder a pleasant name.

Separate checking sources from rewriting the draft

A source-check skill needs evidence to check against, even when its instructions are detailed. Anthropic's guide to building skills describes skills as instructions for specific tasks and workflows, including research and documents that follow a style guide. Those are useful jobs to define separately.

Checking whether a sentence is true and making it sound better ask different questions. A sentence can read beautifully while claiming more than its source supports.

For example, a source might say a feature can help with a task. A draft might turn that into a claim that the feature guarantees a result. A source check should flag the stronger wording. A style pass might otherwise make that same unsupported promise shorter and more persuasive.

For a first workflow, use a deliberate order:

1. Draft from the product notes and source material you provide.
2. Check the draft's factual claims against that material.
3. Fix unsupported or overstated claims.
4. Apply your writing rules without changing what the evidence supports.

That's a suggested workflow, not a requirement of Claude Code. Its value is that you can inspect each job instead of receiving one polished answer with no clear record of what changed.

Tell the source-check skill to distinguish “unsupported” from “false.” A claim missing from the supplied sources hasn't automatically been disproved. It needs more evidence, narrower wording, or removal before you publish.

Also ask Claude to state when it couldn't inspect a source. A link in the output shouldn't count as proof that the linked page supports the sentence.

A reusable checklist can make a review easier to inspect. It can't make missing evidence appear.

Test one skill on a draft you already know

An existing draft with a known mistake gives you a concrete way to test a Claude Code skill. Anthropic's guide includes testing and iteration as part of building skills and estimates 15–30 minutes to build and test a functional one.

Treat that estimate as a starting point, not a promise about your workflow. A skill that produces a response has cleared a lower bar than one you'd trust during a publishing deadline.

Choose a short draft where you already understand the evidence. You could deliberately include:

• A number that differs from the supplied source.
• A quote with a changed word.
• A claim that's stronger than the source allows.
• A supported claim that should remain untouched.

Then run /source-check and inspect the result. Did Claude catch the planted problems? Did it show the relevant passages? Did it leave the supported claim alone?

Test the awkward case too: provide a claim without enough evidence. The useful response is an explicit gap, not a confident guess or a citation attached to an unrelated passage.

When the skill misses something, improve the instruction that governs that mistake. If it flags too much, make the boundary clearer. “Only evaluate factual support; don't suggest style edits” may be more useful than adding another page of general advice.

Keep a small set of these drafts for later checks. When you change the skill, run the same cases again so you can compare the results.

You don't need to build a formal testing system before using a checklist. You do need a better standard than “the answer looked thorough.” A long review that misses the wrong number hasn't done the job you asked for.

Build your next skill from work you actually repeat

Repeated instructions are the clearest signal that you may need another Claude Code skill. The Claude Code documentation recommends skills for instructions, checklists, and multi-step procedures you keep pasting into chat.

For content work, the next candidate might be applying your writing rules or drafting from product notes. Don't create both just to fill out a folder. Wait until you've done the task enough to describe what a useful result looks like.

A drafting skill needs more than “write something engaging.” It needs a clear account of what Claude should use and what it should return. For example, you might tell it to work only from supplied notes, preserve the product's stated limits, and mark missing information rather than filling it in.

A writing-rules skill could describe the edits you keep making yourself. If you repeatedly cut vague openings and replace unsupported promises, write those checks down. Use examples from your own editing rather than borrowing a huge rulebook you haven't tested.

Keep the names plain enough to remember when you're busy. A skill you can't find or don't know when to run won't help you finish a post.

You also don't need to migrate working commands for the sake of it. The documentation says existing .claude/commands/ files still work now that custom commands have merged into skills. Use the format that solves the task in front of you.

The useful finish line is modest: one procedure you no longer have to paste, producing a result you can judge.

Open the checklist you used on your last draft. Put it in .claude/skills/source-check/SKILL.md. Run it against that same draft and inspect every flagged claim before trusting it on the next one.