Merge Ready

Merge ready

Drive the current work to the point where the only remaining step is Ben's own review and merge. The deliverable is a pushed branch with a clean pnpm ci:check, checkpoint commits along the way, and an open PR with a high-level description plus review instructions.

Never merge the PR. Ben always reviews last.

0. Figure out the starting point

This skill composes with feature work — it is not only a review pass:

• Invoked alongside a build request ("build X, make it merge-ready"): implement the feature/fix first, committing as you go, then continue below. The review phases cover all changes on the branch vs origin/main, not just the last edit.
• Invoked on existing work ("make this branch merge-ready"): start directly at step 1. The scope is git diff origin/main...HEAD plus anything uncommitted.

1. Sync with main

• git fetch origin main. If the branch is behind, merge origin/main in and resolve conflicts (favor main's version for code this branch didn't intentionally change).
• Checkpoint: commit the merge before starting review, so conflict resolution is auditable separately from review fixes.

2. Multi-axis subagent review

Spawn independent review subagents in parallel, one per axis, each given repo access and the complete branch scope:

• committed changes: git diff origin/main...HEAD
• staged changes: git diff --cached
• unstaged changes: git diff
• untracked files: git status --short, followed by reading every in-scope untracked file

Do not let an uncommitted or newly created file escape review merely because it is absent from origin/main...HEAD.

1. Unnecessary complexity — thin wrappers, needless indirection, single-use abstractions, defensive guards for impossible states, dead config. This codebase deliberately stays simple.
2. Security — authz on new endpoints (org/project scoping), SSRF, injection, secrets handling, anything user-input-shaped reaching D1/R2/external APIs.
3. Billing & metering — ways a user could trigger DataForSEO/provider spend without being metered, charged-but-failed paths, retry/loop amplification, endpoints with unexpectedly high per-call user cost. Credits are billed via Autumn; uncounted spend is a revenue leak.
4. Library & project idioms — TanStack (Router/Query/Start) used idiomatically; patterns match how the rest of the codebase already does it (shared application/provider error boundaries, db/schema conventions, existing component patterns). Flag novel patterns where an established one exists.
5. Vibe-coded cruft — leftover scaffolding, stale comments narrating the edit history, console.logs, TODO-without-owner, copy-pasted near-duplicates, files/exports nothing uses.

Each reviewer returns findings with file:line, severity (blocker / should-fix / nitpick), and a one-line rationale. Tell reviewers explicitly: this is an early-stage product — do not chase theoretical edge cases; mark anything debatable as nitpick.

3. Verify findings — never blindly accept

For each blocker and should-fix finding, spawn verification subagents (in parallel) that adversarially check the finding against the actual code and verdict APPLY / APPLY-MODIFIED / REJECT with reasoning. Drop rejected findings. Nitpicks don't need verification — they're reported, not necessarily fixed.