actual-mcp-server

The develop-to-main release. Fast-forward main to develop, tag the new version, confirm the publish pipeline is green, AND close the implemented tickets the release ships. Use whenever the user asks to "release", "merge to main", "ship to main", "push to main", "cut a release", "do a release", "release vX.Y.Z", or "promote develop to main". This is the ONLY sanctioned path to main; implement-ticket and merge-pr deliberately stop at develop.

Enforce and automate releases in CI so a promotion to main can never silently ship without a version bump. Documents and governs the release gate (block a main promotion that did not bump VERSION past the last vX.Y.Z tag) plus, on the same VERSION<->tag primitive, the auto-release lanes that already ship in this repo (auto-release a verified @actual-app/api dependency update). The enforced/automated sibling of the invoked `release` skill. Use when the user asks to "enforce version bumps", "block merge without a release", "auto release on merge", "auto-release dependency updates", or "stop forgetting to tag releases".

OWASP API Security Top 10 testing patterns, injection payloads, auth bypass vectors, and security test generation for the actual-mcp-server MCP API. Use when writing security tests, reviewing tools or HTTP endpoints for vulnerabilities, or auditing input validation and authorization.

Analyse every GitHub fork of this repo, and every meaningful BRANCH within each fork, to find features and functionality the forks added that upstream does not have, as a source of ideas to implement. For each newly-identified idea it opens a gate-ready GitHub tracking ticket (crediting the origin fork and original author, linking the exact code to review, flagging that the imported external code MUST get a security review, and requiring positive plus negative scenarios and test cases before implementation). Maintains docs/audit/FORK_ANALYSIS.md as a cache so unchanged fork branches are skipped on the next run. Use whenever the user asks to "analyse the forks", "what do the forks add", "scan forks for features", "fork feature scan", "any new ideas from forks", or wants to harvest fork ideas, even if they do not say the word "fork-analysis".

End-to-end implementation pipeline for a GitHub issue in actual-mcp-server: gate the ticket to 10/10, implement it, validate, code-review it, and either fix findings inline or spin them into their own tickets, then commit + bump + push to develop. Use this whenever the user asks to implement, build out, do, work, or ship a ticket or issue by number, e.g. "implement ticket 167", "implement #178", "do issue 142", "build out ticket 90", or "/implement-ticket 178", even if they do not name every step. Do NOT use it for merely reading, triaging, gating, or reviewing a ticket without implementing it, or for code changes that are not tied to a specific issue number.

Handle a request to merge a GitHub pull request in actual-mcp-server WITHOUT ever merging it directly. Instead, create a gate-ready GitHub ticket to integrate the PR's change onto develop, run that ticket through the full implement-ticket pipeline (gate to 10/10, implement, validate, code review, mandatory /local-env full, commit + patch bump + push develop, confirm CI green), then close the original PR as superseded. The change only ever reaches main later through the normal develop-to-main release. Use this whenever the user asks to merge, accept, land, or pull in a pull request by number or reference, e.g. "merge PR 179", "merge this pull request", "land the dependabot PR", "accept #42", or "/merge-pr 179". Do NOT use it for the develop-to-main release itself, or for git branch merges that are not GitHub PRs.