An independent magazine about AI at work in construction. Every story starts on a real job site, with the people who used the technology and the results they will answer for.
Tim Fairley Runs Eight AI Skills on Every Tender, and Two Jobs Stay Human | ConstructionMagazine.ai
Tim Fairley Runs Eight AI Skills on Every Tender, and Two Jobs Stay Human
Tim Fairley sells 95 Claude skills for construction. On a live tender he runs eight of them in a fixed order, and two jobs never leave the person: the measurement and the method.
A client sends a hundred pages and wants a price back in five days. That is the tender Tim Fairley, an estimator and commercial manager in Melbourne, builds his methods for. He has packaged 95 of them as skills for Claude and sells them through a paid community, and he teaches the eight he runs on almost every project in public. The advice holds up, because it is organized around a rule about what a model may not do.
Every workflow he writes has the same three parts: an input, a transformation, and a fixed output. The output is fixed in the skill, so a conceptual estimate always comes back in the same spreadsheet layout and a contract review always comes back as the same task list. Before he builds anything, he breaks construction management into eleven domains, lays out each process step by step, and marks which steps make sense for a model and which stay with a person. His test is the tender that matters: nobody should save two hours estimating a $20 million job and find out later they under-quoted by 20 percent.
The rule comes from the economics of the trade rather than from any view about models. A contractor runs at a margin of five to ten percent. An estimate that is five percent wrong has spent the profit before the job starts, and ten percent wrong has spent it twice. That is why every skill he writes ends in an output a person can check in minutes, and why the two steps that carry the most money, the physical count and the markup, get no model at all. He trained as an electrical engineer and spent eight years on infrastructure jobs before he wrote a line of a skill, and the skills read like the checklists of someone who has been on the wrong end of a missed requirement.
We're not trying to save a couple of hours estimating a $20 million project and then find out that we've under-quoted by 20%.
The eight skills, in the order Fairley runs them on a tender
1Index the project and split the drawings into a database
Pull every requirement in the bid documents into a register
→
3Run the conceptual estimate against the historic cost library
→
4Customise the takeoff assemblies from the drawings
→
5Forecast cash flow to find the deepest cash-negative month
→
6Turn the contract into an obligations register
→
7Schedule the document controller to keep the index current
→
8Format a person's methodology as a Gantt chart
Eight skills, and the two the model does not run. AI-assisted illustration.
Index first, then ask
The first step on any job is the project indexer. It turns the bid stack into text the model can search, splits the drawing set, and stores the drawings as a database of what is physically being built rather than as sheets in the order the architect issued them. A slab on sheet one and its section on the last sheet end up as one record. He runs the indexer on a schedule so the context stays current as registers change, and the skill carries a rule: when the model is not sure, it goes back to the source document.
He has measured why the indexing matters. On a 44-question test he wrote against real drawing sets, the model answered 86 percent of the questions correctly from raw images and used about 104,000 tokens per query. From extracted text it reached 98 percent at 66,000 tokens. From his structured database it reached 100 percent at 1,400 tokens. The one-off cost is the indexing run itself, which is heavy. The answer key is his own, and so is the method he sells.
The second step is the requirements register, the skill he calls his favourite. The bid documents hide hundreds of small instructions: remove waste from site, cut the penetrations in the slab, provide the crane for the free-issued mechanical plant. The model reads every document and lists them. Fairley still reads the scope of works and the drawings himself. The register covers the documents he would never have time for, and it becomes his checklist before submission. Every row is either priced or excluded in the letter of offer.
The losses he sees on projects are rarely a mispriced activity everyone knew was in scope. They are the odd requirements buried in the bid documents that nobody priced or excluded.
The conceptual estimate comes next. The skill reads the scope, turns it into activities, and matches each one to a unit rate in his historic cost library. His example is trenching: a past job priced an 800-millimetre trench with four conduits at $150 a metre, and the model judges what that rate should become for a three-conduit trench in different ground. Each line carries a confidence band. Clear scope and a good match get a high band; a thin bill of quantities gets a low one. A $2.3 million job at plus or minus 30 percent is what he expects on the first pass, and he uses it to cross-check the detailed estimate he then builds by hand.
The two jobs that stay with a person
Takeoff is the skill everyone asks about, and Fairley splits it into three steps. His assembly library does the heavy lifting: one light fitting on a drawing means a fitting, a support bracket, ten metres of cable, and two labour hours. The model's first job is to read the drawings and customise that library for the project, the B2 fittings, the 300 and 600 millimetre cable tray, the tray that has to be painted black. Where a drawing carries vector data and text tags, the model counts tagged fittings reliably and marks up the PDF so a person can audit every count. Measuring stays with the person.
The count itself follows a rule he states without hedging: read the tag, not the symbol. A drafter labels a footing F9 and a fitting B2 in the text layer of the drawing, and a model reads a text layer without error. The same model reading the symbol next to the tag, a circle with a line through it, will miss some and invent others. So the takeoff skill searches for tags, returns a count per tag with the sheet and grid reference of every instance, and hands the estimator a list of items to count physically where no tag exists. The model proposes what to count. The estimator counts. Then the assembly library turns each count into labour, materials, and plant, and the markup and margin are applied by hand, with no model in the room.
His own benchmark of the major models on drawing questions found scale and measurement the weakest category for every one of them, with one model well ahead of the rest and still not good enough for a lump-sum price. The result did not change his rule. It confirmed where the line sits, and it gave him a reason to keep the assembly step, which is where a model helps, apart from the measuring step, where it does not.
Where AI can't do quantity takeoffs is with precise measurements and where you're measuring more areas and lengths.
The eighth skill is the one he says to use with caution. It takes a methodology and an estimate and formats them as a Gantt chart, as a live artifact or through a scheduling tool's connector. The methodology is the part it must not write. A construction supervisor with twenty years of experience, in his view, will always plan a job better than a model asked how to deliver it. The model reformats. The person decides how the job gets built.
One rule for eleven domains
Underneath the eight skills is a single design rule that explains why they work on a desk and why a general chatbot does not. Each skill is a small task with a defined input, a defined process, and a defined output, and the output is shaped so that a person can verify it quickly. A requirements register is a table with a source page for every row. A conceptual estimate is a spreadsheet with a confidence band on every line. A contract review is a task list. None of them is a paragraph. A paragraph is the output format that hides its own errors, because a reader scans it and agrees with it, and the polished ones are the worst.
The person drives every step. That sounds like caution, and it is, but it is also what makes the chain reliable. A single long automated run compounds its small error rate across every step. A chain of short skills, each checked, resets the error at every handoff. The eleven domains he mapped, from tendering through delivery to claims, are each broken into steps that a person can own, and the model is invited into the steps that produce a checkable table and kept out of the ones that produce a price.
What a GC found when it checked its own app against the list
In August 2026 one of the GCs we talked to compared its own Procore app against those eight skills. Drawing compare, sub-proposal check, and a prompt that asks for the unknowns before a conceptual estimate were already built. A requirements register was not, so it went on the board. The cash flow forecaster and the contract obligations register stayed further down the list.
Josh Turner, a civil project manager in New Zealand who works inside Fairley's community, teaches the same habit on a smaller channel: pick one workflow, write down the inputs and the human role, then install it as a skill. His worked example is a clause-by-clause review of a $2.4 million civil subcontract against the New Zealand Construction Contracts Act. Ask a model for a risk register with no inputs and a generic one comes back.
Fairley's closing advice is about the skill file, not the model. Run it, be critical of the output every time, feed the corrections back, and the skill improves. His larger claim is that the opportunity for contractors is in their data and their workflows, not in trying a thousand tools. The eight skills are one estimator's answer to that. The rule underneath them, count but do not measure and format but do not plan, is the part a mid-size desk can copy today.
Writing the first skill
Pick one task the desk does on every tender and write down its input, its process, and the exact output layout.
Make the output a table or a list with a source reference on every row, never a paragraph.
Run the skill on a finished job where the answer is known, and mark every row the model got wrong.
Feed the corrections back into the skill file, and run it again before it touches a live tender.
Keep the count and the margin outside the skill. The model proposes what to count. A person counts and prices.