docs: frontend skills now install from npm, not committed copies

[WiktorStarczewski]

Draft — sequenced last. Depends on frontend-template#27, which itself needs the SDK bumped to a version that ships skills. Order: web-sdk#310 + #311 release → bump frontend-template to 0.16.x → frontend-template#27 → submodule bump here → this.

Documentation only. No code, no setup.sh change — setup.sh already runs yarn install, and the skills now arrive as part of it.

What changes for someone using this template

Nothing they have to do. Clone, run setup.sh, and .claude/skills/ is populated as before.

Two things get better:

• The frontend skills now match the SDK the template pins. They were committed snapshots; react-sdk-patterns here had drifted 174 lines from the agent-tools copy. Bump the SDK and the guidance follows.
• They stop being conditional on a manual step. This file currently concedes that guidance depending on agent-tools "is only available if the user has run the install step" — a separate clone plus two ln -sf lines into ~/.claude/. That step is machine-global, easy to miss, and silently degrades the agent when skipped. The web-SDK skills no longer need it; they install project-locally with the frontend dependencies. The step still covers MASM, Rust-SDK and the slash commands.

Why this content is moving, not disappearing

Two reasons, and the second is the one that motivated the change.

1. Keeping the guidance in sync with the code it describes

These skills document the @miden-sdk/* API. Kept in a separate repo, nothing
ties a skill to the API it describes, so an API change and its documentation
are always two PRs — and the second one is easy to skip. That is not
hypothetical here: every skill shared between agent-tools and
frontend-template had already drifted from its counterpart.

skill	agent-tools	frontend-template
react-sdk-patterns	386	560
testing-patterns	237	338
frontend-pitfalls	202	186
signer-integration	196	186
frontend-source-guide	174	165
vite-wasm-setup	140	134
miden-concepts	116	110

Living in web-sdk and shipping inside each npm tarball fixes both halves of
that. A change to the API and a change to its documentation become the same
PR, and consumers get guidance version-matched to the release in their
lockfile — a project pinned to 0.15 reads 0.15 guidance, not whatever HEAD
happens to say. A stale skill is worse than no skill, because an agent will
follow it confidently.

The split is by what the knowledge is about, not by who consumes it:

• web-sdk owns anything describing the @miden-sdk/* public API.
• agent-tools stays canonical for everything cross-cutting — the MASM
  family, rust-sdk-*, miden-concepts, local-node-validation, and the
  slash commands.

2. Brownfield projects, which the template cannot reach

The template assumes a clean start: clone the repo, take its submodules, its
layout, its build pipeline. That is the right shape for a proof of concept, and
nothing here changes it.

But most people adding Miden are not starting from nothing. They already have a
codebase, or they are on a template of their own, or they simply would rather
not rebase their project onto someone else's scaffold to adopt one SDK. Total
greenfield is not usually achievable in real work, and it is not a reasonable
precondition for getting good agent guidance.

Shipping the skills through npm means those projects get the same content by
installing the SDK — no clone, no submodules, no adopting a foreign layout.
The template and npm create @miden-sdk then become two doors onto one
knowledge base rather than two competing sources of truth: greenfield keeps
the full scaffold, brownfield gets the guidance alone, and both read the same
files at the same version.

Nothing changes for people using the template

This is transparent for existing template users. Clone the template, run
setup.sh (or npm install directly), and .claude/skills/ is populated with
the same skills as before — the prepare script regenerates them from
node_modules as part of the install the template already runs.

The one difference is when the files appear: they are written during install
rather than arriving with the checkout, because they are now generated rather
than committed. Since setup.sh installs dependencies anyway, a normal setup
sees no difference at all.

Two things actually improve:

• The skills now match the SDK the template pins. Previously they were a
  snapshot committed at some past point, which is how they drifted in the first
  place. Bump the SDK and re-run install, and the guidance follows.
• The agent-tools skills stop needing a manual step. Today they are only
  available if the user separately clones agent-tools and symlinks it into
  ~/.claude/skills/ — a machine-global step that most people skip, and that
  the template's own instructions acknowledge much of its guidance depends on.
  Installing them project-locally means a plain clone-and-setup now gets the
  surface the template documents, instead of silently missing it.

Doc corrections along the way

• idxdb-patterns and wasm-bridge are no longer listed under agent-tools — they moved to web-sdk's .claude/skills/, beside the crates they describe (agent-tools#16).
• The "22 skills upstream / 13 mirrored / 9 upstream-only" counts were already stale and would have gone staler. Replaced with a description of what agent-tools is canonical for, which does not need updating every time a skill is added.

Test plan

• After the submodule bump: clone fresh, run setup.sh, confirm .claude/skills/ in frontend-template/ holds all eight
• Confirm the MASM and slash-command guidance still reads correctly for someone who has run the agent-tools install step