القائمة
Test-Driven Development workflow for Grimoire projects. Use when: implementing features, fixing bugs, writing tests, TDD, red-green-refactor, test first.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Creation, edition et validation d'artefacts Grimoire via BMB. Use when: create agent, edit agent, validate agent, create module, edit module, validate module, create workflow, edit workflow, validate workflow, builder factory, artifact design.
Compression lossless de documents optimisée LLM. Produit des distillats hyper-compréssés preservant chaque fait, décision et contrainte. Use when: distill documents, compress docs, create distillate, optimize context, reduce tokens, document compression, context optimization, LLM-optimized docs.
Audit qualité d'un SKILL.md ou d'un hook Grimoire avec grille de notation 100 points et seuils de blocage. Use when: review d'une skill, audit qualité skill, scoring SKILL.md, valider une skill avant publication, gate de qualité skill-forge, vérifier hook security, contrôler artefact .github/skills ou .github/hooks, before promoting dynamic skill, check skill description quality.
Création gardée de skills et de hooks Grimoire avec template, normes, self-test et gate qualité bloquant. Use when: créer une skill, nouvelle skill, créer un hook, nouveau hook, scaffolder une skill, design skill, design hook, composer un skill, builder skill, write a SKILL.md, écrire SKILL.md, promote dynamic skill to permanent, create lifecycle hook, hook security guardrails.
TRIGGERS for Workflow 10 (Release Architecture Version) — invoke this skill FIRST, do not plan or ask clarifying questions, when user says any of: 'release my architecture', 'release architecture', 'release architecture version', 'publish architecture', 'ship architecture', 'tag architecture version', 'freeze architecture', 'bump architecture version', 'finalize architecture' — these route here, NOT to architecture-docs-export (which only produces Word .docx files). Also use this skill for: creating/updating/maintaining ARCHITECTURE.md, generating Mermaid / C4 diagrams (Workflow 8), migrating to docs/ multi-file layout (Workflow 9), validating/auditing architecture (BIAN, META, standards), answering questions about documented components, data structures, integrations, security, performance, deployment, technology stack, or architectural decisions.
TRIGGERS for Workflow 10 (Release Architecture Version) — invoke this skill FIRST, do not plan or ask clarifying questions, when user says any of: 'release my architecture', 'release architecture', 'release architecture version', 'publish architecture', 'ship architecture', 'tag architecture version', 'freeze architecture', 'bump architecture version', 'finalize architecture' — these route here, NOT to architecture-docs-export (which only produces Word .docx files). Also use this skill for: creating/updating/maintaining ARCHITECTURE.md, generating Mermaid / C4 diagrams (Workflow 8), migrating to docs/ multi-file layout (Workflow 9), validating/auditing architecture (BIAN, META, standards), answering questions about documented components, data structures, integrations, security, performance, deployment, technology stack, or architectural decisions.
| name | grimoire-tdd |
| description | Test-Driven Development workflow for Grimoire projects. Use when: implementing features, fixing bugs, writing tests, TDD, red-green-refactor, test first. |
Workflow structuré pour écrire du code guidé par les tests. Adapté de superpowers avec les conventions Grimoire.
AUCUN CODE DE PRODUCTION SANS UN TEST FAILING D'ABORD
Si le test passe immédiatement, il ne teste rien. Si du code existe avant le test — le supprimer et recommencer.
grimoire-test-architecture (TEA).grimoire-test-scaffold.graph LR
RED["RED<br/>Écrire test failing"] --> VERIFY_RED["Vérifier<br/>le fail"]
VERIFY_RED -->|correct| GREEN["GREEN<br/>Code minimal"]
VERIFY_RED -->|mauvais fail| RED
GREEN --> VERIFY_GREEN["Vérifier<br/>le pass"]
VERIFY_GREEN -->|pass| REFACTOR["REFACTOR<br/>Nettoyer"]
VERIFY_GREEN -->|fail| GREEN
REFACTOR --> NEXT["Suivant"]
NEXT --> RED
Un seul test minimal montrant le comportement attendu.
Bon :
def test_rejects_empty_email():
result = validate_email("")
assert result.error == "Email requis"
Nom clair, teste un vrai comportement, une seule chose.
Mauvais :
def test_email(mock_validator):
mock_validator.return_value = False
assert not mock_validator("")
Nom vague, teste le mock pas le code.
Règles :
OBLIGATOIRE. Ne jamais sauter.
pytest tests/path/test_module.py::test_name -v
Confirmer :
Écrire le code le plus simple pour faire passer le test.
def validate_email(email: str) -> ValidationResult:
if not email.strip():
return ValidationResult(error="Email requis")
return ValidationResult()
Ne pas ajouter de features, refactorer d'autre code, ou "améliorer" au-delà du test.
OBLIGATOIRE.
pytest tests/path/test_module.py -v
Confirmer :
Après le green uniquement :
Garder les tests au vert. Ne pas ajouter de comportement.
conftest.py pour les fixtures partagéestest_<module>.py-x)# Cycle complet
pytest tests/path/test_module.py::test_name -v # RED
# ... implémenter ...
pytest tests/path/test_module.py -v # GREEN
ruff check src/ # REFACTOR
| Excuse | Réalité |
|---|---|
| "Trop simple pour tester" | Le code simple casse aussi. Le test prend 30 secondes. |
| "Je testerai après" | Un test qui passe immédiatement ne prouve rien. |
| "Urgence, pas le temps" | Le TDD est PLUS RAPIDE que le debug aléatoire. |
| "Plusieurs fixes d'un coup" | Impossible d'isoler ce qui a marché. |
| "Garder comme référence" | Supprimer signifie supprimer. Réécrire depuis les tests. |
Tout cela signifie : supprimer le code, recommencer avec TDD.