메뉴
Test-driven development — write the test first, watch it fail, write minimal code to pass. Use when implementing features or fixing bugs.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
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.