review(using-system-snapshot): VERDICT PASS 3/3 — close skill-using-system-snapshot-review

Non-implementer review of skills/using-system-snapshot (v0.1.0). All three
acceptance criteria pass:
- trigger phrases cover real scenarios (4/4 positives + clean negatives)
- no-claim-without-snapshot rule explicit (4 places)
- output format brief (three lines, verified vs live payload)

Evidence: live meta_system_snapshot call confirms the documented poller/docker/
tasks contract; 9 fresh-context subagents over a simulated registry (real
descriptions + using-vds-ops/using-projects-meta/using-tasks competitors) routed
8 cleanly, incl. no false-positive on a docker-compose.yml edit.

3 informational findings, none blocking:
1. cross-project task-count phrasings overlap with using-projects-meta (by-design)
2. local-container deep diagnosis unowned — vds-ops scope, not this skill
3. deployment scaffold missing — not installed, not in hermes/mapping.yaml,
   no -install/-hermes-mapping/-test-trigger baseline tasks

No SKILL.md edits -> no version bump. TDD N/A (review of markdown policy).
Review outcome recorded in .wiki/concepts/using-system-snapshot-design.md + log.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

.wiki/concepts/using-system-snapshot-design.md

@@ -57,3 +57,42 @@ is absent, the server isn't registered → `setup-projects-meta`.
 Markdown policy artifact — no code/test surface (consistent with sibling skill
 tasks). Behavioral trigger smoke-test is the paired `skill-using-system-snapshot-review`
 task, not this implementation task.
+
+## Review outcome (2026-06-09, `skill-using-system-snapshot-review`)
+
+**Verdict: PASS** on all three acceptance criteria. Reviewer was a non-implementer
+session.
+
+- **Tool contract verified live** — a real `meta_system_snapshot` call returned
+  exactly the documented shape (`poller {running, projects}`, `docker [{name,
+  status}]` incl. `agents-task-runner-*` with `Up … (healthy)` strings, `tasks
+  {owner/repo: {active, blocked}}`). The "The call" table and this page are accurate.
+- **Trigger phrases cover real scenarios** ✅ — 9 fresh-context subagents, each
+  given a simulated skill registry (real descriptions + `using-vds-ops` /
+  `using-projects-meta` / `using-tasks` competitors) and one trigger phrase, no
+  hint of the expected answer. 4/4 positives → `using-system-snapshot`; VDS-logs →
+  `using-vds-ops`; mutate/full-board → `using-projects-meta`; `docker-compose.yml`
+  edit → `none` (no false-positive on the "docker" keyword).
+- **No-claim-without-snapshot rule explicit** ✅ — stated in 4 places (Overview
+  core rule, "When to use", "What NOT to do", Common-mistakes table).
+- **Output format brief** ✅ — three-line block, per-line rules, "no raw JSON";
+  confirmed achievable against the live payload.
+
+**Informational findings (none blocking):**
+
+1. **Task-count overlap with `using-projects-meta`.** «сколько активных задач по
+   всем проектам» routed to `using-projects-meta`, not the snapshot. By-design —
+   the skill defers *precise* per-task work and the `tasks` line is a bonus of the
+   combined ops view, not its headline — so no fix. Quick «сводка по задачам …»
+   glances still route here correctly.
+2. **Local-container deep diagnosis is unowned.** «локальный контейнер … почему
+   рестартует» routed to `using-vds-ops` (its incident-phrase triggers grabbed a
+   *local* container, which its VDS-only tools can't reach). Not this skill's
+   defect — the snapshot correctly does not claim deep "why". Candidate
+   `using-vds-ops` scoping follow-up if it recurs.
+3. **Deployment scaffold missing.** The skill is committed (`skills/…`, v0.1.0)
+   but is **not** installed to `~/.claude/skills/`, **not** in
+   `hermes/mapping.yaml`, and has no `-install` / `-hermes-mapping` /
+   `-test-trigger` baseline tasks (unlike `meta-host-routing` / `delegate-task`).
+   Recommended follow-ups before it reaches live sessions; hermes mode could be
+   `auto` since the skill is read-only (owner's call).