Framework Specialist Subagents

Yes, noticeably. Generic Claude knows the framework at a mostly-current tutorial level; a framework subagent knows the current-version idioms, opinionated conventions, and specific gotchas.

The gap shows up most on framework-specific features — Server Components in Next.js 15, Signals in Angular 18, Solid Queue in Rails 8 — where generic Claude often defaults to older or cross-framework patterns.

Match your project's actual Next.js version. Next.js 15 changed defaults (caching is opt-in, params are async), so a 15-expert giving 14 advice — or a 14-expert giving 15 advice — will produce code that looks right but breaks at runtime.

Check your package.json version, then install the matching agent.

Via the description field. Claude Code reads all subagent descriptions on session start and routes work to the one whose description best matches your prompt.

Include:

• Trigger keywords — App Router, Server Components, loaders, guards, Signals, etc.
• The phrase Use PROACTIVELY.

Vague descriptions won't get auto-routed, and the agent will only fire when explicitly invoked with > use the X agent.

Directory-scoped writes plus framework-specific bash commands. Example for Next.js:

• Read, Grep, Glob, Edit
• Write(app/**), Write(components/**), Write(lib/**)
• Bash(pnpm:*), Bash(npx next:*)

Do not allow general Bash — a framework agent should not be running arbitrary shell commands outside its ecosystem.

Sonnet is the right default for framework work. The task is largely applied — knowing the idioms and applying them correctly — which Sonnet handles well.

Reserve Opus for framework agents when the work is architectural (designing a new module structure, choosing a data-fetching strategy for a complex page). Explicit model routing per-task is a bigger cost lever than tuning the frontmatter default.

Whenever the framework has a meaningful release. Cadence varies:

• Next.js — majors every ~6 months.
• Django, Rails — slower cadence.
• SvelteKit, Astro — frequent minor changes.

Our editorial team refreshes framework agents within 48 hours of a major release and does a full rewrite when defaults or conventions change. If you're maintaining your own, plan for a review every quarter and a rewrite at every major.

Yes, and you should. They're complementary:

• CLAUDE.md — tells Claude about your project (name, versions, deployment targets, team conventions).
• Framework agent — tells Claude about the framework itself (default patterns, gotchas, current idioms).

The CLAUDE.md gives project-specific context every session; the agent gives framework-specific expertise on demand.

Install both agents. Give each a directory-scoped tool restriction so they can only write into their part of the codebase:

• Write(apps/web/**) for the Next.js agent.
• Write(apps/api/**) for the FastAPI agent.

Cross-cutting work still routes to the main conversation, but framework-specific work goes to the right specialist. Common pattern for full-stack projects.

Occasionally. If both agents' descriptions match a prompt, Claude Code's routing may be ambiguous.

Prevent it by:

1. Making descriptions non-overlapping — the Next.js agent's description mentions Next.js and App Router; the Remix agent's mentions Remix and loaders.
2. Adding directory-scoped tool restrictions as a hard boundary even if routing gets it wrong.

Yes. Framework agents cost nothing when idle — they're just Markdown files.

The value shows up the moment you actually work on the framework: correct current-version code without you having to remember what changed in the last release.

For frameworks you use less often, the agent is even more valuable — because your own knowledge is more likely to be stale.