Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add instructions/ibuilder/massing/claude-mdgit clone --depth 1 https://github.com/ibuilder/massingWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.04411 | $0.04411 |
| Opus 5 | $0.02205 | $0.02205 |
| Sonnet 5 | $0.00882 | $0.00882 |
| Haiku 4.5 | $0.00441 | $0.00441 |
Grade A, and why
massing CLAUDE.md scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured yesterday.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 225 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Project: Massing
What this is
A standalone web BIM modeling program + data platform for AEC firms. IFC is the source of truth. The web app is a genuine authoring tool: create a model from scratch (blank IFC → levels/grid datum), then draw walls/columns/slabs/families/MEP via server-side GUID-stable edit recipes — not just a viewer. (Directional change, 2026-07: in-browser authoring is now a first-class goal, reversing the earlier "web = viewer, Blender = editor" split.) Blender/Bonsai remains an optional advanced/interop editor, not the required one. RVT support is an optional, paid Autodesk bridge — never assume RVT can be read offline.
Non-negotiables
- Reference model elements by IFC GlobalId (GUID), never by transient viewer IDs.
- Pre-convert IFC to Fragments on the server; never parse full IFC in the browser at runtime.
- Keep geometry and metadata separate: geometry streams as .frag; data comes from the API.
- Pins/RFIs/punchlist follow the BCF model so they round-trip with other BIM tools.
- The viewer must run fully offline (local WASM, self-hosted tiles).
Stack
- Web: Vite + TS, web-ifc, @thatopen/{fragments,components,components-front,ui}, three (pinned pair).
- Services: Python, ifcopenshell, FastAPI, SQLAlchemy/Postgres, MinIO.
- Editor: Blender + Bonsai, driven via Bonsai-MCP.
- Optional: Autodesk APS Model Derivative (RVT→IFC), behind a feature flag with a cost warning.
Build order
Phase 0 smoke tests → 1 conversion → 2 large-model → 3 viewer/tools → 4 API/BCF → 5 data export → 6 editor/families → 7 deploy.
Watch out for
- @thatopen/components and @thatopen/fragments version coupling — pin a compatible pair.
- Bonsai-MCP execute_blender_code runs arbitrary Python: gate it, save first, chunk big ops.
- Set-origin/georeferencing: preserve real coordinates for export, render near scene origin.
Local environment notes (this machine)
- Bare
nodenow resolves to v24.18.0 — the PATH workaround this line demanded is obsolete (re-measured 2026-08-27).which node→/c/Program Files/nodejs/node→ v24.18.0, npm 11.16.0. v18.8.0 is still installed, at/c/laragon/bin/nodejs/node-v18/node, but it sits later on PATH and you no longer get it by default.export PATH="/c/Program Files/nodejs:$PATH"is therefore belt-and-braces, not a requirement — harmless to keep, and worth keeping in scripts, because the thing that changed is PATH order, which can change back the moment laragon updates. Both manifests declare"engines": {"node": ">=24"}and CI pinsnode-version: 24, so 24 is the supported baseline. This is the fourth wrong value in these three lines, and the first to be wrong in the safe direction: v20.3.1, then a version naming the Node you get after fixing PATH, then a major nobody had run in weeks — and now a workaround that outlived its cause. A stale instruction to do something unnecessary costs less than a stale one to skip something, but it still teaches the reader that this file is not to be trusted, which is the expensive part. A config file that is subtly wrong is worse than one that is silent — four drifts in, the only safe move iswhich node && node -v, never reading this line. - Python ≥ 3.12 is now a HARD FLOOR, not a preference (corrected 2026-08-25; this line said
"guide targets ≥ 3.11" and "prefer a 3.11+ interpreter … if available").
requirements.lockpinsnumpy==2.5.2, and numpy dropped <3.12 at 2.5.0 — so on 3.11 the install does not degrade, it fails outright:No matching distribution found for numpy==2.5.2. CI pinspython-version: "3.12"inci.yml,db-migrations.yml,desktop.ymlandsecurity.yml, and the lock is compiled inpython:3.12-slim, the prod base image. Same failure as the Node line above, in the other language: a floor that moved under a note phrased as advice. "Prefer if available" is what a version note says when nobody has tried the alternative — and the alternative had stopped working. Check a floor by creating the venv, not by reading this line. - RESOLVED 2026-08-27: 3.12.10 installed, and
services/api/.venvnow MEETS the floor. This entry previously said the venv could not meet it and that CI was therefore the only authority for the backend. Both halves are now out of date, and the reason it had drifted was not the one recorded here.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- yesterday First seen · 225 lines · 4,411 tokens per session scan A 85df8bdf9d50
massing CLAUDE.md is an instructions file published in the GitHub repository ibuilder/massing (132 stars, last pushed yesterday), licensed MIT. It adds 4,411 tokens to every session, about $0.0221 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other instructions, from other repositories
solibri-mcp CLAUDE.md
Claude Code instructions for Vanderjohnny/solibri-mcp, covering instruções para agentes (claude code, claude desktop), 1. regra geral: dados, não pixels, quando um print é legítimo, 2. solibri: use a api, nunca a tela and se as ferramentas falharem.
conway AGENTS.md
AGENTS.md instructions for bldrs-ai/conway, covering agents.md, build and test, pr lifecycle, review: codex first, sub-agent on timeout and what the draft gate covers.
opentakeoff AGENTS.md
Instructions for Kentucky-ai/opentakeoff, covering run / build / check, shipping — the required steps, every change, where things live, how the canvas works (the mental model) and conventions.
rvt-mcp AGENTS.md
Instructions for bimwright/rvt-mcp, covering agents.md — rvt-mcp install guide for ai agents, rules for agents, baked-tool routing, prerequisites (check first, stop if any are missing) and step 1 — download the client setup zip.
rvt-mcp CLAUDE.md
Instructions for bimwright/rvt-mcp, covering rvtmcp-mcp, architecture, project structure, build & deploy and build everything (server + all 6 plugin shells).
archsight-aios GEMINI.md
Instructions for ArchSightLabs/archsight-aios, covering gemini.md, 必读入口 and gemini 特别说明.