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).

2. CARVE

Scan the request and its adjacent inputs for safety-adjacent elements. There is no fixed risk catalog — judge bright-line/gray-zone status case-by-case on this request's own facts. To keep the bar from drifting call to call, cross-check against the precedent surfaced in FRAME (if any prior decision on this user/topic was found); if none exists, judge the item on its own facts and record the reasoning in the ledger so it becomes precedent for next time. For each element, propose verdict=descope, classify it as bright-line (no safe version exists) or gray-zone (a safe alternative narrows scope), and name one risk-free alternative plus an archive location (the ledger file; default ./.clean-room/ledger.md, created on first use — the "negatives as corpus" convention). If the user chooses to keep a gray-zone item anyway, record it in the ledger as kept-by-owner. Only mention descoping technique in as much detail as needed to identify it — no elaboration. Downstream work that touches a bright-line item's output (e.g. organizing or storing scraped results) — even when that downstream step is itself a safe, mechanical operation — should not be handed to the executor framed as "the output of the bright-line step." Give it a generalized assumption instead (e.g. "assume the records already exist") that severs the downstream task from the original source, or the executor can infer the excluded bright-line context while doing otherwise-safe downstream work.

2-A. CARVE-appeal (only when the user disputes a bright-line call)

The same session that felt the pressure doesn't get to reconsider it. Send only an abstract description of the item (excluding the negotiation history and the user's persuasion arguments) to a fresh context for re-evaluation. Whether the fresh re-evaluation upholds the bright-line call or reclassifies it as gray-zone, record in the ledger that an appeal happened and its result. If the same topic gets appealed repeatedly (2+ times), make that pattern visible in the ledger — repetition itself is a signal.

3. GUARD

Compress the carve results into a scope-guard block (an absolute exclusion list + approved alternatives + the context under which the remaining scope was approved) and embed it verbatim in the carved prompt. This block names each excluded item explicitly so the execution stage can't pull it back in — never include the original risky request itself, or the reasoning behind carving it, verbatim. The scope-guard block must also state a minimum safety envelope: one line naming the safe purpose of the task, and one line naming what falls outside it (the prohibited scope). An executor given zero purpose can't distinguish a real boundary from an arbitrary one and may drift back across it in good faith while trying to be helpful — this one-line pair is the minimum needed to make the boundary legible, not an invitation to explain why it exists. Include a standard clause in the scope-guard block telling the executor not to consult any decision logs, memory files, session transcripts, or transcript-search tools during this task — this closes a side channel where the executor could reconstruct the original risky request by reading something this session just archived, or by reading this session's own logs. Carry the active zone to the executor: if a 🔒 FROZEN SCOPE block from the freeze skill is active in this conversation (or the caller supplies an editable/frozen list), copy its EDITABLE, FROZEN and READ-ONLY lists verbatim into the scope-guard block and state that the executor may edit only the EDITABLE paths. Copy the lists only, not the block's task-description heading, since that line may name the risky request. If no zone is active, write "no file zone declared". Instruct the carved prompt to build the safe scope at full strength, with no hedging, apologizing, or watering down.

4. RUN

Dispatch a genuinely fresh-context subagent with only the carved prompt, choosing the narrowest-tool subagent type that actually exists in your harness. Read-only types (for example Explore or Plan in Claude Code) cannot write files — they return text, which this session can then write itself — and task-specific agents usually have their own roles and extra tools (e.g. Bash), so they are not a fit. Prefer a read-only type that returns text; use a general-purpose agent only when the agent must write the output itself, and then state the allowed actions and write scope in the prompt. A general-purpose agent has every tool, including search over memory and transcripts, so the instruction-only limit in Invariant 1 would be the sole barrier. Never pass the executor the original risky request or this session's carving reasoning. Because carving is already done, the executor has no reason to hedge. Keep risk-lens verification consolidated into VERIFY step 5(e)'s single independent re-sweep (N=1) rather than an open-ended fan-out of extra subagents or reviewers at this step. If a new risky element surfaces inside the subagent's work, don't handle it inline — go back to step 2 (CARVE).

5. VERIFY

Run an adversarial pass over the returned output and adjacent artifacts, checking six things: (a) was risky content spelled out in detail (b) was risky content silently dropped without saying so (c) was safe work diluted or excluded just because it sat near a risky element (d) does stale risky material linger nearby (e) carve-accuracy: re-sweep the original task from scratch in a context independent of this session, and diff against the ledger's flagged items — surface anything under-carved (missed risk) or over-carved (wrongly excluded safe work) before the final report. Cap this independent re-sweep at a single pass (N=1) rather than an open-ended fan-out — this one pass also covers the risk-lens review role that step 4 (RUN) delegates here. (f) fence robustness: check the scope-guard block against at least one instance each of common language-mediated bypass techniques (embedded commands, quotation/use-mention framing, scope ambiguity, deixis, indirect speech acts, claimed source authority, instruction conflict, and other pragmatic reframings) — report which category, if any, got through, not just a single pass/fail. (a)-(d) verify the output; (e)-(f) verify the carve judgment and the scope-guard fence itself — these are different targets from (a)-(d), skipping them means nobody catches the original carve's mistakes or a fence that looks solid but isn't.

6. LEDGER

Report the output together with a descope ledger — for every carved-out item: classification (bright-line/gray-zone), verdict (descoped/kept-by-owner), reason, safe alternative, archive location. The user-facing ledger includes verdict + safe alternative + a high-level reason category only (e.g. "security-adjacent, exceeds safety threshold") — never the precise trigger phrasing or the judgment heuristic itself. Keep detailed reasoning only in the archive file. Treat exclusions as a visible decision, not something hidden — but "visible" and "precisely mappable" are different things.

Where the archive goes: append the detailed entry (item, classification, verdict, reason, safe alternative, date) to ./.clean-room/ledger.md in the project root, creating the folder and file if they do not exist. The file holds the detailed reasoning, so keep it out of version control (add .clean-room/ to .gitignore) and write it only after RUN has finished (Invariant 7). If the project has its own decisions or lessons file and the user prefers it, use that instead and say so in the report. If the file cannot be written, print the entry in the report and mark the archive location as "not saved".

Invariants (never violate)

1. The executing subagent sees only the carved prompt — at the prompt layer, and via an instructed restriction on what it may look up (there is no real filesystem access-control boundary here; the subagent shares the same filesystem as the main session and is kept out only by being told not to read certain things): never pass it the original risky request, the carving reasoning, or this session's context. The one sanctioned exception is the minimum safety envelope required by step 3 (GUARD) — the one-line safe purpose and one-line prohibited scope, both scrubbed of the original request's specifics — which the executor needs to recognize the boundary as a boundary. The carved prompt must also not instruct or permit consulting decision logs, memory files, or session-transcript search tools. Violation → the executor either becomes aware of the risky request and starts hedging/diluting/refusing, or reconstructs the original by stumbling onto something this session just archived during "safe" due-diligence lookup — either way, isolation (the whole point of this skill) is void.
2. Never enter RUN with an unapproved gray-zone item: if a gray-zone item still shapes the carved prompt and the user hasn't answered, don't start step 4 for that item. Safe items whose content does not depend on the pending answer still run first — hold only the dependent ones; bundling safe work behind an unanswered question is the over-refusal this skill exists to prevent. If the turn ends with no answer, deliver only the output of the answer-independent safe items and list the held items as "NEEDS_INPUT: " — never read silence as approval or refusal, and never proceed on or delete the gray-zone item on your own. In a delegated run, only the user's own approving words passed verbatim by the caller count as approval; a paraphrase or "the user approved" does not. Bright-line alone doesn't block (not negotiable). Violation → proceeding without user confirmation on a scope-narrowing decision.
3. No probing: never actually ask about an excluded item or gray-zone request "just to see if it goes through" — carving is supposed to clear the scope before such a request ever arises. Violation → defeats the whole preventive point of carving.
4. The scope-guard block must be accurate and portable: embed it verbatim in the carved prompt, and it must block both directions (never re-explain excluded material, never dilute or refuse the scope carving left intact).
5. No unsafe elaboration: never provide more operational detail about a descoping technique than needed for identification. Both the ledger and the carved prompt are bound by this.
6. Never frame this skill as a safeguard-bypass mechanism: it removes the risky request before it ever gets acted on, then executes a genuinely safe prompt — it does not "get a blocked input through," it produces a different, safe input. It cannot let a blocked request through, only build a different, safe one.
7. Preserve negatives-as-corpus — but mind the write timing: archive carved-out material (with its reason and safe alternative) rather than erasing it from the record. But write this archive entry after RUN completes and the subagent has terminated — a ledger entry containing risky-material description sitting on disk during the subagent's active execution window conflicts with Invariant 1's instructed file-access restriction (since there is no real filesystem partition, anything written to disk during that window is technically readable by the subagent). Violation → the subagent reads the archive file mid-task and reconstructs the original.
8. Never claim this skill controls model routing: don't claim it governs model routing, fallback provisioning, or fixed-model selection — that's harness behavior, not skill (prompt) behavior. Violation → the user mistakenly believes this skill has harness-level control and forms wrong expectations about model-switching failures.
9. CARVE-appeal doesn't let the pressured session reconsider itself: a bright-line dispute gets re-evaluated by a fresh context using only an abstract description of the item — never pass along the negotiation history or the user's persuasion arguments to that fresh context. Violation → repeated (polite) pressure erodes a legitimate call without any real re-review.
10. VERIFY isn't complete without checking the CARVE judgment itself: never report completion without step 5's (e) carve-accuracy re-check. Violation → the original CARVE sweep's misses (undetected risk) or over-corrections (wrongly excluded safe work) go straight into the final report unchecked.

Scope Boundary

Rationalization Table

Self-Verification (check before reporting completion — separate from step 5 VERIFY)

Step 5's VERIFY is the workflow step that adversarially re-checks the output content plus the CARVE judgment itself. This section is a separate checklist, done before reporting, that checks whether the skill's execution itself was done correctly — both are needed, neither replaces the other.

Before reporting completion, confirm:

• Did CARVE cover every safety-adjacent item found, without gaps — does each have a classification (bright-line/gray-zone), verdict (descoped/kept-by-owner), safe alternative, and archive location? Were bright-line calls judged case-by-case and cross-checked against the FRAME-stage precedent (if any), rather than assumed from memory or a catalog that doesn't exist?
• Did the RUN subagent receive only the carved prompt plus the minimum safety envelope (one-line safe purpose + one-line prohibited scope), did the embedded guard actually hold both directions (no re-introducing excluded material, no diluting the remaining scope), and did the scope-guard include the archive/session-search access restriction?
• If a file zone was active (FROZEN SCOPE block or a caller-supplied list), did the scope-guard block carry its EDITABLE/FROZEN/READ-ONLY lists without the task-description heading?
• Was safe output kept from being diluted by nearby risky material, and did any risk discovered mid-execution get routed back to CARVE and reflected in the ledger?
• Was VERIFY's (e) carve-accuracy re-check actually performed — does the independent fresh-context re-sweep's diff against the ledger appear in the report?
• Was the ledger archive entry written after RUN completed (not before)?
• Does the final report have an independent LEDGER section with exclusions/classification/reasons/alternatives/archive locations — and does the user-facing version avoid exposing precise trigger reasoning?

If any answer is no, don't report completion — go back to that step and fix it.

Output

• FRAME/CARVE stage: proposed carve plan + bright-line/gray-zone classification + (if any) citation of a similar past precedent → ask for user approval of the gray-zone items; answer-independent safe items may run meanwhile (Invariant 2)
• Final report: the safe-scope output + a Descope Ledger section (per item: classification / verdict / high-level reason category / safe alternative / archive location — precise trigger reasoning not exposed, kept in the archive file only). Items still waiting for an answer are listed as NEEDS_INPUT: <high-level reason category>
• Final status label: none, except NEEDS_INPUT when any item was held (this skill is a scope-separation procedure, not itself subject to a done/partial/broken judgment) — the WORKING/PARTIAL/BROKEN judgment for the produced output follows the nature of the underlying task