Proposal: a Boost skill that walks agents through preparing a pull request #1011

Problem

There are hundreds of PRs in mere days. For the maintainers life is going to get hectic!

The PR templates and .ai/guidelines/github.pull-requests.blade.php (#954) say what a good PR needs, but not how to get there step by step. Most of the follow-up work a change pulls in lives in other files, and it's easy for an agent working on one feature file to miss it. While preparing a small composer feature from a fork, I found these were easy to miss:

• KNOWLEDGE_BASE.md updates for user-visible behavior, and new shortcuts in keyboard-shortcuts-dialog.tsx and the knowledge-base shortcuts table.
• Frontend unit tests for new composer logic.
• The 100% coverage run, which can't pass locally without pcov and should be reported as not run.
• The independent review the guidelines require before an agent-made PR is opened.

Titles are mostly fine already: 2 of the last 60 PRs broke the format, and both were from outside contributors.

Proposal

Programmatically improve the quality and pass rate of PRs.

Add a project skill at .ai/skills/devnull-pull-request/. Boost already discovers custom skills there and links them into each agent's skills folder (.claude/skills, .agents/skills, .github/skills, and so on) on boost:install or boost:update, so every contributor's agent gets it without extra setup.

The skill would be procedure only. It points to the existing guidelines and templates as the source of truth and defers to them if anything ever disagrees, instead of restating them. It covers:

1. A scope check against PRODUCT.md, plus a search for existing PRs and issues before building a feature.
2. Branch and diff hygiene for fork-based contributions.
3. A table that maps what changed to what else it needs: knowledge base, shortcut reference, PRODUCT.md, Tom's tool routing, migrations without down(), tests.
4. The exact check commands, including the pcov requirement for the 100% coverage run, and how to tell existing production failures apart from new ones.
5. Title rules matching .commitlintrc.json.
6. Choosing and filling the template, with an example Validation section.
7. Independent review, then publishing only when the user asks.

It also ships a read-only scripts/preflight.sh. The script prints the diff against upstream/production, flags lockfile, .env, media and agent-config changes, untracked and unstaged files, and missing knowledge-base, shortcut or test updates, and checks a proposed title. On the nine sample titles I tried, including Feat(Composer): …, its title check gave the same pass/fail result as the CI commitlint.

Testing so far

I ran the draft against three realistic requests (a readiness check on a UI branch, writing a PR body for a small fix, and fixing a failing title), each once with the skill and once without:

Without the skill, agents already do well, because the existing guidelines and templates carry most of the rules. The skill made the results more complete:

• Only the run with the skill searched for existing work, and it found that feat: pick emoji from a button in the commit and reply composers #252 already covers the same feature I was building. The run without it would have led to a duplicate PR.
• With the skill, the PR body had every template section, and the agent got an independent CODE: PASS before writing it. Without it, the body left out Independent review and Limitations.
• The title test made no difference, since both read .commitlintrc.json correctly.

The runs also caught two problems in my draft, which are now fixed: the title check missed scope errors when the type was capitalised, and the skill didn't mention generating the Wayfinder files (php artisan wayfinder:generate --with-form), without which the frontend checks fail in a fresh checkout.

The cost was about 55 seconds and 5k tokens more per task. That's one run per configuration, so treat the numbers as directional.

Questions for maintainers

• Is a project skill the right home for this, or would you rather extend github.pull-requests.blade.php?
• Should the preflight script stay, or should the skill be text only?
• Any recurring review comments you'd want it to catch that aren't listed above?

If this direction works for you, I'll open a draft PR with the skill and script.