branch-reviewlisted

Assess whether this branch is ready to be submitted as a reviewable pull request. ## Analysis Steps 0. Gather the exact numbers first: `"$HOME"/.claude/library/scripts/branch-facts.sh [base]` emits JSON (ahead/behind, conventional-commit and branch-name compliance, WIP commits, diff size, conflict markers, TODOs and console.logs added, test files touched, svu bump). Judge from these facts; the steps below are the judgement layer, not fact-gathering to repeat by hand. 1. Identify the base branch (usually `main`) and list all commits since diverging 2. Review the full diff for: - Incomplete work (half-implemented features, placeholder logic) - Obvious bugs or unhandled edge cases - Code quality issues that would block a reviewer 3. Check commit history: - Conventional commit compliance (`type(scope): description`) - Logical atomicity — each commit should represent one coherent change - No WIP, fixup, or junk commits that should have been cleaned up 4. Check branch name against naming conventions: - Format: `<prefix>/<short-description>` (lowercase, hyphens, imperative) - Valid prefixes: `feat`, `fix`, `enhance`, `refactor`, `types`, `perf`, `styles`, `layout`, `docs`, `test`, `deps`, `config`, `build`, `agents`, `chore`, `ci`, `deploy`, `spike`, `experiment`, `wip`, `hotfix` - Breaking change branches should use `<prefix>/breaking-<description>` 5. Scan for anti-patterns: - Debugging artefacts (`console.log`, commented-out code) - Unresolved c