How to Build and Test a Claude Skill for Source-Backed Writing

A Claude writing skill should sometimes stop before it produces a finished draft. If your notes contain no customer result, a polished customer success story is a failed test.

For a solo founder, that failure costs more than a bad paragraph. You now have to check whether the rest of the draft contains invented claims, missing links, or promises your product can't support.

A useful skill saves the instructions you keep repeating. A trustworthy one also knows when those instructions require it to ask a question. Build both into the same workflow.

The complete guide to building skills for Claude starts with one repeatable task

A Claude skill packages instructions for a recurring task in a folder. Anthropic's complete guide describes skills as a way to avoid explaining the same preferences and processes in every conversation.

Start with a task you already do, rather than an impressive workflow you might use someday. For a founder who needs to publish regularly, a useful first task is turning source-backed notes into a draft that follows your writing rules.

Keep that task narrow enough to judge. “Help with marketing” gives you no clear way to tell whether the skill worked. “Turn supplied release notes and customer evidence into a linked draft” gives you an input, an action, and an output.

Write a short brief before touching the skill files:

• Input: product notes, source links, customer quotes, and the requested format.
• Output: a draft that follows your voice and preserves the evidence behind its claims.
• Boundary: no invented customer outcomes, quotes, or numbers.
• Success: you can check every factual claim without rebuilding the research yourself.

Those are proposed requirements for your skill, not promises about what Claude will always do. You'll test whether the instructions produce that result.

Don't make your first skill responsible for research, writing, scheduling, and publishing. Each extra job adds another place to investigate when the output goes wrong.

A saved prompt may be enough for a one-off task. A skill becomes useful when you keep repeating the same corrections or need supporting files. Build around the work you've already repeated, then expand only when a real request exposes a missing step.

Define the evidence a finished draft needs

A source-backed writing skill needs rules for unsupported claims before it needs rules for sentence length. Anthropic's skill creation article recommends defining the task, its triggers, success, and limitations before writing the skill.

For your content workflow, define “finished” in terms you can inspect. A draft isn't ready just because it reads well or sounds like you. It needs enough evidence for the claims it makes.

Use a small set of hard checks:

• Keep each supplied source URL attached to the claim it supports.
• Preserve the meaning of quotes rather than rewriting them as stronger praise.
• Flag conflicting figures instead of choosing whichever sounds better.
• Ask for evidence when the requested story depends on an unsupported outcome.
• Separate your own advice from facts taken from a source.

Suppose your release notes say you added a bulk export feature. Those notes can support a description of the feature. They can't establish that a customer saved time, reduced costs, or increased revenue.

The skill should offer a useful next step: ask for a customer quote or measured result, or suggest a feature announcement instead. It doesn't need to abandon the whole task because one requested claim lacks support.

A good writing skill makes missing evidence visible before it makes the prose convincing.

Put that rule ahead of style preferences. You can repair a stiff sentence during editing. An invented customer result can slip through precisely because it sounds natural.

Also define what the skill may leave unfinished. A draft with a clearly marked evidence gap can be useful working material. A draft that hides the same gap behind confident wording is harder to review and should fail your test.

How should you structure a Claude skill folder?

Put the main instructions in SKILL.md and keep supporting material in separate files. Claude's custom skills documentation describes a skill as a folder containing that file, with optional scripts and references.

For a writing workflow, a simple starting structure could look like this:

source-backed-writing/
  SKILL.md
  references/
    writing-rules.md
    approved-examples.md
  templates/
    customer-story.md
  tests/
    requests.md
    expected-behavior.md

The supporting filenames here are suggestions, not required names. The test files give you a place to record your checks; they don't replace running the requests yourself.

Keep SKILL.md focused on the job, the order of work, and the rules that must survive every draft. Put longer voice examples in approved-examples.md. Put the shape of a customer story in its template.

Tell Claude when to read each supporting file. A useful instruction might say: “Read the writing rules before drafting. Read the customer story template only when the requested format is a customer story.”

That split follows Anthropic's authoring guidance: Claude loads skill metadata first, reads SKILL.md when relevant, and reads additional files as needed.

Don't add a script just because skills support scripts. Add one when you have a specific check that code can perform, such as comparing supplied URLs with links in the output. Even then, a link check won't tell you whether a source supports the attached claim.

Keep the folder readable enough that you can open it after a month and understand the workflow. If changing one writing rule requires hunting through several duplicated files, simplify the structure before adding another feature.

Your description decides whether Claude loads the skill

The skill's name and description influence whether Claude calls it for a request. Anthropic's creation guide says those are the parts of SKILL.md that influence triggering.

Choose a plain name that describes the work. source-backed-writing tells you more than content-genius. The description should name the input, the expected output, and the situations where the skill belongs.

Here's a starter file you can adapt:

---
name: source-backed-writing
description: Draft source-backed articles, product updates, and customer stories from supplied notes and links. Use when turning release notes, research notes, or customer evidence into publishable copy. Do not use for unrelated writing or coding tasks.
---

# Source-backed writing

1. Identify the requested format and audience.
2. Read references/writing-rules.md.
3. Map the supplied evidence to the claims needed.
4. If a required claim lacks evidence, ask for it or offer a narrower draft.
5. Flag conflicting numbers. Don't choose one without support.
6. Read the matching template when one exists.
7. Draft using only supported factual claims.
8. Keep source links beside the claims they support.
9. Check the draft against the evidence and writing rules.

Never invent customer results, quotes, or measurements.

Treat this as a starting point, not a tested skill. Your actual requests may use language the description doesn't cover. Your writing rules may also reveal decisions that need clearer instructions.

Test a normal request such as “turn these release notes into a customer story.” Don't rely only on “use my source-backed-writing skill.” Naming the skill directly bypasses the question you need answered: will Claude select it during ordinary work?

Also try an unrelated request. The description should help Claude leave the skill alone when you're asking for something else. A writing workflow that intrudes on debugging work needs attention even if its drafts look good.

Test the request your writing skill should stop

A writing skill should ask for missing evidence when the requested draft depends on an unsupported claim. Anthropic's best practices call for concise, well-structured skills tested with real usage.

For a first writing skill, use four saved requests. These are proposed tests for your workflow, not a benchmark supplied by the documentation.

1. Complete source notes. Supply release notes, a customer quote, and a documented result with links. Ask for a customer story without naming the skill. Passing means the draft preserves the evidence, uses the requested format, and follows your writing rules.
2. Missing evidence. Supply release notes without a customer quote or measured result. Ask for a success story about customer gains. Passing means Claude asks for evidence or offers a narrower feature story. A fabricated gain fails, however good the prose sounds.
3. Conflicting numbers. Supply notes that disagree about the same result. Passing means Claude identifies the conflict and asks which figure is supported. Averaging the figures or quietly choosing one fails.
4. An unrelated request. Ask Claude to explain a small code function. Passing means it answers without forcing the source-backed writing process onto the task.

Save the inputs and expected behavior before you edit the skill. Otherwise, it's easy to soften your standard after seeing an attractive draft.

Inspect the output rather than trusting a final line that says “all claims verified.” Open the links. Compare the quoted language. Check that the requested result actually appears in the supplied evidence.

For the missing-evidence case, don't demand one exact refusal sentence. Judge the behavior. Claude can ask a clear question, offer a safer format, or draft supported sections while marking the gap.

The test passes when Claude protects the claim, not when it produces the most complete-looking page.

How do you debug a skill without losing citations?

Rerun the same saved requests after each edit to a Claude writing skill. Anthropic's workflow patterns recommend explicit ordering, dependencies, and checks at each stage for work that follows a sequence.

Use the failure to decide what to change. Don't rewrite the whole skill whenever one output disappoints you.

• If Claude doesn't select the skill, inspect the name, description, and wording of the request.
• If Claude selects it but invents an outcome, strengthen the evidence check before drafting.
• If links disappear, make the final check compare draft claims with their supplied sources.
• If the output ignores your voice, inspect the writing rules and examples for unclear or conflicting advice.

Change one part, then run the saved requests again. That makes it easier to connect the edit with the result. If you change the description, workflow, and examples together, you won't know which change helped.

Keep a small record for each run: the skill version, request, output, and reason it passed or failed. You don't need a dashboard. A text file with links to saved outputs can do the job.

Review factual support separately from prose quality. A revision can produce shorter sentences while losing a citation. Calling that an improvement hides the failure you most need to catch.

You can also ask for another review. Anthropic's resources page says skill-creator can generate skills from descriptions and suggest improvements to existing ones.

Use those suggestions as edits to test, not proof that the skill works. Your saved requests remain the check. Keep the version that handles the difficult inputs, even if another version produces a smoother first paragraph.

How do you set up, share, and maintain a Claude skill?

A shared Claude skill needs its supporting files and clear expectations, not just a copied SKILL.md. Claude's custom skills documentation explains that skills can include references and scripts and can apply for people you share them with.

Use the setup instructions for the Claude surface where you'll run the skill. Check the linked documentation rather than relying on a remembered menu path. Once it's available, run an ordinary request without explicitly naming it.

Before sharing, inspect the whole folder:

• Include every reference and template that the instructions point to.
• Remove private customer notes, internal links, and secrets from examples.
• Explain which inputs the user must supply.
• Record known limits and the requests you've tested.

If someone else will use it, ask them to try their own wording. Their request is a useful check on whether your description only matches the phrases you wrote while building it.

Keep tool access separate from workflow instructions. The custom skills guide distinguishes skills from connectors: a skill can explain how to use a connected service, but it doesn't provide access by itself. A folder of writing instructions won't fetch private customer records on its own.

Maintain the skill when your work changes. Update examples when your voice changes. Update templates when your publishing format changes. Rerun the saved requests whenever you edit the rules.

Don't spend your next writing session designing a skill for every possible content task. Pick one real draft. Save its input, define what would make it publishable, and build the smallest folder that can handle it.

Then remove the evidence for its strongest claim and run it again. If Claude asks for the missing source instead of supplying a believable result, you've built something worth continuing to use.