Create BDD test stubs from acceptance criteria and report PASS or FAIL.
npx skills add https://github.com/robconery/crap-code --skill tester-robconery
Please help me install this Agent Skill. Skill: tester Source: https://github.com/robconery/crap-code/tree/main/.pi/skills/tester Command: npx skills add https://github.com/robconery/crap-code --skill tester-robconery
This Skill prevents fragile releases by ensuring every acceptance criterion gets a corresponding, correctly structured test that either green-lights the task or blocks it without altering production code.
/lib/.vi.mock-style mocks), fixture-based external data, and no E2E calls to real Stripe/Resend/Firebase.Use the tester skill during a development task to turn the task’s acceptance criteria into BDD test stubs, then finish the tests and run the suite so the task is either transitioned to review or recorded as failed for correction.
High-intent search queries and answers about installing and using this skill.
You generate BDD test stubs by mirroring your `/lib/` structure under `/tests/`, ensuring every acceptance criterion has a corresponding stub. This immediately initiates the red→green loop without touching production code.
You gate releases by completing BDD tests for every acceptance criterion per task. Passing tests trigger a `sprint_state_transition` for review, while failures record a `strike_record` to block the release without altering production code.
BDD testing works with in-memory SQLite and test fakes by enforcing reliable isolation. You provide fixture-based external data and avoid `vi.mock`-style mocks or E2E calls to real services like Stripe and Firebase.
The best way to isolate external integrations in BDD tests is using test fakes with fixture-based data. This prevents E2E calls to real Stripe, Resend, or Firebase services and prohibits `vi.mock`-style mocks to ensure reliable isolation.
You should use test fakes instead of `vi.mock` to verify reliable isolation practices and ensure idempotent workflows. Fakes provide fixture-based data for external integrations without fragile E2E calls, keeping production code unmodified.
You need to run BDD test gates during the planning-to-execution workflow of a development sprint. Gating happens per task after completing `/tests/` stubs to ensure every acceptance criterion passes before transitioning the task to review.
pingwuGenerate BDD/Gherkin feature files and TDD test scaffolding before coding.
tmdgusyaVerify implemented plans against codebase and test results.
robconeryRoute sprint tasks through planning, execution, and review gates.
GainInsightDevGenerate Markdown BDD scenarios from requirements with test type classification.