القائمة
Use when implementing any feature or bugfix, before writing implementation code
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use before any creative work — creating features, building components, adding functionality, or modifying behavior. Explores intent, requirements, and design before implementation.
Use when completing tasks, implementing major features, or before merging. Covers both performing self-review and responding to external review feedback.
Use when starting feature work needing isolation or when completing a development branch — covers worktree creation, setup, and branch finishing.
Use at the start of every conversation to establish skill-driven workflows. Ensures relevant skills are loaded before any action or response.
Use when you have a spec or requirements for a multi-step task. Covers both writing implementation plans and executing them task-by-task with review checkpoints.
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
| name | test-driven-development |
| description | Use when implementing any feature or bugfix, before writing implementation code |
NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
Write code before the test? Delete it. Start over.
No exceptions:
Violating the letter of the rules is violating the spirit of the rules.
Always: New features, bug fixes, refactoring, behavior changes.
Exceptions (ask your human partner): Throwaway prototypes, generated code, config files.
Write one minimal test showing what should happen.
Requirements:
MANDATORY. Never skip.
# Run the specific test
<test command> path/to/test
Confirm:
Test passes? You're testing existing behavior. Fix the test.
Write simplest code to pass the test.
Don't add features, refactor other code, or "improve" beyond the test.
MANDATORY.
Confirm:
Test fails? Fix code, not test.
After green only:
Keep tests green. Don't add behavior.
Next failing test for next behavior.
| Quality | Good | Bad |
|---|---|---|
| Minimal | One thing. "and" in name? Split it. | Tests multiple behaviors |
| Clear | Name describes behavior | test('test1') |
| Real | Tests actual code | Tests mock behavior |
| Excuse | Reality |
|---|---|
| "Too simple to test" | Simple code breaks. Test takes 30 seconds. |
| "I'll test after" | Tests passing immediately prove nothing. |
| "Need to explore first" | Fine. Throw away exploration. Start with TDD. |
| "Test hard = skip it" | Hard to test = hard to use. Fix the design. |
| "TDD will slow me down" | TDD is faster than debugging. |
| "Already manually tested" | Ad-hoc ≠ systematic. No record, can't re-run. |
| "Deleting X hours is wasteful" | Sunk cost fallacy. Keeping unverified code is debt. |
Never fix bugs without a test.
Before marking work complete:
Can't check all boxes? You skipped TDD. Start over.