// 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.
| name | docs-sync |
| description | 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. |
Identify doc coverage gaps and inaccuracies by comparing the current implementation (MCP tools, types, API endpoints) against the docs structure, then propose targeted improvements.
Confirm scope and base branch
main).main, analyze only the diff vs main to scope doc updates.Build a feature inventory
src/, their parameters, and descriptions.docs/api/.docs/api/openapi.json.Doc-first pass: review existing pages
docs/.Code-first pass: map features to docs
src/ exports and tool definitions.Detect gaps and inaccuracies
Produce a Docs Sync Report and ask for approval before editing.
Docs Sync Report
- Doc-first findings
- Page + missing content → evidence + suggested insertion point
- Code-first gaps
- Feature + evidence → suggested doc page/section
- Incorrect or outdated docs
- Doc file + issue + correct info + evidence
- Proposed edits
- Doc file → concise change summary
- Questions for the user
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.
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.
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.