Skip to content
Back to skills

Blind Author

ASecurity

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.

  • 16 stars
  • 0 votes
  • 0 copies
  • 3 views
  • Added September 5, 2026
ai-agentsbash

Security analysis

A100/100

Scanned September 5, 2026

npx -y skills add qwerfunch/cladding --skill blind-author --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Blind Author?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Blind Author
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/qwerfunch-blind-author/badge)](https://www.skillsdirectory.com/skills/qwerfunch-blind-author)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
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`.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.