Conciseness

Efficient and assumes domain competence ("The **constraints** aspect controls *runtime* rules about nodes" — no tutorial padding; no explaining what MPS is). Not 5: the Section index and Reference Index overlap in purpose, and `scope-fqn-reference` is pointed to in three places (directives, workflow step 2, index), which could be tightened. Not 3: nearly every line is routing, a pitfall, or a concrete directive — there is no unnecessary explanation.

Actionability

Concrete executable guidance: named MCP tools with parameters ("create it with `mps_mcp_create_model` (`moduleName: "<lang>", `modelName: "<lang>.constraints"` — aspect ID `constraints`, case-sensitive, no `@` suffix")"), exact FQNs, and hard rules ("**must explicitly assign** `node.<prop> = propertyValue`"). Not 5: the executable JSON blueprints are entirely deferred to reference files, so inline coverage of common cases has minor gaps. Not 3: what is inline is specific and directly executable, not pseudocode or vague direction.

Workflow Clarity

The Common-Path Workflow is a clearly sequenced 6-step procedure ending in "Validate with `mps_mcp_check_root_node_problems` and rebuild the language", with explicit error-recovery routing ("if the new constraint is invisible at runtime, run `mps_mcp_reload_all`" and `references/common-failures.md` for symptom-driven fixes). Explicit validation plus feedback loops matches anchor 5, not 4.

Progressive Disclosure

Good hub structure: a "one row, one read" Section index table, a "Start here" pointer for the most common case, and one-level-deep references. Not 5: the Reference Index refers to `references/property-constraints.md` and `references/referent-constraints.md` as single files while the Section index shows those are directories (`references/property-constraints/nodepropertyconstraint-shape.md`), and the two indexes are partially redundant; also no bundle files were present to verify the referenced paths. Not 3: references are clearly signaled, shallow, and content is appropriately split rather than inlined.

Specificity

Lists multiple specific concrete capabilities — "property validators / setters / getters, referent search scopes (imperative or inherited via `ScopeProvider.getScope`), `referentSetHandler` side effects, default-scope blocks, `canBeChild` / `canBeParent` / `canBeAncestor` / `canBeRoot` placement rules, `defaultConcreteConcept` ... scope helpers (`SimpleRoleScope`, `ListScope`, `CompositeScope`, `HidingByNameScope`)" — with named classes and concepts. Anchor 5 fits: comprehensive coverage with no real gaps, so not 4.

Completeness

Explicitly answers both: "what" is the enumerated set of constraint capabilities, and "when" is stated twice — "Use when defining or editing MPS language constraints" and "Reach for this skill whenever the task involves authoring or modifying `<lang>/languageModels/constraints.mps`". Matches the anchor-5 example pattern exactly, not merely the 4 anchor's 'when could be more specific'.

Trigger Term Quality

Natural terms an MPS user would actually say — "defining or editing", "constraints", "validators", "scopes", "canBeChild", plus the file path `<lang>/languageModels/constraints.mps`. For this niche domain the coverage is comprehensive including the concrete file location, so anchor 5 over 4.

Distinctiveness Conflict Risk

Clear niche: the MPS constraints aspect of one named file with concept-specific vocabulary (ConceptConstraints, referentSetHandler, canBe* rules). It is unlikely to trigger for sibling concerns (structure, typesystem, editor, behavior), which the body explicitly disambiguates. Minimal conflict risk — anchor 5, not 4.