Conciseness

The body is dense, imperative, and table-driven with no explanations of concepts Claude already knows — no library tutorials, no format primers. It matches anchor 4 ('efficient; minor instances of over-explanation that could be trimmed'): the closing 'Checklist before CreatePlan' re-derives rules already stated verbatim above (e.g., 'No absolute or out-of-repo paths' repeats the Paths constraint row; 'Ambiguities resolved' repeats the Clarify section), and the 'Testing in milestones' section points to reference-pytest.md twice in one line. Not anchor 5 because these redundancies are tokens a careful pass would merge.

Actionability

Guidance is fully executable: real commands ('source .cursor/env.sh', 'bash .cursor/reinstall-tentacles.sh', 'bash .cursor/cloud-validate.sh --profile ci-tentacles --json', 'python -m tools.extended_linter --base origin/dev'), concrete repo-relative paths, and two copy-paste-ready markdown templates (responsibility map table, step with validation milestone including 'Command: `pytest …`' and 'If fail:' fields). This matches anchor 5 ('fully executable; copy-paste ready code or commands; specific examples cover the common cases') and exceeds anchor 4, whose guidance has minor gaps — the templates here enumerate exactly what each plan step must contain, including pass criteria.

Workflow Clarity

The multi-step process is clearly sequenced with explicit checkpoints: Activation (read octobot-cloud first, skim AGENTS.md) → Clarify (stop and ask before CreatePlan) → Hard constraints → Responsibility map 'Place before phased steps' → Plan shape with a per-step 'Validation milestone' including 'If fail:' recovery → final 'PR gate' linter handoff → a closing checklist. This matches anchor 5 ('clear sequence with explicit validation steps; feedback loops for error recovery; checklists for complex processes') and exceeds anchor 4, which allows minor validation gaps — none are evident: every code step requires unit tests in the same step, failure handling is templated, and submission is gated by the checklist.

Progressive Disclosure

No bundle directories (references/, scripts/, assets/) exist; the body delegates its heaviest detail — the pytest matrix — to a one-level-deep, clearly signaled reference ('[reference-pytest.md](../octobot-cloud/reference-pytest.md)') and routes other detail through the 'Skill and doc routing' table. This matches anchor 4 ('good structure; most content appropriately placed; references mostly clear; minor organization gaps') rather than anchor 5 because the ~120-line body inlines the full rule set (hard-constraint, testing, and milestone-catalog tables) that a bundle could split out, and the routing targets (sibling skills, AGENTS.md files) live outside this bundle and cannot be verified from its structure.

Specificity

The description names the domain ('Authors Cursor Plans for the OctoBot git repo that run on Cursor Cloud Agents') and several concrete requirements — 'repo-relative paths only', 'package/module responsibility maps', 'validation milestones with unit tests (pytest or npm test/vitest)', 'functional tests when relevant', 'package ownership'. It stays between anchor 4 ('several specific actions; minor gaps') and anchor 5: the core action is a single deliverable (authoring plans) supported by constraint lists, and the phrase 'clarify-before-assume ... and clarification before guessing' restates the same requirement twice, so it is not the fully comprehensive, unpadded coverage of anchor 5.

Completeness

Both questions are answered explicitly: what — 'Authors Cursor Plans for the OctoBot git repo that run on Cursor Cloud Agents'; when — 'Automatically applies whenever CreatePlan is used and the plan title or overview/description contains "roadmap"' plus 'when the user asks for a cloud roadmap, cloud-safe multi-step plan, or names cloud-roadmap'. This matches anchor 5 ('clearly and explicitly answers both what AND when with concrete trigger phrases') and clearly exceeds anchor 4, where the 'when' is present but could be more explicit — here the trigger condition is fully specified including case-insensitivity.

Trigger Term Quality

Natural trigger phrases are present: 'roadmap' (case-insensitive), 'cloud roadmap', 'cloud-safe multi-step plan', and the tool-based trigger 'whenever CreatePlan is used'. These are terms a user of this repo would plausibly say, matching anchor 4 ('good keyword coverage; a few natural terms missing') rather than anchor 5's comprehensive synonym/extension coverage — e.g., plain 'multi-step plan' or 'planning' variants without the cloud qualifier are not covered, which is intentional scoping but leaves natural variations missing. It is clearly above anchor 3, which expects missing common variations.

Distinctiveness Conflict Risk

The description is pinned to a clear niche: one named repository ('the OctoBot git repo'), one tool ('CreatePlan'), one keyword ('roadmap'), and a cloud-execution context ('Cursor Cloud Agents'). Triggers are distinct and specific, matching anchor 5 ('clear niche with distinct triggers; minimal conflict risk'). It sits above anchor 4 because the double condition — CreatePlan invocation AND a roadmap keyword in the title/overview — leaves almost no overlap surface with generic planning or authoring skills; the only conceivable overlap (a non-cloud plan titled 'roadmap') is explicitly the skill's intended scope.