Clean Room

<!-- provenance: adapted from LilMGenius/paperthin "autobahn" skill (MIT license). Core mechanism (carve -> clean subagent -> verify -> ledger) preserved; reformatted to this repo's SKILL.md conventions, renamed to avoid reusing the original author's skill name verbatim. Upgraded after an adversarial 3-lens design critique (adversarial-user / isolation-integrity / systemic-integration-gap) surfaced gaps the source design didn't cover in a harness with shared filesystem state between the main session and its subagents. Reconciled with upstream autobahn v0.14.0 (RUN's risk-lens fan-out folded into VERIFY step 5(e)'s single independent re-sweep, capped at N=1 rather than open-ended). See CHANGELOG.md. -->

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. 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 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, using a subagent type that has only the tools the task needs (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 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.