Start with a skill: a prompt you paste in can't get better

The usual first move with a big-document job is a big prompt. Write the instructions, attach the documents, ask for the review. If it goes well, the prompt is saved in a note and pasted in again next time, with a few changes. If it goes badly, someone tweaks the wording and tries again.

That is a reasonable way to start and a poor way to carry on. A prompt you paste in is a one-off. There is nothing fixed to test, nothing to improve from one run to the next, and nothing someone else can pick up and run the same way.

The first real step is to build a skill.

What a skill is

A skill is a saved, named package an agent can load when a job calls for it. It holds the instructions for the job, the reference material the job needs, and scripts the agent can run. Claude calls them skills; other platforms have similar ideas under other names. In Claude, a skill is a folder: a short file saying what the skill is for and how to do the job, with its scripts and reference files beside it.

The agent doesn’t load every skill all the time. It reads a one-line description of each and opens the full skill only when the job needs it. That is the same index-first idea the Wordhouse uses for its topics. The Agentic Wordhouse

Why a skill beats a big prompt

It repeats. The same skill runs the same way next week, for someone else on the team, on the next document.

It does more than read and write. A prompt can only ask the model to read the documents and write an answer. A skill can give the agent scripts and tools to interrogate a document, extract its structure, compare it with another, merge content, generate a redline and fill a template. The model does the judgement; code does the work that has to be exact.

It can get better. Because the skill stays the same between runs, you can test it, find what it got wrong, fix that one thing and test again. Each lesson is kept in the skill rather than in someone’s memory.

Two ways to miss

Some teams never build a skill. Every job starts again from a prompt, so there is never anything to improve. What was learned last time lives in someone’s head, or in a chat history nobody will read again.

Others build a skill and put the big prompt inside it. That is a step forward, because it repeats. But it repeats the roll of the dice: the same one big read of every document at once, the same silent stop at the output limit, the same lottery on what matters. BigDocs: rolling the dice on big documents

The value comes from doing both: building a skill, and building the patterns in this series into it.

What goes inside

Each pattern in the series is something to build into the skill:

• The Wordhouse: reference files organised by topic, with an index the skill reads first. The Agentic Wordhouse
• Structure first: a script that splits the document using its own numbering and headings, and a check that nothing was dropped. Structure first
• Content, not documents: a script that extracts the content once, so every later step works from the same words. Content, not documents
• The mapping file: a step that writes the plan down and waits for a person to approve it. The mapping file
• Never retype: scripts that copy text and apply edits, so the model only points. Never retype
• Output for oversight: a fixed output, with a row for every clause and the escalations set aside. Output built for oversight
• Maintaining the Wordhouse: a second skill that keeps the library current. Maintaining the Wordhouse
• Build the tests in: checks the skill runs on its own work, and a test set you rerun whenever the skill changes. Build the tests in

A skill doesn’t need all of these on day one. Start with the one that fixes your biggest problem, and add the next when you see where the skill falls short.

What it bought in the benchmark

The pipeline in the benchmark is a set of Claude skills built on these patterns: one builds the Wordhouse from our standard paper, and others use it to review the customer’s contract. The single prompt is what most people do instead. BigDocs: the benchmark

Building it as skills mattered most when something went wrong. The benchmark found that the library skill’s coverage check passed while 14 clauses that mattered had no position. Because the check lived in a skill, it was fixed once, in the skill, and it now works clause by clause on every run. With a pasted prompt, the fix lasts only as long as someone remembers it.

Who can build one

A skill doesn’t need an engineering team. A first version can be a page of instructions and a few example files, written by the people who know the job. Claude can help write the scripts, and a finished skill can be shared across the team.

For the technology team, the job changes from building each team’s tool to knowing which skills exist, which ones matter, and that each of those is tested. Build the tests in

What your team can do on Monday

Find the prompt your team pastes in most often for a document job. Turn it into a skill: the instructions, the examples it relies on, and a short description of when to use it. Run it on two documents you know well. Then pick the one thing it got wrong and fix it in the skill, not in the next prompt.