merge-ready

Agent Skills › every-app/open-seo › merge-ready

merge-ready

GitHub

将分支准备就绪以进行最终审查，包括合并主分支、审查安全性与简化性、检查 API 使用及计费滥用，修复问题并确保本地测试通过，最后更新或创建 PR。

.agents/skills/merge-ready/SKILL.md every-app/open-seo

触发场景

用户要求功能、修复或分支变为 'merge ready' 请求获取更改以准备审查构建请求中附加 'make it merge-ready'

安装

npx skills add every-app/open-seo --skill merge-ready -g -y

更多选项

非标准路径

npx skills add https://github.com/every-app/open-seo/tree/main/.agents/skills/merge-ready -g -y

不安装直接使用

npx skills use every-app/open-seo@merge-ready

指定 Agent (Claude Code)

npx skills add every-app/open-seo --skill merge-ready -a claude-code -g -y

安装 repo 全部 skill

npx skills add every-app/open-seo --all -g -y

预览 repo 内 skill

npx skills add every-app/open-seo --list

SKILL.md

Frontmatter

{
    "name": "merge-ready",
    "metadata": {
        "internal": true
    },
    "description": "Get a branch ready for the maintainer's final review. Review it for security, simplicity, and billing abuse, fix what's real, get checks passing, and open or update the PR. Use whenever the user says a feature, fix, or branch should be \"merge ready\", asks to get changes ready for review, or appends this to a build request (\"build X and make it merge-ready\")."
}

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.