Menu
Test-driven development — write the test first, watch it fail, write minimal code to pass. Use when implementing features or fixing bugs.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Recognizing context pressure before it degrades output quality.
Writing implementation plans — small testable steps, dependency ordering, upfront risk identification.
Evidence before claims, always — run verification commands and confirm output before making any completion or success claims.
Generate Architecture Decision Records — use when asked to document a decision, create an ADR, record why we chose X, or capture architectural rationale.
Generate a structured changelog from git history — use when asked to create a changelog, release notes, or summarize what changed between versions/tags/branches.
How to write pikit workflow YAML files — steps, loops, branches, interpolation.
| name | tdd |
| description | Test-driven development — write the test first, watch it fail, write minimal code to pass. Use when implementing features or fixing bugs. |
NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
Write code before the test? Delete it. Start over. No exceptions.
Write ONE minimal test showing what should happen.
Requirements:
MANDATORY. Never skip.
Run the test. Confirm:
Test passes? You're testing existing behavior. Fix the test.
Write the SIMPLEST code to pass the test. Nothing more.
Don't add features. Don't refactor. Don't "improve" beyond the test.
MANDATORY.
Run the test. Confirm:
After green only:
Keep tests green. Don't add behavior.
Next failing test for next behavior.
| Excuse | Reality |
|---|---|
| "Too simple to test" | Simple code breaks. Test takes 30 seconds. |
| "I'll test after" | Tests written after pass immediately — proves nothing. |
| "Need to explore first" | Fine. Throw away exploration, start with TDD. |
| "Test is hard to write" | Listen to the test. Hard to test = hard to use. Fix the design. |
| "TDD will slow me down" | TDD is faster than debugging. Every time. |
| "Keep as reference" | You'll adapt it. That's testing-after. Delete means delete. |
Bug: empty email accepted.
RED: test('rejects empty email', () => { expect(validate('')).toBe(false); })
Verify RED: FAIL — expected false, got undefined
GREEN: function validate(email) { return email.trim().length > 0; }
Verify GREEN: PASS
All of these mean: delete code, start over with TDD.