If you paste the same text-review instructions every week, you have a candidate for a skill. Before installing more tools, describe what repeats, which inputs it needs and what output you expect. This often reveals whether the method is reusable or still improvised each time.
We will design a claim-review skill for a draft. This is an original, bounded example. It does not independently verify the web or certify sources. It organizes claims and identifies missing evidence.
Define a recognizable task
The input is a draft with sources when available. The output lists the claim, supplied source, outstanding check and proposed correction. The procedure does not publish the text or alter its figures.
That scope keeps research, editing and publication separate. Add a source-finding stage later if you have the tools to perform it, and evaluate that stage independently.
Explain when the skill should not apply. Fiction does not need its characters treated as unresolved factual claims. A clear description helps the agent select the right procedure.
The minimum file
The Agent Skills specification defines SKILL.md with metadata and instructions. Create a directory called review-claims and place this original example inside it:
---
name: review-claims
description: Reviews checkable claims in a draft and organizes their sources. Use before factual editing, not for fiction or publication.
---
Read the complete draft and supplied sources.
Identify claims that affect a reader's decision.
Separate facts, opinions and hypothetical examples.
For each fact, identify supplied evidence and outstanding checks.
Do not invent links, numbers, dates or test results.
If a source cannot be opened, record that limitation.
Suggest corrections without adding unsupported information.
Return a table of claim, evidence, question and correction.
Do not publish or mark an unperformed check as passed.
The example is short enough to read and adapt in full. A first review table does not require a script. Add code when a repeated operation becomes more reliable and verifiable through execution.
Where to put it in Codex
Codex’s skill documentation lists discovery locations. For a project, this example can live at .agents/skills/review-claims/SKILL.md. Confirm that it appears in your environment and select it explicitly for the first trial.
Keep sensitive instructions and credentials out of the file. A valid path does not install the skill in another application. When sharing it, explain required tools and which parts remain editorial suggestions.
Include a deliberate trap in the trial
Try a hypothetical draft stating that an application costs twenty euros in every country and provides unlimited use. Supply a fact sheet saying only twenty US dollars per month in the United States. The appropriate output identifies unsupported currency, geographic scope and unlimited-usage claims.
Next, test an opinion: “I find the interface more comfortable”. It should remain attributed opinion rather than become a missing numerical claim. Finally, remove the source. The skill should report missing evidence instead of creating a plausible reference.
These are proposed tests for your installation, not results from an automated evaluation across all agents. Save your tool’s output and adjust the instructions if it confuses facts with opinions or invents a source.
Maintain the method as your work changes
A small skill is easier to maintain with examples of inputs and outputs. Add a rule after observing the problem it solves. Avoid collecting contradictory warnings or requirements nobody can verify.
If you are unsure where each instruction belongs, start with skills, MCP and AGENTS.md.
To check whether the procedure helps, apply our guide to verifying agent results.
Once the method is stable, Humanizer can complement it with prose editing while factual verification stays separate. To turn a recurring process into a skill for your team, tell us what you do today.