clean-room-risk-screen
Clean-Room Risk Screen
Overview
This skill checks whether a proposed path relies on employer-confidential materials, sensitive data, restricted customer access, or unsafe regulated-role framing. The goal is not to provide legal advice. The goal is to separate allowed behavior from risky behavior and propose safer adjacent paths.
Load references/risk-categories.md when classifying risk. Load
references/safer-alternatives.md when the original path is unsafe.
When to use
- When a user wants to monetize domain knowledge tied to a job or employer
- When an offer may drift into legal, compliance, healthcare, tax, or similar regulated-role overreach
- When a product plan may depend on PHI, employer data, customer data, or unclear IP ownership
Do NOT use when:
- There is no meaningful IP, data, or role-boundary risk in the plan
Workflow
1. Identify risk category
Classify risk across:
- employer IP/confidentiality
- customer access rights
- sensitive or regulated data
- licensed or regulated authority
- unsafe claims or positioning
2. Decide allowed, conditional, and blocked actions
Produce three buckets:
allowedconditionalblocked
Be concrete. Do not hide behind vague warnings.
Do not allow paraphrasing or recreating employer-confidential materials from memory as a fake clean-room workaround.
3. Propose a clean-room path
If the original path is risky, propose a safer adjacent route based on:
- public data
- independent firsthand knowledge
- newly created original assets
- generalized workflow understanding
- human-in-the-loop support instead of delegated judgment
4. Produce the memo
Return both:
- a readable risk memo
- a JSON block using
assets/risk-screen-template.json
Use the template field names exactly.
Default sections:
Risk SummaryAllowedConditionalBlockedSafer PathStructured Risk Screen
Checklist
- Specific risks are named, not implied
- Allowed, conditional, and blocked actions are concrete
- A safer adjacent path is offered when needed
- The response avoids pretending to give formal legal advice
- Readable memo and structured JSON are both present
Common mistakes
| Mistake | Fix |
|---|---|
| Vague legal warning | Name exact blocked behaviors |
| Treating generalized knowledge as fully blocked | Preserve lawful generalized knowledge where possible |
| Missing safer path | Offer a clean-room alternative, not just a stop sign |
Key principles
- Specificity matters — Name exactly what is blocked, conditional, and allowed.
- Clean-room beats temptation — Safer adjacent paths matter more than clever justifications.
- Generalized knowledge can remain usable — Restrict confidential assets, not lawful judgment itself.
More from accolver/skill-maker
git-conventional-commits
Generate conventional commit messages from staged git changes when the task is to name or format a commit, not to review code or write release notes.
16pdf-toolkit
Operate the bundled PDF scripts to extract, OCR, create, merge, split, or convert PDFs when the task explicitly involves PDF document processing.
14nostr-event-builder
Construct valid Nostr event JSON and tag structures from requirements when the task is to create or validate concrete events rather than choose which NIPs to use.
12error-handling
Standardize application error handling—taxonomy, propagation, response shapes, logging, and correlation IDs—when the task is to improve consistency of existing error behavior across a codebase.
12api-doc-generator
Generate API reference documentation from source code—endpoints, schemas, auth, errors, and examples—when the task is to document an existing API rather than design or implement one.
12monitoring-setup
Add production observability—health checks, metrics, tracing, alerts, and runbooks—when the task is to instrument or operationalize an existing service.
11