القائمة
Use when implementing any feature or bugfix, before writing implementation code
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | test-driven-development |
| description | Use when implementing any feature or bugfix, before writing implementation code |
Core principle: If you didn't watch the test fail, you don't know if it tests the right thing.
Always: New features, bug fixes, refactoring, behavior changes.
Exceptions (require human permission): Throwaway prototypes, generated code, configuration-only changes.
No production code without a failing test first.
Wrote code before the test? Delete it. Start over. No "reference", no "adapting".
Write one minimal test showing what should happen:
Run the test. Confirm:
Write the simplest code that makes the test pass.
Run the test. Confirm:
Test fails? Fix code, not test. Other tests fail? Fix now.
Only after green:
Keep tests green throughout. 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 passing immediately prove nothing. |
| "Need to explore first" | Fine. Throw away exploration, start with TDD. |
| "Test hard = skip" | Hard to test = hard to use. Listen to the test. |
| "Already manually tested" | Ad-hoc != systematic. No record, can't re-run. |
| Problem | Solution |
|---|---|
| Don't know how to test | Write the assertion first. Design the API you wish existed. |
| Test too complicated | Design too complicated. Simplify the interface. |
| Must mock everything | Code too coupled. Use dependency injection. |
| Test setup huge | Extract helpers. Still complex? Simplify design. |
When introducing mocks or test helpers, watch for: testing mock behavior instead of real behavior, adding test-only methods to production classes, mocking without understanding the dependency.
Before marking work complete:
The skill for "is this AI-written?" or "make this sound more human." Use whenever a specific text sample is in question and the core concern is AI authenticity — student submissions suspected of AI authorship, blog/wiki drafts that feel off, PR commit messages that smell like boilerplate, cover letters that sound robotic, paragraphs an editor flagged. Detects copula avoidance, ChatGPT vocabulary, significance inflation, and 30+ other documented AI tells. Also rewrites flagged sections. Not for grammar checks, summarization, or style edits where AI detection is not the concern.
Chain extract-research-questions into objective-codebase-research. Convenience wrapper for the Q+R phases of QRSPI.
Draft a structured design discussion from research findings. Interactive — presents understanding for corrections before finalizing.
Create a structure outline with vertical slices from a design discussion document. Enforces vertical decomposition over horizontal layers.
Extract 5-10 codebase research questions from a ticket or description. Questions only — no answers or opinions.
Conduct problem-aware, solution-blind codebase research. Outputs factual findings only — no opinions or suggestions.
