Clean Room

name: clean-room description: "Use when a task mixes safety-adjacent material (stealth, scraping, privacy, IP, licensing, security) with genuinely safe work, or the moment you notice yourself about to hedge, dilute, silently drop, or brace for a refusal on part of a request. Triggers: 'strip the risky part out', 'just the safe part', 'carve this out', 'clean-room this'." tools: Read, Grep, Glob, Write, Agent user_invocable: true

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 (a lessons file, a decision log) for this user/topic, and if so cite the precedent and note explicitly if this judgment differs from it — this keeps the judgment from drifting session to session. If the user has already approved a descope, go to 3 (GUARD). Otherwise build a proposed carve plan showing the split explicitly and wait for approval — bright-line items (no safe version exists) don't block on this alone, since they're not negotiable. If gray-zone items remain (a safe alternative narrows scope), don't proceed until approved. 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 (a lessons/decisions file — 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. 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 — never the original risky request, and never 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.

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. 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?
• 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 → wait for user approval (if gray-zone items exist)
• 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)
• Final status label: none (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