القائمة
Phase d'architecture systématique AVANT le code (TDD). Use when starting a new feature that touches multiple files, designing a new module, or making non-trivial architectural choices.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Docker & Hadolint validation (2026). Use when working with Docker, containers, or validating Dockerfiles.
Security guidelines and OWASP Top 10. Use when reviewing security, implementing authentication or authorization, hardening code, or discussing vulnerabilities.
Third-party Claude Code token/context/code-review tools. Use when choosing or recommending an external tool to reduce token usage, manage context, or review large codebases (caveman, code-review-graph, token-savior, context-mode...).
Third-party Claude Code token/context/code-review tools. Use when choosing or recommending an external tool to reduce token usage, manage context, or review large codebases.
Testing Flutter 3.44 / BLoC v9 / Riverpod 3 - Stratégie Complète. Use when writing tests, reviewing test coverage, or setting up testing.
Testing React Native 0.85+. Use when writing tests, reviewing test coverage, or setting up testing.
| name | architect |
| description | Phase d'architecture systématique AVANT le code (TDD). Use when starting a new feature that touches multiple files, designing a new module, or making non-trivial architectural choices. |
| context | fork |
| disable-model-invocation | true |
| triggers | {"keywords":["architect","design","new feature","structure","boundaries","dependencies","module design"]} |
| auto_suggest | true |
Skill inspiré de obra/superpowers. Objectif : produire une spec d'architecture avant d'écrire le moindre test ou ligne de code.
Règle d'or : si tu ne peux pas dessiner le diagramme, tu ne peux pas coder la feature.
| Situation | Architect phase ? |
|---|---|
| Bug 1 fichier | ❌ Non (go direct TDD) |
| Nouvelle feature < 3 fichiers | ⚠️ Court (10 min) |
| Nouvelle feature > 3 fichiers | ✅ Obligatoire |
| Nouveau module/bounded context | ✅ Obligatoire |
| Migration technique | ✅ Obligatoire |
| Intégration externe (API, MQ, DB) | ✅ Obligatoire |
Quelles frontières la feature touche-t-elle ?
Output : liste des frontières traversées.
Pour chaque frontière traversée, définir le contrat :
Output : signatures de fonctions/endpoints + DTO.
Qui dépend de quoi ? Dans quel sens ?
[HTTP Controller] ──▶ [Use Case] ──▶ [Domain Service]
│
▼
[Repository] (interface)
│
▼
[Postgres Adapter] ─implements─▶
Vérifier :
Output : diagramme (Mermaid, ASCII, ou texte structuré).
Pour chaque décision non évidente, documenter pourquoi ce choix :
| Décision | Alternative envisagée | Pourquoi ce choix |
|---|---|---|
| Async via queue | Sync HTTP | Latence >500ms, pas critique immédiat |
| CQRS | CRUD simple | Ratio 20:1 lecture/écriture |
| Event sourcing | Store état | Besoin audit légal |
Output : ADR léger (3-5 bullets) — voir .claude/rules/10-documentation.md pour ADR formel si décision majeure.
Avant TDD sur le comportement, définir les tests d'architecture :
Output : liste de tests d'architecture à écrire en Phase TDD.
À la fin de la phase Architect, produire :
atomic-tasks)Ce n'est qu'après qu'on rentre dans le TDD (Red/Green/Refactor).
| Anti-pattern | Solution |
|---|---|
| Coder directement sans diagramme | Dessiner AVANT, même 5 min suffisent |
| Architect phase > 2h sur feature simple | YAGNI — couper court |
| Contrats flous ("objet User") | Types stricts, tous les champs |
| Ignorer les trade-offs | ADR court obligatoire |
| Architecture en vase clos | Review par un pair ou subagent @tech-lead |
/workflow:design — utilise ce skill par défaut@tech-lead — peut produire l'output Architect/common:architecture-decision.claude/rules/04-solid-principles.md.claude/rules/10-documentation.md (ADR)atomic-tasksDate de dernière mise à jour : 2026-04-15 Version : 1.0.0