A quality-assurance guide for testing a deployed system against agreed scenarios and rules. It requires traceable evidence for each result, rather than trusting a claim that something works.

Use it to turn acceptance criteria into tests, verify behavior across services or over time, check safe retries and recovery, and produce a release verdict.

It finds rejected inputs, inconsistent data, repeated actions, and failed rollbacks before release. It also checks cases kept hidden from the builder to reduce biased testing.

df-qa — Skill for Claude Code and Codex by OneDro1d

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

Any agent

npx skills add OneDro1d/dark-factory --skill df-qa

Clone the repo

git clone --depth 1 https://github.com/OneDro1d/dark-factory

Made for: Claude Code, Codex.

Wrote this? Show the measurements

A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.

README.md

[![agentmods](https://agentmods.dev/badge/skills/onedro1d/dark-factory/df-qa/github.svg)](https://agentmods.dev/skills/onedro1d/dark-factory/df-qa)

Your own site

<a href="https://agentmods.dev/skills/onedro1d/dark-factory/df-qa"><img src="https://agentmods.dev/badge/skills/onedro1d/dark-factory/df-qa/github.svg" alt="Measured on agentmods" height="20"></a>

Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.

Your own site · 80×15

<a href="https://agentmods.dev/skills/onedro1d/dark-factory/df-qa"><img src="https://agentmods.dev/badge/skills/onedro1d/dark-factory/df-qa.svg" alt="Reviewed on agentmods" width="80" height="20"></a>

Per session 119 Skills are progressive disclosure: only the name and description are preloaded; the body loads when the skill is used.

When invoked 810 The whole file, excluding the scripts and references it only reads on demand.

Security scan A 0 findings. A grade says what 26 rules found in the file — not that it is safe.

Origin original No closer match found in the catalogue.

Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

Model	Per session	Once invoked
Fable 5.1	$0.00119	$0.00810
Opus 5	$0.00060	$0.00405
Sonnet 5	$0.00024	$0.00162
Haiku 4.5	$0.00012	$0.00081

Measured 8d ago against content hash aa4afac17eb7, method: parsed. Prices are Anthropic first-party input rates as of 2026-09-09, from the pricing page.

Security

Grade A, and why

df-qa scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 8d ago.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

skills/df-qa/SKILL.md · 38 lines

How it starts

The opening of the file, as written. The whole thing — 38 lines — stays where its author put it; the contents beside it link to each section on GitHub.

Dark Factory — QA (validation rules executed)

Overview

QA deploys the built system, runs the PO's real-life scenarios against it, and returns a Works? verdict backed by unforgeable evidence. Through the lens (df-data-transform-lens), QA executes the validation rules. QA is the observer — it assesses evidence, it does not accept the builder's claim.

When to use

Testing a deployed system, mapping PO Test Scenarios to test cases, capturing per-scenario evidence, or deciding a release verdict.

What QA does

Each PO acceptance criterion is a validation rule → a test.
- LOCAL rules → tests that feed bad input at an edge and assert it is rejected.
- GLOBAL rules → reconciliation tests across systems/time, asserting the invariant and the authority tie-break.
For every effect transform: test idempotency (replay → no double-action) and compensation (failure → clean rollback).
Capture evidence by correlationId — a scenario "passed" only if its run is traceable in observability (metric/log/trace). Observation, not assertion.

The holdout = the anti-Goodhart firewall

QA holds the held-back acceptance suite — the cases the Developer agent never saw. Verifying the build against held-back cases is what proves it implemented the spec, not its own tests. Never hand the holdout to the builder.

Pre-test gate (the eyes must work first)

Before running scenarios, confirm the Observability Surface renders live data and the $correlationId query resolves (see df-observability). Broken eyes block the verdict — evidence capture is impossible without them.

Instructions

Map, don't invent — every test case starts from a PO scenario (one scenario → ≥1 case).
Run the pyramid in order: unit (from Dev) → integration → E2E (JMeter) → the held-back acceptance suite. Stop at the first quality-gate breach.
Capture evidence by correlationId; record failures too (publish bad alongside good).
Verdict: Pass / Conditional / Fail. A "pass" with no observability evidence is not earned. Route a Fail to the owning lane (code → Developer, deploy → Infra, requirement → PO).
In-lane or out-of-lane — decide before the Fail blocks the verdict. A Fail caused by the change under test routes in-lane and must be fixed and re-verified. A Fail that is evidence-proven reachable without the change is a pre-existing defect of the base product: route it out-of-lane to the backlog, with the evidence that proves it pre-existing, rather than letting it hold the verdict hostage. The proof is the price — an unproven "that was already broken" is how a real regression gets waved through.

Read the full file on GitHub · 38 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

8d ago First seen · 38 lines · 119 tokens per session scan A aa4afac17eb7

Subscribe to this mod's changes

df-qa is a skill published in the GitHub repository OneDro1d/dark-factory (0 stars, last pushed today), licensed Apache-2.0. It adds 119 tokens to every session and 810 once invoked, about $0.0006 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-01.

Claude Code Testing agent-skills mcp

research-engineer

An uncompromising Academic Research Engineer. Operates with absolute scientific rigor, objective criticism, and zero flair. Focuses on theoretical correctness, formal verification, and optimal implementation across any required technology.

davila7/claude-code-templates · 43 tokens

tika-eval-compare

Compare extracts from two Tika builds over a corpus to detect regressions in content, encoding, exceptions, and embedded-document handling. Use for "compare before/after extracts", "eval this change against the corpus".

apache/tika · 50 tokens

neuron-evaluation-engineer

Create and run AI evaluations with datasets, assertions, and output drivers in Neuron AI. Use this skill whenever the user mentions evaluation, testing AI systems, creating evaluators, dataset-driven testing, assertion-based validation, or wants to measure AI system performance. Also trigger for tasks involving…

neuron-core/neuron-ai · 77 tokens

df-qa