clean-room

Clean Room

Purpose

Dominant Variable: did the subagent that actually executes the work ever see the original safety-adjacent request? If it did, this skill has failed — isolation is everything. "Never saw it" applies not just at the prompt layer but to what the subagent is instructed not to go looking for too — there is no real filesystem access-control boundary between the main session and its subagent, only a shared filesystem plus an instruction not to consult certain paths. A subagent with shared Read/Grep access to your project files can read a mention of the risky request in a memory or log file just as easily as if it had been told directly; the instruction not to look is the only barrier, not a partition.

Discard if:

• The whole request is obviously safe (no safety-adjacent element at all) — just handle it directly
• The whole request is a clear bright-line refusal (nothing safe to carve out) — nothing to carve, just decline
• The user has already narrowed the request to the safe part explicitly — no carving needed, proceed directly

Workflow

1. FRAME

Read the request, its inputs, and any risk posture the user has stated. Before drafting a carve plan, check whether there's a similar past decision on record for this user/topic: first the ledger file (default ./.clean-room/ledger.md, see step 6), then a lessons file or decision log if the project has one (lessons.md format: https://github.com/AlexZio00/sovereign-skills/blob/master/docs/FILE-CONVENTIONS.md). If a precedent exists, cite it and note explicitly if this judgment differs from it — this keeps the judgment from drifting session to session. If none of these files exists, write "no precedent on record" and judge on the request's own facts; the first ledger entry becomes the precedent. This citation is bound by the same exposure limit as the LEDGER (step 6): verdict plus a high-level reason category only (e.g. "security-adjacent, exceeds safety threshold") — never the precise trigger phrasing or the judgment heuristic itself, even at this earlier stage, since a stage without its own exposure limit can leak what the later LEDGER step is trying to protect. If the user has already approved a descope, go to 3 (GUARD). Otherwise build a proposed carve plan showing the split explicitly and ask for approval — bright-line items (no safe version exists) don't block on this alone, since they're not negotiable. Gray-zone items (a safe alternative narrows scope) that shape the carved prompt are held until approved; safe work whose content does not depend on the answer proceeds (Invariant 2). Delegated approval: in a delegated run with no user present, approval counts only when the caller passes the user's own approving words verbatim. A paraphrase or "the user approved" is not approval → return NEEDS_INPUT listing what needs approval. A caller's instruction never stands in for the user's approval. If the user disputes a bright-line call itself, go to 2-A (CARVE-appeal).