From hackathon to a live project: what ten days of Claude skills in Revit taught us (part 2)

In part 1 we described one hackathon session: Claude Code connected to Revit through an MCP server (Model Context Protocol), an empty project and a toy structural frame. The verdict was a fast junior who needs a complete brief and a reviewer. This article covers the ten days that followed, when the same team put the agent onto a live data-centre project.

The client is a design studio specialising in data centres whose standard is set by finished reference models, including a recent, fully specified one from a top-tier engineering consultancy. Our job was to achieve that standard on a new project: wall types, doors, ceilings, floor finishes and rooms, coded the way the references do it. Three of us did the work: our information manager and two modellers, one of them still new to Revit. The tools were Claude Code, an open-source Revit MCP server with its Revit plugin, Speckle and a small set of in-house skills.

This is for BIM managers, information managers and digital leads deciding whether AI agents belong in production workflows. It matters because a demo shows one run and a live model shows the second. Below: what a skill is, how we built and broke ours, four episodes, our rules and the agent's limits.

A skill is a written procedure, in natural language, that the agent reads before it acts. It is not a script and not a chat prompt: it is a file published to the organisation that says, for one task, what to look at, which types to use, how to code them and when to stop and ask. Ours cover wall types, door types, ceiling types, floor finishes and rooms, plus a general-geometry skill for massing.

The difference shows on screen. With the skills installed, the agent narrated each step and guessed less; without them, it produced only a final report. It also asked better questions. Before swapping wall types it asked what each room was: were the cores reinforced concrete, was the delivery dock a road? One modeller said what the rest of us thought: he liked that it asked.

How we built them from a reference model

None was written from scratch: each skill started as a working session. A modeller opened the reference model beside the working file, did the task with the agent, then asked Claude to create a skill from the session and upload it to the organisation. Two rules came out of the first days:

• Build the skill from the whole conversation, not the closing report. The report is only the final result. The reasoning and the corrections live in the chat.
• A skill that triggers actions must not vary between projects. Where the reference shows no clear pattern, the skill tells the agent to ask, so that a person decides.

For floor finishes it created a colour-fill legend in Revit through the MCP server, after we stopped it writing pyRevit scripts from memory. When the wall skill was rewritten, the new one went up with a "V2" suffix so its description would not clash with the old one. That is where the housekeeping started.

The housekeeping that went wrong

A good part of the first week was version control: making sure everybody ran the same skill.

• Organisation versus personal copies. One modeller kept getting the old wall logic after it had been deleted, because a copy had been pulled into her personal skills. We deleted the personal copies.
• Stale versions. Two wall skills with similar "use when" descriptions let the agent pick the old one. Duplicates change what the agent does.
• Reload. A new version only takes effect after closing Claude Code and loading the skills again. Forget that and you test yesterday's logic.
• Admin rights. Replacing an organisation skill needs admin or owner rights, which the authors did not have at first.
• Install by default. Ticking it on publish stops one person seeing a skill and another not.

None of this is complex. All of it is invisible until two people get different results from the same prompt.

Ceilings just under the floor above

The reference projects colour rooms through view filters that read elements, not only parameters. So the ceiling skill inserts a reference ceiling about 1 cm below the floor above wherever a room needs one, and leaves it out where the reference does, for example the gantry with its rain grate. Our information manager's first reaction was that modelling a ceiling that does not exist is not BIM. He changed his mind when he saw that filters driven by elements are the smarter arrangement. So far it is useful for filters and nothing else.

Corridor ceilings sat under the floor and disappeared until we configured the view range as unlimited at the top with an offset. Stair and lift cores came out grey instead of green because the floor above had no opening, and the skill does ceilings, not openings. For now stair cores get no ceiling.

The modeller testing it chose the "recommended" option nearly every time; the skill's author said he would have done the same about 90 per cent of the time. Her comment was the useful one: she had not written the skill, so the type names meant nothing to her. A skill has to work for someone who does not already know the answer.

Sixty walls and a seven-layer type

The prompt was short: based on the rooms, introduce wall types, swap them on the plan and set the filters. The agent swapped 60 walls automatically and came back with approvals. Exterior walls at the core and gantry: do not change. Cooling corridor: accept type 105. Twelve facade, six gantry and four substation walls: no change. Walls between two ancillary rooms: accept 104. One-word answers were enough.

Then the problems:

• Columns. They changed colour with the walls, because "automatically joins" was on in the column family. We undid, reloaded the family without it and recoloured.
• Long walls. One changed type along its whole length, because the agent cannot cut a wall.
• Hand edits. Twice, a modeller fixed a wall by hand and the agent reverted it on its next pass.
• Layers. The new types had the right names, codes and thicknesses, but layers and materials copied from the source types. The skill had no build-up catalogue; its author had worked out the layers in his own session and never written them in.

Version 2 added them, and the red wall type came through with all seven layers and the client's index prefix in place of the reference's.

A building from a Speckle link, twice

The first attempt was the ambitious one, a big step from the toy frame. A modeller gave the agent a Speckle link to the concept geometry, a site-plan PDF and an orchestrator skill, and let it run unattended for about two hours. It created the structure in system families, then recognised generator sets and racks by their names. Told to work in the background, it wrote a Revit file to a folder with Revit closed. The run used the whole five-hour usage window and was followed by a two-hour wait. The PDF and the Speckle geometry disagreed in places, and we never established which one the agent leaned on.

The supervised rebuild was slower and more instructive. Speckle did not carry the Rhino parameters or any other metadata, so the agent read names and guessed. Some elements were boxes named as rooms, "office" for example, which it outlined with walls, leaving gaps and one double wall. It offered to straighten walls that were slightly off-axis, which was genuinely useful. But after fighting wall by wall, our information manager came to the conclusion that the last walls might be quicker drawn by hand. The source was a sketch, and a sketch has no pattern to repeat.

Rooms: do not let it guess

Rooms showed the repeatability problem most clearly. On a re-run, the skill asked room questions it had not asked the first time. One room it could not identify turned out to be roof space.

The fix is hints, not freedom. Rooms take their names from the Speckle source. Where there is no name, the room is "not specified", never an invented label, and hints go on the plan as text the agent can read. When it still cannot tell, it asks. As one modeller put it, the agent does not read, it guesses, unless you give it something to read.

• Test new skills on a clean context on another person's machine. The author's Claude remembers the reference, so it passes tests a new user would fail.
• Feed real geometry, not screenshots. A few numbers cost less context than an image, and a PDF beats a browser screenshot.
• A reference project beats a prompt. With the reference open in the same Revit session, the agent found nine door types and took its rules from the reference rather than the skill. That bit us: the copy of the reference was very old, so it chose the wrong doors. Keep references current and family names identical every run.
• Supervised MCP for project changes, background generation only for loadable families. Anything that would modify the project model happens live, with a person watching.
• Step narration and approvals are features. They are how you catch a reverted hand edit. Long unattended runs need auto-accept, which we do not want on a project model.
• Repeatability is the metric. A skill that answers differently on the second run is still a demo.
• Treat "execute Revit code" with caution. In full-power mode, with all its capabilities enabled, the server runs arbitrary code and follows your commands literally, including what you did not mean. The agent asks and ends with a checklist, Ctrl-Z works until someone saves and synchronises, and the agent sees only the file open on the modeller's machine. The server is community-built, so its Revit plugin and local bridge are a data-security question too, and its permissions need careful configuration; more in MCP in Revit. Our information manager would rather the agent wrote pyRevit code, with every change approved inside Revit.

This belongs on one page of a BIM execution plan, where an agent can follow it as easily as a person. Model names in ACC take a project number, client code, building code (DC01), ZZ in the level field, a model-type field, discipline (A for architecture), then a suffix for site (ST) or context (CX). Work in progress lives in a "01 WIP" subfolder. Fixed naming and templates keep documents consistent and let the next project reuse the skills.

The sync to Speckle is now automatic: in Speckle's ACC integration you connect, choose the team and project, tick the models and create a sync, and Speckle pulls new versions from then on. The client's Speckle dashboards depend on the reference parameters our skills write. The open risk is coordinates: linked context and masterplan models may not share them.

At the end of the ten days we sat down with the client's founder and an external software studio.

The client's vision is not design automation. Masterplanning stays human, and test-fits are not the target. The target is production and detailing, from definitive to executive design, architecture first: sheets, wall types, door schedules, so that five or six senior professionals who carry the responsibility can move faster. Augment the seniors, do not replace them.

The plan has three steps. First, an instruction book: daily workflows, which we had written as checklists for two or three weeks and as skills for one, turned into a written explanation that is also machine-readable. The studio's developer proposed giving an LLM the whole book and letting it interview people chapter by chapter; the founder doubted interviews would work and would rather record meetings and systematise recurring problems. Second, AI integrations: connectors between the tools. Third, an interface that lowers the AI barrier for architects. The book is expected to rewrite itself as the work goes on.

The point that matters most to a BIM manager came from the founder: in twenty years, every R&D project he had seen in an architecture office failed, and the only things that stuck were tested daily on a live project.

Token economics came up too. A platform's built-in AI feature sells model access dearer than a direct connection through AI coding tools such as Claude Code, which also lets you choose the AI model. Because MCP is an open protocol, you can switch AI provider without rebuilding the connection to Revit. We had explored a local workstation running local models with unlimited tokens. We did not buy it: it runs Linux and cannot run Revit.

• Cut a wall or place a door. The door skill swaps existing doors by room context; with no doors in the model there was nothing to attach to. A door-location skill is next, and we expect it to get 80 to 90 per cent right.
• Know a build-up it was never given. The layer catalogue had to be written into the skill. Floor openings are not supported yet.
• Run cheaply. One unattended run used a whole usage window, and we expect tokens to get more expensive, one more reason for firm standards.

And the limit that matters most: we have no measured time saving. One modeller said she had spent two days talking to Claude without opening Revit and felt as if she were cheating. That is a feeling, not a measurement.

FAQ