Conciseness

Lean and dense throughout: every line carries operational payload (exact commands, paths, metric names, gotchas like "Never `pkill` by pattern: other sessions on the machine run their own servers" and the double-zero polling rationale), with no explanations of concepts Claude already knows. Nothing is clearly trimmable, so it matches anchor 5 rather than anchor 4.

Actionability

Fully copy-paste-ready: complete bash for init/start/teardown including env vars and pid handling, a complete MCP server JSON config with pinned package version, exact endpoints with payload shapes (e.g. `/delete_by_ids` with `{"memory_type": "episode", "memory_ids": ...}`), and concrete verification targets (metric names, db paths, markdown paths). Matches anchor 5.

Workflow Clarity

Clear five-step sequence (start, readiness, drive, read outcome, tear down) with explicit validation checkpoints: poll `cascade.pending` until 0 on two consecutive samples with the reason a single 0 is insufficient, verify the pid is yours (`ps -o args=`) before killing, wait for port release, and per-feature end-state checklists in the feature map. Error-recovery guidance (read `$ROOT.log`, strip ANSI codes before grepping) and defined verifiable end states for destructive delete/purge operations match anchor 5.

Progressive Disclosure

Well-organized numbered sections with clearly signaled one-level-deep pointers into repo files (`docs/reflection.md`, `docs/api.md`, `tests/acceptance/memory_delete/observe.py`). However the feature-map table consumes roughly half the body and is dense lookup-style content that could live in a reference file, so the file goes beyond a lean overview - matching anchor 4 (good structure, minor organization gaps) rather than anchor 5, and clearly above anchor 3 since placement and signaling are otherwise appropriate.

Specificity

Lists multiple concrete actions covering the full lifecycle: "start your own instance", "drive it over HTTP or through Claude Code with everos-mcp", "read the outcome from the layer that owns it (markdown, SQLite, LanceDB, metrics)", "and tear it down". Coverage is comprehensive rather than having minor gaps, matching the anchor 5 example's structure.

Completeness

Clearly answers both: what ("Verify an EverOS change on a real server - start your own instance, drive it... read the outcome... and tear it down") and when ("Use before saying a memory feature works end to end") with a concrete, explicit trigger phrase. The when-clause is specific, not merely implied, matching anchor 5 rather than anchor 4.

Trigger Term Quality

Good natural-term coverage: "verify", "real server", "end to end", "everos-mcp", "memory feature" are phrases a user of this system would actually say. A few natural variations are missing (e.g. "smoke test", "acceptance", "manually test"), so it falls just short of the comprehensive synonym coverage of anchor 5.

Distinctiveness Conflict Risk

Names a clear niche with distinct triggers: "EverOS", "everos-mcp", "LanceDB", "memory feature" - no other skill would plausibly trigger on these terms, so conflict risk is minimal.