Menü
Scannable BDD tests written in domain language. Use when doing BDD.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
| name | bdd-with-approvals |
| description | Scannable BDD tests written in domain language. Use when doing BDD. |
Specifications live in documents. They drift from reality because nothing enforces them.
Tests verify implementation. Written after code, they document what IS, not what SHOULD BE. They're noisy. You can't glance at them and quickly validate correctness.
You need an artifact that:
The fixture file IS that artifact. Write it BEFORE implementation.
Think through scenarios by creating approval files. Describe expected behavior in domain language. Implementation is driven by making these specs pass. Specs stay executable, never go stale.
A human looks at the fixture and immediately sees: correct or not. No translation between "spec" and "test". They're the same artifact.
For the approval testing technique itself (verify, scrubbers, combinations), see /approval-tests. For nulled infrastructure in system tests, see /nullables.
Test files combining input and expected output in a format designed for human validation.
## Input
(context, parameters, initial state)
## Output
(expected results, side effects, final state)
Test runner reads fixtures, executes code, compares output. Adding test cases = adding files, not code.
Design the format for YOUR domain:
See references/approved-fixtures.md for examples.
The question: Can someone validate correctness in <5 seconds?
Design for human eyes, not machine parsing. Match the domain's natural representation. How you'd explain it on a whiteboard.
What makes formats scannable:
Avoid:
One-time per domain:
Keep parser/formatter simple. Format should be close to natural representation.
Turn production logs into tests by copying and fixing incorrect lines. Quick bug reproduction.
Caveat: Logs are for runtime observability, not test validation. Tying tests to log format creates coupling. Log changes break tests. Use sparingly when logs happen to capture the behavior well.
Nullables — testing technique alternative to using mocking libraries. Use when writing unit tests, when code touches external I/O or state (HTTP, databases, files, clock, random) anywhere in its dependency chain, when making a system testable, or when tests are slow or flaky.
Bash script style guide. Always use when writing bash scripts, shell scripts, or CLI bash tools.
Drive a browser from the terminal with playwright-cli: snapshot the page, then act on elements by ref. Use when automating browser interactions, filling web forms, testing UIs, or driving logged-in web apps from the command line.
Facilitates deep, structured learning of a topic — gathering source material, assessing the learner's gaps, then teaching through guided Socratic sessions. Use when someone wants to genuinely study or be tutored on a subject over time, not get a quick answer.
Creates C4 architecture diagrams for designing, documenting, or understanding software architecture. Use when working through system design, mapping existing codebases, or visualizing structure at any level from system landscape down to code.
Test-driven development (TDD) process used when writing code. Use whenever you are adding any new code, unless the user explicitly asks to skip TDD or the code is exploratory/spike.