add-tech-specialist

name	add-tech-specialist
description	Use when the extension adopts a new technology (a library, framework, protocol, or service — e.g. Solr, a language server, a webview UI framework) and you want reusable per-technology expertise. Generates a path-scoped rule + a specialist agent (+ optional skill) so future tasks get current, project-specific guidance on that tech. Trigger: /add-tech-specialist.

/add-tech-specialist — Per-Technology Specialist Generator

Meta-skill. Turns "we now use technology X" into reusable assets: a path-scoped rule capturing how X is used in this extension, a specialist agent that carries that rule and verifies current API, optionally a workflow skill, and a catalog entry so everything is discoverable. This is what makes per-technology analysis (e.g. for Solr) repeatable instead of one-off.

The argument is the technology name, e.g. /add-tech-specialist solr. Derive a slug <name> = lowercase, hyphens only (e.g. solr, language-server, react-webview).

Inputs

• $ARGUMENTS — the technology name. If missing or ambiguous, ask the user for the exact technology and how the extension uses it (runtime dep, build tool, external service, webview UI, protocol) before proceeding.

Workflow

1. Research the technology (web + Context7)

Goal: a current, sourced understanding — do NOT rely on training memory.

• Context7 MCP — mcp__context7__resolve-library-id then get-library-docs for the library's current API shape and version.
• WebSearch / WebFetch — official docs, the project's README/changelog, and recent (date-stamped) ecosystem signals. Capture version numbers and the date you verified them.
• Grep/Glob/Read — find where (or whether) the extension already uses this tech in src/, package.json, and build config, so the rule reflects actual usage, not generic advice.
• Note: API knowledge decays. Record the verification date in the rule's Sources table.

Optionally persist findings to .claude/artifacts/research_<name>.md using .claude/templates/artifacts/research.template.md — useful when the research is substantial or feeds an ADR.

2. Write the path-scoped rule

Create .claude/rules/tech-<name>.md from the stencil .claude/templates/tech_specialist/rule.template.md.

• Set the paths: frontmatter to globs matching where this tech is actually used (broad like src/**/*.ts for a pervasive API; narrow like **/esbuild.* or src/**/*solr*.ts for a localized integration). The rule then auto-loads only on matching edits.
• Fill: Overview (what it is, version targeted, verification date), Core model, Invariants, Gotchas, Best practices, Sources (with dates).
• Keep it concise — it loads into context on every matching edit.

3. Write the specialist agent

Create .claude/agents/specialist-<name>.md from the stencil .claude/templates/tech_specialist/agent.template.md.

• Frontmatter: name: specialist-<name>, model: sonnet, tools: Read, Glob, Grep, WebSearch, WebFetch.
• Body: Focus / Rule Context / Tool Preferences / Output Format / Constraints / On Completion.
• The agent must state it carries .claude/rules/tech-<name>.md as its authoritative context and verifies version-sensitive claims via Context7 / official docs before answering.
• Mirror the exemplars specialist-vscode-api.md and specialist-esbuild.md.

4. (Optional) Add a workflow skill

Only if the tech has a recurring, multi-step workflow worth automating (e.g. "run a Solr query and validate the schema", "regenerate the language-server protocol types"). If so, create .claude/skills/<name>-<verb>/SKILL.md from .claude/templates/claude_mechanisms/skill.template.md. Skip this step for techs that only need reference knowledge — the rule + agent are enough.

5. Update the rule catalog

Update .claude/rules.md (create it if it does not exist yet) so the new assets are discoverable in the same change:

• Add a row under a "By technology" table linking tech-<name>.md and noting its paths: scope and the paired specialist-<name> agent.
• If a skill was added in step 4, list it under the skills section.
• Keep catalog ↔ filesystem in sync — every tech-*.md rule has a catalog row.

6. Report

List the files created/updated:

• .claude/rules/tech-<name>.md
• .claude/agents/specialist-<name>.md
• .claude/skills/<name>-<verb>/SKILL.md (if added)
• .claude/rules.md (updated)
• .claude/artifacts/research_<name>.md (if persisted)

State the verified version of the technology and the verification date.

Templates Referenced

• .claude/templates/tech_specialist/rule.template.md — the rule stencil
• .claude/templates/tech_specialist/agent.template.md — the agent stencil
• .claude/templates/claude_mechanisms/skill.template.md — optional skill stencil
• .claude/templates/artifacts/research.template.md — optional research artifact

Constraints

• ALWAYS verify the API against live sources (Context7 / official docs); cite sources with dates
• ALWAYS set a sensible paths: scope on the rule — never leave the placeholder
• The specialist agent is read-only (analysis/guidance), not implementation
• Keep the catalog in sync in the same change
• Reuse the exemplar specialists' structure; do not invent a new shape

Examples

• /add-tech-specialist solr → tech-solr.md (scoped to the Solr integration files) + specialist-solr.md + catalog row; optional solr-query skill if querying becomes a recurring workflow.
• /add-tech-specialist language-server → rule scoped to the LSP client module + a specialist-language-server agent.

$ARGUMENTS