actual-mcp-server: Skill for Claude Code

Merge PR (develop-first, never direct)

A request to "merge a PR" is treated as a request to INTEGRATE the PR's change through the normal process, not to click merge. Direct PR merges are forbidden here: most PRs (Dependabot especially) target main, and merging them straight in would bypass the develop-first workflow, skip the version bump and the live /local-env full gate, and re-diverge main from develop. Every change earns its way to main the same way: develop -> ticket -> gate -> implement -> bump -> /local-env full -> CI green -> (later) an explicit release.

The hard rule

• NEVER run gh pr merge (or merge the PR in the UI) as part of this skill.
• A version bump and a passing /local-env full are NON-NEGOTIABLE prerequisites for anything that will eventually reach main. A PR provides neither on its own, so it must go through the ticketed pipeline first.
• The original PR is CLOSED as superseded once its change lands on develop. It never merges to main.

Inputs

The PR number (extract it from the request; if absent, ask). Everything happens on develop; main is untouched.

Pipeline

Phase 1: Inspect the PR

Read it so the integration ticket is accurate and the change is reproducible:

gh pr view <n> --json title,baseRefName,headRefName,labels,author,url,mergeable,statusCheckRollup
gh pr diff <n>                 # the actual change
gh pr diff <n> --name-only     # files touched

Classify it: dependency bump (Dependabot) vs code change; security/CVE driver (check npm audit for the package and the PR's referenced advisories); which files; whether the dep is direct or transitive (npm ls <pkg>). Note the resolved target versions from the lock diff so they can be reproduced exactly.

Phase 2: Refuse the direct merge, explicitly

State plainly that the PR will not be merged directly, and that its change is being routed through the develop-first pipeline (ticket + gate + bump + /local-env full). This is the policy, not a limitation.