Conciseness

The body is dense and rule-driven with no concept explanations Claude already knows, giving exact commands, TOML snippets, and a handoff template. It fits 'efficient; minor instances that could be trimmed': the validate/dry-run/reload gates appear in both the Scope section ("Run ccb config validate after every edit", "Run ccb reload --dry-run before reload materialization") and again in Required Workflow steps 6-10, a modest redundancy that keeps it below the every-token-earns-its-place anchor at 5 and well above the verbose anchors.

Actionability

Guidance is fully executable and copy-paste ready: "ccb config validate", "ccb reload --dry-run", "cp .ccb/ccb.config .ccb/ccb.config.bak.$(date +%s)", "ccb roles install agentroles.ccb_self", plus concrete TOML binding examples and a literal handoff block. This matches the top anchor for executable commands covering the common cases; there is no vague or pseudocode direction that would drop it to 4.

Workflow Clarity

The 12-step Required Workflow has a clear sequence with explicit validation checkpoints (validate after every edit, dry-run before materialization) and a genuine error-recovery feedback loop in step 7 ("report the full validation error, do not run reload... Restore the previous config when a reliable pre-edit copy exists; otherwise stop and ask"). This is exactly the validate → fix/rollback → retry pattern the top anchor describes; the batch/destructive-operation cap at 3 does not apply because validation is pervasive.

Progressive Disclosure

The body points to a real, one-level-deep reference with a clear condition — "Read `references/config-contracts.md` before complex edits or reload-impact analysis" — and the file exists with appropriate depth. It sits at the 'good structure; minor organization gaps' anchor rather than 5 because the pointer is an inline sentence rather than a labeled navigation section, and the Role Binding TOML rules in the body substantially duplicate the reference's Role Bindings and Windows Topology sections, so the split between overview and reference could be cleaner.

Specificity

The description lists multiple concrete actions — "Design, edit, validate, and prepare reloads for .ccb/ccb.config, role bindings, providers, windows, workspaces, tool windows, sidebar, and provider startup inputs" — with comprehensive coverage of the config surface. It matches the anchor for multiple specific concrete actions and comprehensive coverage; nothing is generic or padded, so it does not fall to the 4 anchor with coverage gaps.

Completeness

The 'what' is clear and concrete (design/edit/validate/prepare reloads for the enumerated config surfaces), and a 'when' is present via "Use only inside ccb_self; non-self agents should delegate CCB config changes to ccb_self" — explicit trigger guidance, so the missing-'Use when' cap at 3 does not apply. However, the 'when' covers scope restrictions rather than natural task triggers, matching the anchor where 'when' could be more explicit or specific rather than the fully explicit trigger phrases at 5.

Trigger Term Quality

It contains good, natural keywords — "ccb.config", "reload", "role bindings", "providers", "validate" — but is missing common variations a user might say ("ccb reload", "agent roles", "ccb setup"). This fits the 'good keyword coverage; a few natural terms missing' anchor rather than the comprehensive-synonyms anchor at 5.

Distinctiveness Conflict Risk

It carves a clear niche: "Private built-in CCB configuration skill for agentroles.ccb_self", with an explicit scoping instruction that non-self agents must delegate. Combined with the unique `.ccb/ccb.config` file path, conflict risk with other skills is minimal, matching the top anchor. It is not merely 'mostly distinct' as at 4 — the delegation clause actively prevents mis-triggering.