Architecture Studio at Three Months: Your Project Gets a Memory

The numbers

We open-sourced Architecture Studio on March 2, 2026, and wrote up the first month when it crossed 100 stars. Three months in:

• 179 GitHub stars and 40 forks (102 and 30 at five weeks)
• 1,236 unique visitors and 259 unique clones in the last 14 days alone — GitHub only reports a rolling two-week window, so that’s current pace, not a running total
• Seven releases since v1.0.0 in May, now at v1.2.1
• The catalog grew from 37 to 39 skills, from 9 to 10 plugins

One number we’re watching honestly: the stars-to-forks ratio drifted from roughly 3:1 to 4.5:1 — closer to a typical tool repo. Early on, forking-to-customize was the signal we cared about most. It’s still happening, but the newer audience looks more like installers than customizers. That tracks with where the work went, as you’ll see below.

What shipped

The first month was about skills. The last two months were mostly about structure — the unglamorous releases that decide whether a public catalog stays trustworthy as it grows.

v1.0–v1.1 (May) restructured everything into a plugin marketplace: skills bundled by project lifecycle (due diligence → site planning → zoning → programming → specs → sustainability → materials → presentations), a /studio router that reads your request and hands off, and a CI lint that fails the build if the README claims a count that doesn’t match the actual files. If we say 39 skills, there are 39 skills — the robot checks.

v1.2 (June) is the release we’d been circling for a while. Three things:

1. Every project gets a dossier

A building project spans months and a team. Without shared state, every session re-derives the same facts — the lot, the zoning district, the code edition — and the reasoning behind choices dies in email threads and meeting minutes. Ask anyone six months into a project why scheme B won, and watch the archaeology begin.

Software solved half of this years ago with Architecture Decision Records — short, numbered files that capture the context, the options, the call, and the consequences. The construction industry never adopted an equivalent. Which is funny, because they’re called architecture decision records.

So v1.2 ships them for actual architecture. Two layers, both plain files in your project folder:

• PROJECT.md — the facts. Address, zoning district, FAR, program, code edition. Every entry carries its source and date. /project-dossier maintains it.
• decisions/ — the reasoning. Numbered records with context, options considered, the decision, and consequences. Decisions get superseded, never deleted — the trail is the point. /decision captures them.

The analysis skills are wired into both: they check the dossier before fetching (no re-deriving what’s on file), append their findings after, and when an analysis surfaces a real choice — an as-of-right envelope versus a City of Yes bonus path, a code edition, a carbon threshold — they propose recording it.

There’s no sync service, no dashboard, no accounts. The dossier is shared however your project already is — git, Drive, Dropbox. Files outlive tools.

2. Agents became native

The seven agents (site planner, NYC zoning expert, workplace strategist, and the rest) used to be documents the router read at runtime. Now each one ships inside the plugin it orchestrates and registers directly with Claude Code on install — so Claude can delegate to them on its own, not just when you go through /studio.

3. Hooks install themselves

The quality hooks — the disclaimer check on regulatory outputs, the CSI section-number lint — used to require hand-editing your settings file, which in practice meant nobody ran them. They now register automatically when the Dispatcher plugin is enabled. Zero setup, and you can switch them off per session.

What we said in April vs. what happened

The first-month post promised three things. Scorecard:

1. “More skills.” Barely — 37 to 39. The honest version: we spent the skill-writing time on structure instead (the marketplace, the lint, the dossier). Material takeoffs and code-compliance checking are still on the list, not in the repo.
2. “Canoa integration.” Canoa became Norma. The FF&E pipeline now runs fully standalone on Google Sheets — no product dependency — and exports schedules ready for Norma when you want the database behind it.
3. “Team distribution.” This one structure solved for free: plugins now carry their agents and hooks, so installing a plugin is the distribution. One marketplace add, and everyone on the team gets the same skills, the same agents, the same quality checks.

What’s next

Two things we’re actively circling:

• Worked examples. The catalog tells you what each skill does; it doesn’t yet show a full project run end to end. Bundled walkthroughs are the biggest gap between “starred it” and “uses it weekly.”
• An MCP server for NYC PLUTO. The most-used data source in the catalog, turned from fetch-and-parse into a tool Claude can query directly.

The repo is public and MIT-licensed, and every number above links to its public source. If you’re an architect or designer curious what AI can actually hold onto across a real project — start here.