zheref

black-voice

Validate a delivered feature after its PR merges — resolve the PR and the issues it closed, take their acceptance criteria verbatim, raise Shalnark once to drive every one of them through ephemeral automated UI tests in the repository's own pinned tooling, and publish pass / fail / not-testable per criterion as a Rikugan page. Use when the maintainer invokes /black-voice [<CODE>#<PR>], or asks for the merged feature to be validated against what was asked for. It is never automatic and never called from a composite; it fixes nothing, merges nothing, and files a failure only on the maintainer's word.

zheref 0 Updated 3w ago
GitHub

Install

npx skillscat add zheref/hatsu/surfaces-antigravity-skills-black-voice

Install via the SkillsCat registry.

SKILL.md

Black Voice — the delivered feature, driven against what was asked for

It merged. Does it actually do the things the issue said it would?

Shalnark's antenna is a remote control: he attaches it, the body performs the routine exactly, and he is
not the one fighting. That is the whole of this skill. Black Voice is the only way Shalnark is ever
raised
— never automatically, never from en, mukai, getsuga, futon or a backlog loop, and never
as a step of anything. The maintainer types it, or it does not happen.

It is not offensive QA. Rukia's equivalent post-merge adversarial pass stays unstaffed until
Akatsuki-AI, by the maintainer's ruling
(docs/ROSTER.md § Rulings of 2026-09-19 — Nobunaga, Shalnark,
the review preamble
), and Black Voice is not it: this validates the delivered behaviour against the
stated criteria and nothing more. Adversarial hypotheses are still Phinks'.

1. Invocation

/black-voice [<CODE>#<PR>]
nen parse black-voice --grammar "[<target:code-hash>]" \
  --line "<the invocation, minus the /black-voice prefix>"

With no argument the target is the latest merged PR of this session — read from the session's efforts
record, or from nen pr fetch over the PRs this session drove, taking the most recently merged. If the
session drove none, the target is asked for, never guessed
: this skill validates something that
merged, and guessing which PR the maintainer meant is the one mistake that wastes a whole validation
run. Ask through the surface's own option picker, seeded with the merged PRs the session can see, and
run on the answer. A missing argument or configuration item is asked for and set up inline
(missing-argument, missing-configuration; `WORKFLOW.md` § 4 Ask, set
up, continue
); an unparseable line is the same trigger, never the end.

A PR that is not merged is refused, naming its state. Black Voice runs after the merge, because until
then the feature the criteria describe does not exist on the trunk.

And the never-from-a-composite rule is mechanical, not manners. Before anything else, read the
session's efforts record: an efforts record open under ren, mukai, en, futon or
backlog-loop means the invoking context is a composite run, and this skill refuses
— it says
which composite is open, that Black Voice is the maintainer's own call, and stops. Nothing about a
composite reaching its own end re-opens the door: the maintainer types it in a session of their own,
or it does not happen.

2. Resolve the specification

  1. The PR — nen pr fetch --target <owner/name> --pr <n>: head, merge state, body, and the issues it
    closed. The body's "How to verify" section is one of the two criteria sources.
  2. The closed issue(s) — each one's acceptance criteria list, verbatim. That list is the other
    source and the primary one: it is what was asked for, where "How to verify" is what the author said to
    check.
  3. Where the two disagree, both are validated and the divergence is itself reported — a gap between
    what was asked for and what the author said to check is a finding about the delivery, not noise.
  4. A PR that closes no issue, or an issue with no acceptance criteria, is reported as such and the run
    validates only "How to verify", saying so. Never derive a criterion from the code: a test written
    from the implementation proves only that the implementation agrees with itself.

3. Classify and resolve the tooling

nen repo classify --repo <checkout>      # role · kind · stack · lanes · gate
/bankai-quality                     # the scenario's pinned E2E / UI automation row

The classification decides which handbooks and lanes apply; /bankai-quality resolves the UI-test
tooling for this repository's bankai_scenario
— XCUITest, Compose UI Test on a Gradle Managed Device,
Maestro against a dev-client build, Playwright, whatever that resolver returns. Never a tool you
remember and never one the resolver did not return.
A scenario with no row is a finding about the
manifest, and every criterion under it is not-testable with that named as the missing capability.

Ephemeral only at v0.42.0. Tests are authored in a checkout, run, reported, and left
uncommitted, and there is no other mode. A persistent mode waits on a tests.uiValidation key in
nen's workflow schema, to be filed against zheref/nen
— until that key exists no repository can
declare one, so a tests.uiValidation value found in a nen/workflow.json is undeclared
configuration nen schema check does not know: read it as ephemeral and say so out loud.

4. Raise Shalnark — once

One subagent, /shalnark, titled black-voice · shalnark · <model alias>, at
models.<surface>.fast (his definition pins sonnet / medium, so no model is passed). The prompt
carries the absolute path of the checkout, the criteria list verbatim with each criterion's source,
the resolved UI tooling and the declared lanes. Every run is ephemeral.

Raised once per invocation. He is not re-raised to retry a failure, and a flake is reported with its
rate rather than run again until it passes. Where /shalnark has no definition on this surface, or
the surface will not raise it, that is a gap reported exactly as `hanten` § 3
reports one — named, never improvised past.

5. Collect the result — one row per criterion

Shalnark returns pass, fail or not-testable for every criterion on the list, each with its
evidence: the test id and the run's own output, the assertion that held, or — for a failure — the failing
assertion excerpt plus the screenshot or recording the runner produced. not-testable names the missing
capability
(no device, no runner, no driver, no scenario row) and is never rendered as a pass. A
criterion that was not attempted was not validated, and the row says so.

A fail becomes a finding in hanten's fixed shape (claude/agents/_review-preamble.md § 4): rule is
the criterion cited by its source — issue and criterion, or the PR's "How to verify" — evidence is the
failing run, proposedFix is what would satisfy the criterion. Shalnark files nothing and fixes
nothing
; the findings come back here.

6. Publish, then offer to file

The result is published as an Artifact page, rendered through
nen report render --variant register in `backlog-board` § 3's data
shape — every key present, generatedAtLocal filled by
"$hatsu_root/scripts/report_time.sh" --at <generatedAt> [--tz <reports.timeZone>] — the Rikugan template, whose desk carries one ask per
failing criterion
(kind DO, the gate it stands at, the criterion quoted as the why, and options that
are the actual next moves) and whose register carries one collapsible row per criterion with its evidence,
while a run with no failure renders the desk cleared. The page is the deliverable; a pasted summary is not.

Then offer to file each failure through `/file` — one issue per failing
criterion, reconciled against the backlog first as that skill requires, filed only on the maintainer's
explicit pick
. A validation run that quietly opens five issues has spent the maintainer's backlog on
behalf of a tool they invoked to look at one feature.

Authority and hard limits

Permitted: read the merged PR, its issues and the checkout; classify; resolve tooling; raise Shalnark
once; author and run ephemeral UI tests in a checkout; publish the page; offer the filings.

  • Never automatic and never called from a composite. No skill invokes Black Voice; the maintainer does.
  • Never fixes anything — not the feature, not the test, not a flake found on the way. A post-merge
    automator that also fixes is an unreviewed change landing behind a validation report.
  • Never merges, pushes, tags, deploys, labels or votes.
  • Never files an issue without the maintainer's pick, and never files one for a not-testable
    criterion — that is a tooling or host gap, reported as one.
  • Never renders not-testable as a pass, never drops a criterion from the list, and never reports a
    run as validated when a criterion was not attempted.
  • Never derives a criterion from the implementation.
  • Never commits a test: every run is ephemeral at v0.42.0, and no tests.uiValidation value makes
    one persistent while the key is absent from nen's schema.
  • Never runs against production data, a live account or a real payment rail (QA-10's discipline):
    synthetic and local, or not-testable.
  • Never improvises a Nen-owned operation — nen pr fetch, nen repo classify, nen report render and
    the declared nen shu lanes are verbs; if nen is unavailable, `ten`
    installs it (missing-tool), and where it cannot the run does not happen, and that is the report.