메뉴
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.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
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.