This PL role sub-skill helps the PL core investigate environment questions before evaluations or end-to-end runs. It checks applicable services, dependencies, hosts, secrets access paths, and startup conditions using configured scripts, then reports evidence and missing configuration for the core to act on.
PL role sub-skill — environment doctoring. Loaded ONLY by the pl core via its routing table; NEVER auto-load from context, never invoke directly.
Run score Not tested
See how to installReview the instructions the agent will receive before you install.
Scripts named below run as bash "${PL_SKILL_DIR}/scripts/<name>.sh" ..., where PL_SKILL_DIR is the
absolute path of the pl skill directory; set it in the same Bash call.
Sub-skill of the PL role. The pl core skill invokes this EXPLICITLY on any
environment doubt: a "not available / missing / down" claim, a restart wish, a
VM/host question, or before opening an evaluation or end-to-end run. Canonical scripts:
the pl skill's scripts/. Read the host/VM registry from ${SNO_ROSTER_FILE:-};
when unset, report "no roster configured" and continue. The TSV columns are
name, address, kind, purpose, and check; no machine inventory ships with the skill.
Use the repo's documented service-address source when one exists.
Read ${SNO_SECRETS_CMD:-} for an optional secrets wrapper: one executable path
that accepts a command and its arguments, injects secrets, and preserves its exit status.
When unset, report "no secrets wrapper configured" and continue.
Read ${OPENAI_BASE_URL:-} for model connectivity; when unset, report
"using the harness's own endpoint" and continue.
Known environment traps: read the project's lessons file (ai-doc/LESSONS.md) when it exists;
propose additions by card.
The environment doctor is software-flavoured: each check below applies when the project uses that tool (Docker, uv/bun, git, a GPU, a VM roster); a check for a tool the project does not use is reported as not applicable, never as a failure.
Environment, resource, and startup blockers are yours (and every executor's) to fix, not to wait on — parking on an environment blocker without attempted self-service is a protocol violation. Most external stalls are environment-class, and a large share of those are FALSE blockages built on stale premises. Hence:
docker ps,
ls, configured secrets-wrapper check). A remembered/recorded "not available" is invalid.general-env-doctor.sh is the standard tool:
run bash "${PL_SKILL_DIR}/scripts/general-env-doctor.sh" (optionally --fix) before ever declaring an environment blocker.
Classes: secrets / creds (auto-repair through the configured wrapper) /
connectivity / deps (uv/bun sync, CLI tools) / workspace (stale locks,
scratch directory, disk) / drift (documented ports versus Docker listeners).
bash "${PL_SKILL_DIR}/scripts/general-env-doctor.sh" secret <NAME> answers "the key is missing" claims —
it checks this shell and the configured secrets wrapper
without printing values; every name, including API-key names, takes the same lookup.
An unset wrapper is an unavailable check, not a missing key.
Query the supplied roster with bash "${PL_SKILL_DIR}/scripts/general-env-doctor.sh" host [<name>].
Before dispatching a VM-dependent journey, run bash "${PL_SKILL_DIR}/scripts/general-env-doctor.sh" vm.
A missing roster reports "no roster configured" and proves no VM reachable;
obtain the run's host configuration before dispatching. A failed VM probe
means do not dispatch onto it.bash "${PL_SKILL_DIR}/scripts/docker-env-doctor.sh" <service> (deterministic).
START/RESTART_OK → run bash "${PL_SKILL_DIR}/scripts/docker-env-doctor.sh" <service> --execute
(Docker Compose by default, or the executable named by ENV_DOCTOR_REBUILD_CMD; two more optional settings, ENV_DOCTOR_COUNTER_REQUIRED_RE (services that must pass a work-counter probe) and ENV_DOCTOR_QUEUES (Redis queues that must be empty), are described in the script header); NO_GROUNDS → investigate logs instead;
BLOCKED_BUSY → another session's work is in flight: do not restart,
report with the script's evidence; INDETERMINATE → a safety signal could not be verified: take no
action and report which signal is missing. By default, direct process kills (pkill,
kill -9) are forbidden. Verdicts auto-append to
ai-doc/ACTIVE/PL/docker-env-doctor-verdicts.jsonl (audit trail).SNO_OWNER_ADDR (the owner's own
Reach address, exported before the PL starts) with the COS that supervises this lane (the
Chief of Staff agent; see the pl core's Terms) on Cc, and that COS may not approve, hold or
edit it (bands and lists: the live decision-rights file,
~/.config/sno/decision-rights.md when present, otherwise the shipped references/decision-rights.md in the pl skill).
A credential is never one of the five. "I cannot find the key" and "I am
locked out" are not escalations at any layer; check the available credential
sources first. Interactive auth stays legal only
because a browser genuinely needs a human at it, and only with the exact
command written out; it is not a place to file a key you did not find.Two rules outrank everything else in this file: never lock yourself out, never lose the key. The encrypted-store rule below applies when the project stores encrypted user data. The operational half is here because this is where an agent lands the moment a key fails.
bash "${PL_SKILL_DIR}/scripts/general-env-doctor.sh" secret <NAME> — the secret lookup in item 2. Run it
before the thought "the key is missing" is allowed to become a sentence in a
card. If the configured sources miss, inspect the repository's documented
credential source before declaring the key absent.Before opening any evaluation or end-to-end run, check the host you will run it on ONCE: probe the run's real dependencies up front and declare any degradation BEFORE the run starts. A failing probe means choose the host NOW from the available ones; do not discover the degradation mid-run, where it costs rounds on a degraded attempt before the host question is even asked.
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Estimate wall-clock time for AI-agent work using measured progress, remaining tasks, and reference data. It can also report user-facing clock times through a dedicated command, while keeping estimates focused on agent work rather than human developer effort.
Use this method when a run reports success but may have done nothing. Trace the code path from entry to downstream effect, identify a narrow observable at each important hop, and report concrete evidence such as changed rows or sent requests that a no-op could not produce.
Summarize recorded work completed, blocked items, questions awaiting the owner, and quota readings in a page of up to 60 lines. Use it after time away or a long work stretch to see what changed, what needs attention, and where the status came from.
Compare problems found by peer review with errors agents recognized in their own conversations. The skill summarizes existing review records and uses each agent’s own model to judge sampled self-check moments over a chosen period.
Create, revise, or review a project charter that states the deliverable, boundaries, settled owner decisions, and observable pass-or-fail success checks. Use it to brief an executor before work begins or to identify concrete mismatches in an existing charter and related work.
Dispatch a production coding request from Claude Code to a direct Codex run. Route the work to Shell, TypeScript, Python, or Rust guidance based on the requested changes, and return Codex’s implementation report after the run completes.