Menú
Use when reviewing or modifying ZOB communication, ledgers, Mission Control coms, or live transport safety gates.
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
| name | zob-coms-safety |
| description | Use when reviewing or modifying ZOB communication, ledgers, Mission Control coms, or live transport safety gates. |
ZOB coms live transport may be transient, but ZOB audit must stay metadata-only.
.pi/coms/messages.jsonl and .pi/coms/status.jsonl as canonical hash-only ledgers.bodyStored=false for persisted coms records.taskHash, outputHash, artifactRefs, sessionHash, and endpointHash instead of raw content.normal/urgent/force semantics: urgent is steer-only and must not abort; force requires an explicit transient reason, stores only reasonHash/interruptReasonHash, and remains blocked unless topology, room, role, rate, lease, and local-socket guards pass.waiting status as delivery/control metadata only, not as read/digestion proof or TODO completion evidence; opt-in required responses must expire terminally unless an exact msgId-correlated reply arrives. Use zpeer_reply or /zpeer reply <msgId> <response> only when the msgId is active inbound; wrong, expired, or already-answered msgIds must block.details.msgId, never taskHash alone; taskHash remains an integrity check. Multiple eligible inbounds are ambiguous and must fail closed without transport.DELEGATION_REQUEST.v1, ORACLE_REQUEST.v1, CONTEXT_REQUEST.v1, OWNER_CHANGE_REQUEST.v1) as proposals only: parent/governor decides; extraction must not dispatch, mutate TODO state, apply owner changes, or store raw bodies.body, task, prompt, output, content, message, text, rationale, diff, or patch keys in persisted ZOB ledgers or Mission Control artifacts.force ZPeer send without an explicit reason hash, no forged/broad force escalation, and no force fallback to append-only or tmux delivery success.For tmux-backed ZAgent teams:
control room with lanes/tags/artifact sections unless a bounded owner-approved route exists.For parallel owner micro-worker pools:
OWNER_CHANGE_REQUEST.v1/governed request metadata and wait for owner/parent decision.--no-extensions children, use final-output OWNER_CHANGE_REQUEST.v1 blocks with requested_by, owner_worker, requested_paths, body_hash, change_hash, reason_hash, optional validation_plan_hash, safe refs, and FINAL_MARKER: OWNER_CHANGE_REQUEST_END; parent extraction appends Goal Room metadata only.No-ship if:
.pi/coms contains raw prompt/output/body-like fields;force works without reason hash, bypasses topology/room/role/local-socket guards, or persists raw reason/message bodies;zob_coms_readiness fails.Use when an active ZOB handoff, live peer question, required-local coms delivery, or orchestration message is needed.
Use when planning, using, reviewing, or implementing ZOB /goal-linked TODOs, subtodos, TODO HUD progress, delegated TODO claims, or hierarchical subagent work graphs.
Use when working inside the ZOB Pi harness, designing agentic workflows, creating specialist prompts, adding Pi extensions, or turning repeated tasks into software factories.
Use before non-trivial work, uncertain tool selection, orchestration, delegation, context lookup, factory work, autonomous-runtime claims, or evidence-gated completion.
Use when driving the append-only metadata-only worklist blackboard — appending events, reading derived directives, leasing/satisfying directives by content hash, delivering idempotent DIRECTIVE_READY notifications, running the liveness watchdog (observe/escalate), or building/querying the dependency DAG.
Use when running, documenting, or reviewing adaptive active search backend context discovery, including zob_context_search, optional ColGREP setup, and grep/find/read fallback behavior.