Conciseness

The ~780-line body is noticeably verbose: dated incident narratives ("F168 PR #2214 实测 21 轮", "operator 2026-07-15 投诉②修复"), rationale essays, and time-stamped SHAs/dates ("main `1419b60a74`") sit in live sections rather than an old-patterns section, and key rules are restated across 核心知识, 合入方式, Common Mistakes, and QA. This fits anchor 2 ('several unnecessary explanations or padded sections') rather than anchor 3 ('mostly efficient with some tightening possible') because the padding is extensive and structural; it avoids anchor 1 only because the material is novel project policy rather than concepts Claude already knows.

Actionability

The body is dominated by concrete, executable guidance: complete bash blocks (root artifact guard with regex, PR-body @handle checks, hotfix detection with jq parsing, `classify-merge-outcome.mjs` three-state case handling, worktree finish/retain), the E1–E5 table pairing each check with a verification command and failure action, and an exact MCP parameter table for Step 7.6. It stops short of anchor 5 because of placeholder-laden snippets ({PR_NUMBER}, {branch}) and prose-only steps like the 6.5 guardian gate that defer to 'live schema' rather than concrete invocations.

Workflow Clarity

The sequence is explicitly numbered (Step 0.5 → 6.8 → 6.9 → 7 → 7.5a–c → 7.6 → 8 → 8.5) with exceptional validation checkpoints, fail-closed gates, feedback loops (re-run check-feature-truth after doc sync, CI repair state machine, three-state merge exit classification), and checklists. Held at 4 rather than 5 because the linear path is fragmented across interleaved policy essays and duplicated in Quick Reference / Common Mistakes, so a reader must reassemble the order from multiple sections.

Progressive Disclosure

Scored against the actual bundle: no references/, scripts/, or assets/ directories exist, so ~73KB of niche policy (browser verification policy, targeted 终态语义, 判例 #4152/#4163, 封板协议, Evidence Manifest field tables, CI Repair Loop) is inlined in SKILL.md — content that clearly belongs in separate reference files, matching anchor 2. It is above anchor 1 because section headers are clear and external references (../.cat-cafe-shared-refs/pr-template.md, pr-signals.md, sop-definitions/development.yaml) are well signaled and one level deep.

Specificity

The description lists several concrete actions — "合入 main，消费风险匹配的验证与适用的 review 证据", author self-verification ("产品快车道的作者自验"), risk-required independent review, and "受影响检查支撑的合入证据" — with only minor gaps in coverage. It falls short of anchor 5 because the actions are wrapped in project-internal jargon (e.g. "产品快车道") that is not self-explanatory, but it clearly exceeds anchor 3's '1-2 concrete actions'.

Completeness

It explicitly answers both what ("合入 main，消费风险匹配的验证与适用的 review 证据") and when ("Use when: 准备合入 PR") with a concrete trigger phrase, and goes further with explicit "Not for" exclusions and an Output clause. This matches the anchor-5 example structure of what + explicit when with concrete trigger phrases.

Trigger Term Quality

The description itself contains natural phrases users would say ("合入 main", "准备合入 PR", "review"), and the frontmatter triggers list adds "merge", "开 PR", "gh pr create", "cloud review" for good bilingual coverage. It is not a 5 because a few natural variations (English "merge PR", "code review", "squash merge") are absent from the description itself.

Distinctiveness Conflict Risk

The niche is clear (post-review merge flow into main) and the "Not for: 未完成作者自检、处理 review findings 或 Feature 终态验收" clause explicitly excludes adjacent skills. Not a 5 because triggers like "cloud review" and "开 PR" overlap with the review-request/receive skills in the same family, creating minor conflict risk.