Architecture Studio 1.4: The Skills You Write Yourself

The numbers

We open-sourced Architecture Studio on March 2, 2026. The 1.3 post went out a week ago at 255 stars. Since then:

• 283 GitHub stars and 58 forks
• 1,470 unique visitors and 627 unique cloners in the last 14 days — visitors up 28% over the 1.3 window, cloners up 83%
• Google is now the top inbound channel: 835 unique referrals in 14 days against LinkedIn’s 96. The launch ran on one LinkedIn post; the traffic since runs on search. AEC Magazine sent another 19 after Martyn Day covered the judgement stack.
• Nine releases, now at v1.4.0, and 46 skills

Release day itself was the biggest day in the window — 545 views against a baseline near 110.

What 1.4 changes

Every release until now shipped things you install. 1.4 ships the place your own work lives.

/as:studio initializes a studio workspace you own: a portable STUDIO.md registry, your working units, your default jurisdiction, a plain-language data-governance boundary, and project folders underneath it. /as:studio create-project, register-project, archive-project, and projects manage the registry from there. Installing the plugin still creates nothing — no workspace, no account, no cloud store, no git repository. The workspace appears when you ask for it. The full workspace and memory model is in the repo.

Firm-owned skills

An initialized studio gets a .claude/skills/ directory, and so does every project under it. /as:skill-maker now writes there by default instead of into the catalog — which means the procedures your firm writes live outside the installed plugin cache and survive every update we ship. Studio-level skills are firm standards. Project-level skills are the client, the jurisdiction, the delivery method. Anything general enough comes back upstream as a contribution — that guide is explicit that private firm procedures stay in your workspace, and only general-purpose work belongs in a pull request.

That is the whole shape of the thing now, and it is the argument from Architecture Firms Need an Agent Harness, shipped. We maintain the framework, the governance rules, and 46 working reference implementations. Your practice layer grows next to it, in files you own. Distributing them across a team works the way it always has.

One interface for project memory

v1.2 gave projects a dossier and a decision log. 1.4 collapses both behind /as:project — init, update, remember, decisions, record-decision, supersede. The old /project-dossier and /decision commands are gone, with no aliases.

Decision files are now the only canonical record. PROJECT.md no longer keeps a Decisions table, and /as:project migrate removes it from an existing project only after every row has a matching decision file. Meeting minutes, site visit reports, tasks, work plans, and time entries all hand facts and decisions to the same place and read decision files directly — each one an independently owned file with source links and a non-destructive history.

/as:workplan joins them: a Markdown-only planning workflow that separates facts from assumptions, traces requirements into verifiable work units, and stops at an explicit handoff.

The migration

1.4 is a breaking release, and the break is the install identity. The plugin is now as@skills-for-architects and commands are /as:<skill>.

Update the marketplace, uninstall architecture-studio@skills-for-architects, install as@skills-for-architects, reload plugins. Coming from v1.2 or earlier, uninstall the old numbered plugins and install directly — there is no need to stop at 1.3 on the way. The reinstall replaces plugin code and touches nothing you own.

The install guide has the Claude Desktop walkthrough with screenshots, and the CHANGELOG carries the complete migration notes.

What 1.3 promised, and where it landed

The 1.3 post said the standalone harness was in development: durable studio memory, firm-authored skills, governed connectors. Two of three shipped here. Connectors did not. /as:studio init writes a root .mcp.json holding an empty mcpServers object and nothing else — no provider, no endpoint, no credential, no OAuth. It is a reserved boundary, and calling it anything more would be a lie about what is in the file.

Two other honest limits: XLS/XLSX product data is still out, so FF&E runs on a project-local product-library.csv, and we do not claim to migrate anyone’s disconnected cloud data. Old master-schedule.json and canoa.json files are preserved as evidence — Canoa became Norma last spring — and you export your own rows to CSV before importing.

Tell us when it breaks

Four issues in five months, on a repo with 283 stars and 627 people cloning it every two weeks. That ratio is wrong, and it is the number we would most like to change.

The issue tracker is the right place for anything that does not work, anything missing, and any jurisdiction we have not covered. There are two forms — bug report and feature request — and both ask for your version and the skill involved, because that is what makes a report actionable. The one real bug anyone has filed was a good one: output files getting written outside the path the user chose, without confirmation. That report made the catalog better than any feature request would have.

/as:studio-feedback does the drafting for you. It collects the fields, flags anything in your report that looks like confidential client or project information, shows you the URL parameters GitHub will receive, and then stops. You open the browser. You press submit. Nothing leaves your machine without you doing it.

What belongs there: bugs, gaps, and general-purpose capabilities. What does not: your firm’s proprietary procedures — those belong in your own studio workspace, and 1.4 exists so they have somewhere to live.

What’s next

The advanced /as:learn track — plan mode, subagents, precedent study, headless runs, and git for a firm’s skill library. Connectors after that, when there is something real behind the boundary.

If you are new to all of it, the README has a terminal preflight written for people who have never opened one: install, log in, type /as:learn. The cheat sheet is worth a browser tab while you go, and the product page has the wider shape of where this is heading.