// Decide how to implement runtime and API changes before editing code. Use when a task changes exported APIs, MCP tool definitions, runtime behavior, or configuration, and you need to choose the compatibility boundary and implementation shape.
This skill should be used when the user asks to "build an MCP server", "create an MCP", "make an MCP integration", "wrap an API for Claude", "expose tools to Claude", "make an MCP app", or discusses building something with the Model Context Protocol. It is the entry point for MCP server development — it interrogates the user about their use case, determines the right deployment model (remote HTTP, MCPB, local stdio), picks a tool-design pattern, and hands off to specialized skills.
Run the verification stack (format, lint, typecheck, test) when changes affect runtime code, tests, or build config.
Audit documentation coverage by comparing implementation against docs/. Use when asked to check doc coverage, sync docs with code, or after significant API surface changes. Produce a report and ask for approval before editing.
Generate a PR-ready summary block with branch suggestion, title, and description. Use in the final handoff after moderate-or-larger code changes; skip for trivial or conversation-only tasks.
This skill should be used when the user asks to "optimize TypeScript performance", "speed up tsc compilation", "configure tsconfig.json", "fix type errors", "improve async patterns", or encounters TS errors (TS2322, TS2339, "is not assignable to"). Also triggers on .ts, .tsx, .d.ts file work involving type definitions, module organization, or memory management. Does NOT cover TypeScript basics, framework-specific patterns, or testing.
| name | implementation-strategy |
| description | Decide how to implement runtime and API changes before editing code. Use when a task changes exported APIs, MCP tool definitions, runtime behavior, or configuration, and you need to choose the compatibility boundary and implementation shape. |
Use this skill before editing code when the task changes runtime behavior or anything that might look like a compatibility concern. The goal is to keep implementations simple while protecting real released contracts.
git tag -l 'v*' --sort=-v:refname | head -n1
State the decision briefly:
Compatibility boundary: latest release tag v0.x.y; branch-local interface rewrite, no shim needed.Compatibility boundary: released tool schema; preserve compatibility and add migration path.