Conciseness

Nearly all content is repo-specific knowledge Claude could not know (precedents, deploy traps, incident history), so it does not explain known concepts — but the prose is noticeably dense: 100+ word sentences with nested parentheticals ('*(Origin: shipping #571's root-word search fix, I scoped down to inflectional matching, filed the broader fuzzy/typo fix as #573, and stopped...)*') and long narrative asides that could be tightened without losing information. Mostly efficient but with real tightening headroom, matching the 3 anchor.

Actionability

Concrete, executable guidance throughout: '`tsc --noEmit`, `prettier --check .`', '`just worktree <branch>`', '`git fetch origin main`, then `git diff origin/main -- <file>`', 'upgrade→downgrade→upgrade round-trip against real Postgres', the 32-char `alembic_version` limit with the `NNNN_short_slug` convention. Falls short of 5 because sections like 'Sweep the pattern' and 'Solve the broader problem' are principle-narrative rather than concrete procedure, leaving minor gaps.

Workflow Clarity

Each domain carries explicit validation checkpoints ('Verify before shipping: tsc, prettier, build ... manually verified on the dev server'), the paid-run flow is a numbered order of operations with a dry-run + scoped-live-check gate, and error-recovery guidance exists (post-merge `alembic_version` query, the `StringDataRightTruncation` failure mode, 'testing the downgrade' resolving doubt). Validation is present so no cap applies, but there is no single coherent top-level sequence — it is per-domain procedures — and the front-end section has no explicit failure-recovery loop, placing it at 4 rather than 5.

Progressive Disclosure

Section headers are clear and per-domain organization is sensible, but this is a ~103-line single-file body with no bundle files at all, and the handback catalogue table plus the incident-history narratives (the #489/#486 migration handbacks, the #571/#573 origin story) are precisely the non-resident material that could live in a one-level-deep reference file. This matches the 3 anchor: 'some structure ... content that should be separate is inline'.

Specificity

Names concrete capabilities — 'deciding whether a change is yours to ship or needs the maintainer's approval first', 'look up what to verify before shipping it' — and enumerates its coverage domains ('front-end, backend, migrations, paid production runs, dead-code removal, concurrent-session safety'). This matches the 'several specific actions; minor gaps' anchor rather than 5, since the enumerated items are coverage areas rather than a comprehensive list of concrete actions.

Completeness

Explicitly answers both questions: the 'what' ('the per-domain carve-out details behind `.claude/rules/workflow.md` rule 10 ... plus the catalogue of handbacks that produced each grant') and the 'when' with multiple concrete trigger phrases ('Use when deciding whether a change is yours to ship', 'Invoke before opening a PR', 'before committing or merging while other sessions are running'). Clearly matches the top anchor.

Trigger Term Quality

Natural trigger phrases are present and idiomatic: 'before opening a PR', 'when tempted to ask "want me to ship this?"', 'before committing or merging while other sessions are running'. Good keyword coverage (ship, PR, commit, merge, approval, verify), but a few natural variants users might say ('ask permission', 'deploy', 'can I merge') are missing, so it sits at 4 rather than the comprehensive-synonyms anchor at 5.

Distinctiveness Conflict Risk

It occupies a clear niche — ship-vs-ask approval decisions and pre-ship verification for this repo's workflow rule — with distinct triggers (PR, merge, commit, concurrent sessions, maintainer approval) that no generic skill would claim. Minimal conflict risk.