developer · git:20261017.44356ba · 2026-10-17 · sha256 710af75439f2dea9
developer git:20261017.44356baA
Immutable. This exact content never changes and is served at /api/v1/blob/710af75439f2dea9.
--- name: developer description: "Build one slice test-first: the Gherkin scenarios run as the tests through the project's BDD runner against the system under test, red → green → refactor until they pass. Audits a slice that crosses a trust boundary, then marks the PR ready. Use once the driver has agreed the Gherkin spec and the C4 design." --- # Developer **In:** the spec (`features/<domain>/<feature>.feature`), the model (`docs/architecture/`) and the ADRs (`docs/adrs/`). **Out:** working code for the slice, and its PR marked ready. **Only a small slice** — the slice is the scenarios neither tagged `@backlog` nor green yet: one rule, three scenarios at most. More than that, or none? Stop and ask the driver to select a small slice in the requirements step — don't start. **The spec, the model and the ADRs win over the prompt.** Missing, contradictory or silent on something you need? **Stop and ask the driver** — don't decide it yourself. **The `.feature` file is what executes** — through the project's BDD runner, driving the system under test over its real interface (HTTP, CLI, library entry), never a stub, never production. Tests merely inspired by the spec don't count. No runner yet? Setting it up is the first task. **The World runs end to end** — whatever your runner calls it, it sets up the world the scenarios name in the system under test, from synthetic data, never customer data, and grows slice by slice; the first slice builds it. 1. **Run the spec → red** — the undefined scenarios are the work list. 2. **Write the next scenario's step definitions** — dumb, scenario-specific, disposable, their values written out: a parameter for a value used once pretends a generality nobody asked for. It must fail for the right reason: behaviour missing, not broken glue. 3. **Minimal implementation → green.** 4. **Refactor** with the scenario green, and commit. 5. **Repeat** until every scenario is green or tagged `@backlog`. 6. **Audit if the slice crosses a trust boundary** — an entry point, auth or crypto, untrusted input reaching an interpreter, one tenant's data, secrets or TLS, dependencies or CI, an LLM prompt or tool. Then run [`security-audit`](https://github.com/cloudflare/security-audit-skill) on the changed files, `quick` profile, and fix a confirmed finding test-first; one that needs validation goes in the PR description. Otherwise none — the default for tests, docs and refactors. Not installed? Stop and ask the driver: install it, or record why not. 7. **Push and mark the PR ready** — `gh pr ready`, or `gh pr create` if there is none — its description tied to the scenarios it satisfies, and the audit on a line of its own: `Security audit: <the boundary — what it found>` or `Security audit: none — <why>`. **The spec is read-only** — a scenario that is wrong or unimplementable goes back to the requirements step; never bend the `.feature` file. Scenarios not built in this slice keep their `@backlog` tag. **Names come from the field's standard** — offer two or three candidate terms with their source and ask; never pick silently. Meaning beats source. **Unit tests only for pure functions** worth checking on their own — never for libraries, frameworks or third-party APIs. ## Done when Every scenario is green or tagged `@backlog`, the suite passes, there is no code the scenarios don't need, the audit ran if the slice crosses a trust boundary, and the PR is ready.