cleanroom-spec

Generates verified clean-room implementation specs for porting peripheral drivers across licenses.

2|Updated May 13, 2026
One-click install
npx skills add https://github.com/curtisgalloway/public-skills --skill cleanroom-spec-curtisgalloway
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: cleanroom-spec
Source: https://github.com/curtisgalloway/public-skills/tree/main/plugins/driver-porting/skills/cleanroom-spec
Command: npx skills add https://github.com/curtisgalloway/public-skills --skill cleanroom-spec-curtisgalloway

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Writing a from-scratch driver for a differently-licensed OS from encumbered source code creates legal contamination risk. This Skill produces a clean-room implementation spec per peripheral, with an enforced transfer protocol, independent verification, leak scanning, and a provenance ledger so the process is evidentiary and defensible. ## Core Features & Use Cases - Structured spec generation: Produces a two-half spec (hardware facts with provenance tags, plus target-OS integration with file:line citations) covering register maps, init sequences, interrupts, DMA, and milestones. - Transfer protocol and verification gate: Spec text is written by a delegated subagent to a scratch path and only lands in docs/ after a fresh independent verifier subagent returns PASS, keeping unverified text out of the orchestrator. - Evidentiary provenance: Maintains a provenance ledger with content hashes, scan reports, and a spec-gap protocol so implementers never need to read the original source. - Use Case: Porting a DWC3 USB controller driver from Linux to Fuchsia — delegate the spec to a subagent, verify it against the pinned kernel commit, land it in docs/, and let implementers write Rust code from the spec alone. ## Quick Start Ask the agent to produce a clean-room implementation spec for a specific peripheral, naming the IP block, target OS, and board, and let it orchestrate the subagent and verifier workflow.

Frequently Asked Questions about cleanroom-spec

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write a clean-room driver spec from Linux source code?▼

Delegate the spec to a subagent that reads the encumbered source and extracts only hardware facts tagged by provenance, never source code. The spec is written to a scratch path, independently verified with a leak scan, and only then landed in docs/ with a ledger entry.

What is the difference between cleanroom-spec and anchored-peripheral-spec?▼

Use cleanroom-spec when porting from encumbered or incompatibly licensed source, where a contamination wall is required. Use anchored-peripheral-spec when the driver source is yours or compatibly licensed, since it anchors every fact to file:line without the clean-room overhead.

How does the clean-room verification process work?▼

A fresh verifier subagent, never the spec author, runs a mechanical leak scan against the pinned source commit and checks structure, attractants, and the usage notice. It returns PASS with a scan report path or FAIL with section and line references, and only PASSed specs land in docs/.

What happens when a spec is missing information the implementer needs?▼

The implementer files a spec-gap by appending a line to docs/spec-gaps/<device>.md, marks the code site TODO(spec-gap), and continues other work. The orchestrator answers the gap via a fresh investigator run, amends and re-verifies the spec, and marks the gap resolved.

Can the orchestrating agent read the encumbered source directly?▼

No. The orchestrator that writes target-OS code must never read the source-OS tree or hold unverified spec text. All source reading is delegated to designated clean-room reader subagents running with a scoped role, and access is logged for the evidentiary record.