My Architect, part 5: shipping skills and MCP via the Claude Code marketplace

This is the finale of the series about My Architect — a system where the project lives on between AI agent sessions. In part 1 I explained why an agent needs memory and a plan. Today, the last piece of the puzzle: how all of this lands on a user's machine in two commands.

The last-mile problem

From the user's perspective, My Architect is three things. The MCP server @my-architect/mcp, which gives the agent thirty-odd tools. The skill myarchitect — behavioral rules: when the agent files a node for a deferred bug on its own, and when it stops and asks. And four slash commands for typical scenarios.

Installation used to look like half a page of instructions. Open .mcp.json, write in the server config, don't mix up the environment variable name. Download SKILL.md, drop it into ~/.claude/skills/, repeat on the work laptop. Every manual step is a place where a person drops off, and where I gain yet another copy of the skill I must remember to update.

The plugin marketplace in Claude Code closed that gap. A marketplace is an ordinary public git repository with a manifest file; a plugin inside it is a folder with a config, a skill and commands. No registration, no moderation, no store: a repo on GitHub is the distribution channel.

Installation through the user's eyes

Export the token once (you get it in Settings → Connect Agent on the site):

export MCP_API_KEY=mcp_YOUR_TOKEN

Then two commands inside Claude Code:

/plugin marketplace add d7561985/my-architect-marketplace
/plugin install my-architect@my-architect-marketplace

The check is /mcp: the my-architect server should show as connected.

Behind the scenes, Claude Code clones the repository, parses the manifest, registers the skill and slash commands, and at session start launches the MCP server with npx -y @my-architect/mcp@latest. The user hasn't edited a single file by hand. That same half-page of instructions shrank to three lines, with almost nothing in them left to break.

Anatomy: two manifests and markdown

The root marketplace.json is a thin wrapper: name, owner, a list of plugins with links to folders. The $schema field points to the schema on json.schemastore.org, so the editor highlights mistakes before the commit.

All the substance is in the plugin's plugin.json:

{
  "name": "my-architect",
  "version": "1.4.0",
  "mcpServers": {
    "my-architect": {
      "command": "npx",
      "args": ["-y", "@my-architect/mcp@latest"],
      "env": {
        "MCP_API_KEY": "${MCP_API_KEY}",
        "MA_API_URL": "https://my-architect.app"
      }
    }
  }
}

One line matters here: "${MCP_API_KEY}". It's a substitution from the user's shell environment at launch time. The repository is public, and secrets have no place in it — the token lives in the user's ~/.zshrc and never leaves their machine.

The rest is markdown. SKILL.md with YAML frontmatter (name and description, which is how Claude decides when to load the skill), and commands/*.md — four files, each becoming a slash command like /my-architect:next. The commands are thin prompt wrappers over the skill: "pick the next task and drive it through Workflow D".

No server code here

There isn't a single line of TypeScript in the marketplace repository. The MCP server lives in the private product repo and is published to npm, and the plugin references @my-architect/mcp@latest. A new server version with new tools ships — users get it on the next Claude Code launch, with zero action on their side and no plugin release.

With the skill it's the other way around, and that's deliberate. SKILL.md lives in the public repo as the single source of truth. The private product repository keeps no copy as a matter of principle: I've already lived through the period when one version of the skill sat in ~/.claude/skills/ as a personal install, another in the product, and they quietly drifted apart. Now the rule is written right into the marketplace's CLAUDE.md: edit here, push from here, users pull from here. Any copy you find is stale by definition.

Version discipline

The marketplace has a non-obvious consequence: /plugin update my-architect fires only if the version in plugin.json has changed. Fix a wording in SKILL.md and push without a bump — no user will ever see it; the update simply won't be offered. So the rule is strict: every visible change is a version bump plus a CHANGELOG entry, even if a single word changed.

Before publishing — claude plugin validate .: both manifests and the skill frontmatter must parse. The release is closed with claude plugin tag, which cross-checks the version in plugin.json, the entry in the marketplace and the git tag being created against each other and only then sets a tag like my-architect--v1.4.0. Version consistency is checked by a tool, not by my attentiveness, and that's the right division of labor.

A month and a half in the changelog

The plugin has been alive since late April, and its changelog turned into a chronicle of how my understanding of agent-with-architect work evolved:

1. v1.0.0 (April 29) — the skill as a proactive backlog tracker plus MCP server auto-configuration.
2. v1.1.0 (May 29) — Workflow C: documents on nodes as the source of truth, validate_project before closing a task.
3. v1.2.0 (June 5) — Workflow D: the architect stopped being an after-the-fact journal; the skill now requires reading the node and docs before the code and updating them as the work goes.
4. v1.3.0 (June 7) — four slash commands: next, progress, doc, reconcile.
5. v1.4.0 (June 7) — a tightened node naming rule: entity, not work, with a server-side linter.

Note: four substantive releases in five weeks, and not one of them required anything from users beyond /plugin update.

Series wrap-up

Five parts add up to one thought. An agent is exactly as strong as the external scaffolding around it.

In part 1 — why that scaffolding is needed: the agent's memory is not the context window but the project structure it reads in one call. In part 2 — what it stands on: YAML files instead of a database, atomic writes and live sync with the canvas. In part 3 — how to make the agent plan like an architect: hierarchy, inherited requirements, the User Story Map. In part 4 — the working loop from get_next_task to complete_task with documentation as part of the task. And today — the last mile: all of it installs in two commands and updates with one.

You can try it at my-architect.app: an account, a token, two commands in Claude Code. If something here doesn't match what you see — write to me; those letters are more useful than praise.