Files

vitya 49e5c1dd5c feat(using-system-snapshot): new skill v0.1.0

Thin read-only skill wrapping the single meta_system_snapshot MCP call
(poller status + local docker + cached cross-project task summary).
Replaces the scatter of tasklist / docker ps / manual meta_status.

Core rule: no claim about poller / local-docker / task-load state
without calling the tool in the current turn. Output = three lines,
one per section (docker lists only problem containers; tasks gives
Sigma active/blocked + busiest 2-3 projects). Liveness split documented
(poller+docker live, tasks from cache). Scope boundaries: deep single-
container diagnosis -> using-vds-ops / docker logs; precise per-task work
-> using-projects-meta. Read-only, no per-session grant.

Output shape verified by a live snapshot call 2026-06-09.
Wiki: concepts/using-system-snapshot-design.md + index + log.
TDD N/A (markdown policy artifact); behavioral smoke-test = paired
skill-using-system-snapshot-review task.

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

2026-06-09 16:44:34 +03:00

2.6 KiB

Raw Blame History

title, type, updated

title	type	updated
using-system-snapshot skill design	concept	2026-06-09

using-system-snapshot skill design

New policy+technique skill (v0.1.0) wrapping the single MCP call mcp__projects-meta__meta_system_snapshot. Replaces the old scatter of tasklist + docker ps + a manual meta_status read with one round-trip for session-start ops orientation.

Why a skill

The failure mode it guards: an agent asserts "the poller is running" / "all containers are up" / "you have N active tasks" from memory or a stale earlier snapshot, without re-checking. The skill makes the rule explicit — no claim about poller / local-docker / task-load state without calling the tool in the current turn. Mirrors the read-only, no-grant posture of using-vds-ops.

Tool output shape (verified live 2026-06-09)

Three keys:

poller: { running: bool, projects: "<owner/repo …>" } — live.
docker: [{ name, status }] — local machine containers (includes agents-task-runner-*), NOT the VDS. Status strings like Up 4 hours, Up 26 hours (healthy); problems show as Restarting / Exited / (unhealthy) / Created / Paused. live.
tasks: { "<owner>/<repo>": { active, blocked } } — from the projects-meta cache, so approximate.

Design decisions

Output = three lines, one per section (per task spec). Docker line reports N/N up when all healthy, else lists only the bad containers; tasks line gives Σ active / Σ blocked + the busiest 2–3 projects. Never dump raw JSON.
Liveness split made explicit. Poller + docker are read at call time; task counts come from the cache. The skill tells the agent to flag task-count staleness and defer precise per-task work to projects-meta-skills (using-projects-meta Step 0 freshness gate, or local .tasks/ on disk).
Scope boundaries. Deep single-container diagnosis (logs/inspect/stats) is explicitly out — that's using-vds-ops for the VDS or docker logs locally. The snapshot only carries name + status.
Read-only, no per-session grant — same as using-vds-ops. The tool takes no args; no preview/confirm dance (unlike the projects-meta mutations).

Prerequisites

Needs mcp__projects-meta__meta_system_snapshot (shipped by projects-meta-mcp; the meta-system-snapshot capability lives in OpeItcLoc03/common). If the tool is absent, the server isn't registered → setup-projects-meta.

TDD note

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.

2.6 KiB Raw Blame History Unescape Escape