How to Build a Claude Skill for Construction

Building a Claude skill means writing one construction workflow down as a procedure Claude follows the same way on every run. This guide comes from a video where I built a site reporting skill live, from mapping the workflow through testing it on real notes, photos and sign-in sheets. It is written for contractors and PMs, and the core build needs no code.

Key takeaways

• A Claude skill is a procedure manual Claude follows exactly, so you get the same output at the same quality every run.
• The best first skills are format conversions: rough site notes into a formatted daily report, sub quotes into a comparison, meeting notes into an RFI.
• The build is seven steps: map the workflow, gather a template and examples, describe the procedure, generate it with Claude, test it on a real day, then iterate.
• Claude formats, extracts and populates. You still own the numbers, the review and anything contractual.
• The first output will be rough. The fix always goes into the skill, never just the output.

What is a Claude skill?

A Claude skill is a saved set of instructions that tells Claude exactly how to handle one specific task, packaged with the reference material and templates the task needs. Unlike a prompt you retype each time, the skill is read fresh on every run, so the structure and quality of the output stay consistent between projects.

As I put it in the video: “Think of them like a procedure manual that Claude follows exactly, so you get the same output with the same quality every time.”

A skill has four core components:

1. The procedure. A markdown text file that walks Claude through the task step by step: classify the input, work through the stages, produce the output in a set format. Markdown is just structured text, so you can read and edit it yourself.
2. Reference material. What good looks like. Example reports, classification tables, industry standards. Anything that adds context to what the procedure is trying to do.
3. Templates. Your actual report template uploaded as a file, so Claude reads the structure, the sections and the layout, then duplicates and populates it. The output matches your format every time.
4. Scripts. Optional code the skill can run, like generating a formatted Word document. Scripts are powerful because code gives the same result every run, but they only execute inside Cowork or Claude Code, not the standard chat window.

A skill is deliberately generic. Site reporting is site reporting, whether the job is a hospital or a residential subdivision. The job-specific context, the contract, the spec, the team names, lives in a Claude project, and the skill picks it up from there. If you are still weighing up the tool itself, start with the Claude for construction overview. This post is the next step: making it do exactly what you need.

Which construction workflow should you turn into a skill first?

Pick a workflow where the information does not change but the format does. Rough field notes becoming a structured daily report is the textbook case: the capture already happens on site, and the hours disappear into formatting. That reformatting step is what Claude does reliably, and the same pattern repeats across change orders, RFIs and procurement.

Split site reporting open and you see two very different halves. Data capture is the easy half, and it is already happening: walking the site, notes on a phone, voice memos, WhatsApp updates from the crew. Formatting is where the time goes. Find the template, rewrite rough notes into the right sections, lift the language to something professional, fill the tables, check completeness.

That second half is a format conversion. The information does not change; the format does. Tim Fairley makes the same point in his complete guide to AI in construction: AI is good at summarising large documents, first drafts, generating registers, and checking and verifying outputs. It is not good at specific judgment calls. Reading rough diaries and dockets and writing structured entries is a genuinely good fit. Measuring percent complete is not. That number stays with the person whose eyes were on the work.

There is a contractual reason to care too. Claims and extension-of-time positions stand or fall on small, fast, well-documented records, so a daily report in a consistent format is not cosmetic. It is the evidence trail.

Estimating follows the same pattern with a stricter boundary; see Claude for construction estimating for why Claude checks an estimate rather than writes one. And if you would rather start from pre-built skills, the Claude skills for construction library rundown covers what already exists. Once you see the format-conversion pattern, you will see it everywhere.

How do you build a Claude skill step by step?

You build a skill by describing the workflow to Claude and letting it write the skill files for you. Map the workflow, gather your template plus two or three good example outputs, write a detailed description of the procedure, then generate, test and iterate inside Claude’s skill builder. The whole build happens in plain English.

Here is the process from the video, building a daily site reporting skill:

1. Map the workflow. Write down what comes in (rough notes, voice transcripts, WhatsApp messages, photos, sign-in sheets), what has to happen to it, and what goes out (the finished report in your template). As I said in the video: “Once you can map the workflow, you can build a skill for it.”
2. Gather the template and examples. The actual report template as a file, plus two or three past reports you consider good. The template sets the structure; the examples set the quality bar.
3. Write the procedure description. Spell out the input types, the classification rules for what data goes where, the output format, and the extras you want surfaced, like potential change orders or safety items the reviewer should know about. More detail here means fewer iteration loops later.
4. Open the skill builder. In the Claude app, go to customize, then skills, then create with Claude. Paste the description and attach the template and example reports.
5. Generate and review. Claude writes the procedure file, builds a quality-bar reference from your examples, then runs a simulated test input and shows you the output. If it stops at a tool use limit mid-build, that is not an error. Hit continue and it carries on.
6. Save it and run it for real. Copy the skill to your library, open the Claude project for a live job, and ask for today’s report with a real day’s notes, photos and sign-in sheet attached.
7. Iterate on the skill, not the output. Every miss becomes a change to the skill’s instructions, so next week’s report does not repeat it. More on that below.

The iteration loop: testing on a real day

Expect the first output to have the right structure and the wrong details. Run the skill on a real day’s inputs, name what is wrong in plain language, and ask Claude to work out why and update the skill itself. Replace the old version and run it again. A few loops gets most skills consistent.

In the live build, the first test report had the right structure but the formatting was off and it had not handled the site photos at all. The fix was one message: this is okay, but you have not handled the photos correctly, figure out why and change the skill so it handles them going forward. Claude diagnosed the miss and rewrote its own instructions so the next run would place them properly.

Compare that with the site reporting skill I had already spent weeks refining for the ContractorOS library. Same workflow, many more iteration loops. On the demo day it read the superintendent’s rough notes, the sign-in sheet, the tailgate meeting record and two site photos, produced the report as a downloadable Word document, and captioned each photo automatically. It also surfaced a 45 minute ready-mix pump delay from the notes as a potential change order for the PM, unprompted, because the skill tells it to look for exactly that.

Two habits make the loop work. First, missing information stays blank. A report skill should never invent site facts; gaps are for you to fill on review. Second, when the output is wrong, resist fixing the document by hand. Fix the skill. Hand-editing feels faster on the day and guarantees the same error next week.

Common mistakes when building construction skills

Most skills that fail die the same few ways: a body written like a manual, triggers buried where Claude never reads them, output corrected by hand instead of at the source, one bloated skill doing five jobs, or judgment quietly handed to the machine. All five are avoidable at build time.

• Writing a manual instead of a procedure. The skill body is the procedure and the contract, not documentation. The cash-flow forecasting skill in the ContractorOS library handles time-phasing and scenario levers in 113 lines of markdown, and anything much past 120 lines is a sign the detail belongs in the reference files, not the body.
• Burying the trigger. Claude decides whether to use a skill from its description field, which Anthropic caps at 1,024 characters. Every phrase someone would naturally type belongs there. The body only loads after the skill has already triggered.
• One giant skill. One skill, one routine. Site reporting is one skill; change orders are another. A monolith triggers unpredictably and is painful to iterate.
• Fixing the output instead of the skill. Covered above, and repeated here because it is the most common one.
• Letting the skill own the judgment. The skill formats, extracts and cross-checks. It does not assess percent complete, price a variation or decide whether a notice goes out. Those calls stay with the person who walked the site.
• Assuming scripts run everywhere. A skill used in the chat window cannot execute code there. If your skill depends on scripts, it needs Cowork or Claude Code. Check where your team will actually run it before you build around code.

Site reporting is one example. The same approach works for any workflow where the process stays the same and the inputs change. Watch the full video above for the complete build, start to finish, including the demo of the finished ContractorOS site reporting skill going from rough notes to a final Word document.