// 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.
| name | pr-draft-summary |
| description | 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. |
Produce the PR-ready summary after substantive code work: a concise summary plus a PR title and draft description. The block should be ready to paste into a PR.
src/), tests, docs with behavior impact, or build configuration.git rev-parse --abbrev-ref HEADgit status -sbgit ls-files --others --exclude-standardgit diff --name-only and git diff --name-only --cachedgit tag -l 'v*' --sort=-v:refname | head -n1git rev-parse --abbrev-ref --symbolic-full-name @{upstream} 2>/dev/null || echo origin/maingit log --oneline --no-merges ${BASE_COMMIT}..HEADadds, fix → fixes, refactor → improves, docs → updates.feat/<slug>, fix/<slug>, or docs/<slug>.# Pull Request Draft
## Branch name suggestion
git checkout -b <kebab-case, e.g., feat/add-firewall-tools>
## Title
<single-line imperative title, e.g., "feat: add firewall management tools">
## Description
<Start with "This pull request adds/fixes/improves ...", explain the change, any behavior changes or considerations. No need to list tests.>
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.
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 "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.