mcpField
M
merge-ready

merge-ready

github.com/every-appTesting & quality25.5k2.3k installsUpdated 2d ago
Repository

About merge-ready

merge-ready is a code-review skill that prepares a branch for a maintainer's final review. It checks changes against origin/main, addresses real issues, runs local checks, and opens or updates a pull request without merging it.

Key features

  1. 01Fetches and merges origin/main when behind
  2. 02Reviews committed and uncommitted branch changes
  3. 03Checks security, simplicity, and billing abuse risks
  4. 04Fixes issues and commits changes
  5. 05Runs pnpm ci:check and pnpm test
  6. 06Opens or updates a pull request

Use cases

  1. 01Prepare a feature branch for maintainer review
  2. 02Check changes for security and billing risks
  3. 03Run project checks and submit a pull request

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/every-app/open-seo --skill merge-ready

After installing, type/merge-readyin Claude Code to confirm it loaded.

Details

From the project README

Get this branch ready for the maintainer's final review. If you were also asked to build something, build it first.

Fetch and merge origin/main if the branch is behind. Then review everything on the branch against it, including uncommitted and untracked files. Make sure you understand every product decision and change in functionality.

Is it secure?

Is it as simple as it can be? What can be deleted or simplified given the end state of the branch? Did an unlikely edge case lead to overengineering? We prefer to delete code.

Does it use APIs and SDKs (TanStack, DataForSEO, Autumn, Cloudflare) idiomatically? Watch for code that reinvents what they already do, works around limits they don't have, or pays for more than it needs. Check the docs only when something looks off.

Is there a significant way to abuse billing, like getting credits, paid features, or provider calls without paying? Ignore small leaks nobody would bother exploiting.

Beyond that, review it however you think best. Work out which parts could do the most damage if they're wrong and spend your time there. docs/maintainers/review-guidelines.md lists the repo's invariants and the things that look wrong but are intentional.

Fix what's real. Commit as you go. Get pnpm ci:check and pnpm test passing locally, then push. Those local runs stand in for CI, so don't wait for GitHub CI to finish.

Open or update the PR against main. Write the description in the simple-issue-description format, and put anything you left for the maintainer's judgment under Extra context.

Never merge. The maintainer reviews last.

Comments

Markdown supported