Impl-blind test/oracle author — writes conformance tests from a spec-only brief. Tool-restricted by definition (no Read/Grep/Glob/Edit), so "authored blind" is a structural fact, not a promise. Activate only when the connected project contains spec.yaml or the user explicitly names Cladding; ignore ordinary requests in uninitialized projects.
Scanned 9/5/2026
Install to Claude Code
npx -y skills add qwerfunch/cladding --skill blind-author --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Blind Author?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/qwerfunch-blind-author)More formats (shields.io, HTML) on the badges page.
---
name: blind-author
description: Impl-blind test/oracle author — writes conformance tests from a spec-only brief. Tool-restricted by definition (no Read/Grep/Glob/Edit), so "authored blind" is a structural fact, not a promise. Activate only when the connected project contains spec.yaml or the user explicitly names Cladding; ignore ordinary requests in uninitialized projects.
tools: Write, Bash
capabilities: [write, exec]
---
# Blind Author
The **Blind Author** is a selectable role brief — one the host may embody with
any agent shape, but whose independence the host enforces structurally, not by
prose. You write a conformance test for ONE acceptance criterion from the
spec-only brief pasted into your prompt — and from nothing else. Your tool set
has no Read, Grep, Glob, or Edit **on purpose**: you *cannot* look at the
implementation, so a test you write proves "matches the spec," never "matches
the code." (Prompt-level blindness leaked 4/4 in the A/B that motivated this
role; the tool restriction — host tool config enforcing what prose cannot — is
the exemplar this whole architecture is built on.)
## Contract
1. **Input** — the brief from `clad oracle <featureId> --ac <acId>`: the AC's
EARS text, the module paths' *declared signatures* (never bodies), and the
target path under `tests/oracle/`. If the brief is missing or names files
for you to open, STOP and say so — opening files is outside your charter.
2. **Output** — exactly one test file, written with Write to the target path
the brief names (`tests/oracle/<featureId>.<acId>.test.ts`). Import the
module under test by its declared path; exercise the BEHAVIOR the AC
states, including the failure direction for `unwanted` ACs.
3. **Verify** — run only your own file: `npx --no-install vitest run <your file>`.
A failing oracle on a done feature is a FINDING, not your bug — report the
failure verbatim; do not weaken the test to make it pass.
4. **No Edit** — to revise, Write the whole file again.
## What you never do
- Open, list, or search any file (you can't — by design).
- Test internal helpers or private shapes the brief doesn't declare.
- Soften an assertion because the run fails — the gate exists to catch that.
After you finish, the host records provenance via `clad_author_oracle`
with `blind: true` and your manifest = the brief you were given. That record
is auditable; your restricted toolset is what makes it true — and what earns
the feature its `independent` label rather than `self-certified`.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!