القائمة
Use when implementing features or bugfixes where a failing test first is the strongest and most practical way to prove behavior before implementation code
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Generate or edit raster images when the task benefits from AI-created bitmap visuals such as photos, illustrations, textures, sprites, mockups, or transparent-background cutouts. Use when Codex should create a brand-new image, transform an existing image, or derive visual variants from references, and the output should be a bitmap asset rather than repo-native code or vector. Do not use when the task is better handled by editing existing SVG/vector/code-native assets, extending an established icon or logo system, or building the visual directly in HTML/CSS/canvas.
Use when the user asks how to build with OpenAI products or APIs and needs up-to-date official documentation with citations, help choosing the latest model for a use case, or model upgrade and prompt-upgrade guidance; prioritize OpenAI docs MCP tools, use bundled references only as helper context, and restrict any fallback browsing to official OpenAI domains.
Compress natural language memory files (CLAUDE.md, todos, preferences) into caveman format to save input tokens. Preserves all technical substance, code, URLs, and structure. Compressed version overwrites the original file. Human-readable backup saved as FILE.original.md. Trigger: /caveman:compress <filepath> or "compress memory file"
Use for library, framework, SDK, API, or CLI questions that need current documentation or version-specific behavior.
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
Simplifies and refines code for clarity, consistency, and maintainability while preserving all functionality. Use when asked to simplify code, clean up code, refactor for clarity, improve readability, or review recently modified code for elegance. Focuses on project-specific best practices.
| name | test-driven-development |
| description | Use when implementing features or bugfixes where a failing test first is the strongest and most practical way to prove behavior before implementation code |
Write the test first. Watch it fail. Write minimal code to pass.
Core principle: If you didn't watch the test fail, you don't know if it tests the right thing.
TDD is strongly preferred for:
TDD is optional, with explicit justification, for:
WHEN TDD IS THE BEST AVAILABLE PROOF, DO NOT WRITE PRODUCTION CODE BEFORE A FAILING TEST
If you skip TDD where it clearly should have been used, treat that as a process failure and correct it.
Write one minimal test showing what should happen.
MANDATORY. Never skip.
Confirm:
Write simplest code to pass the test.
Don't add extra features or refactor beyond what the test needs.
MANDATORY.
Confirm:
After green only:
Keep tests green. Don't add behavior.
| Excuse | Reality |
|---|---|
| "I'll test after" | Tests passing immediately prove nothing |
| "Already manually tested" | Ad-hoc ≠ systematic |
| "Too simple to test" | Simple code breaks too |
| "Need to explore first" | Fine. Throw away exploration, then start with TDD |
| "Any change must use TDD" | Use TDD strongly, but choose the best verification method for the actual risk |
When these appear in a context where TDD is clearly appropriate, stop and start over with TDD.
If the change is genuinely low-risk and another verification method is better, explicitly state that choice and use the stronger evidence path instead of cargo-cult TDD.
Before marking work complete:
Use TDD when it is the best tool for proving behavior and preventing regression.
If another verification path is stronger for the actual risk, choose it deliberately and explain why.