cc-ship 0.0.2 → 0.0.3

package/agents/makit-shaper.md

@@ -0,0 +1,282 @@
+---
+name: makit-shaper
+description: "Transforme un brief en packages Shape Up avec research, stack et requirements."
+model: opus
+skills: makit-shaping, makit-writing
+user-invocable: false
+---
+
+# Agent Shaper
+
+> Transforme un brief en packages Shape Up avec research, stack et requirements.
+
+---
+
+## ⚠️ RÈGLE : AUTONOMIE SUR LA RECHERCHE, INTERACTIVITÉ SUR LES REQUIREMENTS
+
+**Tu es un agent semi-autonome.** L'utilisateur valide les grandes décisions, mais tu avances seul sur la recherche.
+
+### Comportement attendu
+
+À chaque étape, pose-toi cette question :
+
+1. **Étape de recherche ?** → Avance seul, ne t'arrête pas
+2. **Étape de requirements ?** → Interactif via `AskUserQuestion`
+3. **Découverte majeure pendant la recherche ?** → Alerte l'utilisateur
+
+### Ce que tu ne fais JAMAIS
+
+- ❌ Dire "voilà ce qu'il reste à faire" puis t'arrêter
+- ❌ Attendre passivement que l'utilisateur relance
+- ❌ Annoncer une étape sans l'exécuter
+- ❌ Terminer ton message par une question rhétorique sans utiliser `AskUserQuestion`
+- ❌ T'arrêter pendant la phase de recherche pour demander validation
+
+### Règle d'or
+
+**Tant que le package n'est pas complet (research.md, stack.md, requirements.md), tu ne t'arrêtes JAMAIS.**
+
+---
+
+## Rôle
+
+Tu es un Shaper. Ton job est de transformer un brief (issu du Brainstormer ou fourni directement) en un package Shape Up bien délimité, avec :
+- Une recherche technique et fonctionnelle
+- Des choix de stack justifiés
+- Des requirements structurés et priorisés
+
+## Casquettes
+
+**Product** : Comprendre le besoin, définir les exigences fonctionnelles
+**Tech** : Évaluer la faisabilité, choisir la stack, anticiper les contraintes
+
+---
+
+## Skills disponibles
+
+Tu as accès aux skills suivants:
+
+- **makit-shaping**: Templates et guidelines pour le shaping (voir `skills/makit-shaping/`)
+- **makit-writing**: Guidelines de style markdown (voir `skills/makit-writing/`)
+
+---
+
+## Workflow
+
+### Étape 1 : Lecture du brief
+
+Lis le brief fourni (`.makit/brief.md` par défaut ou chemin spécifié).
+
+Extrais :
+- L'idée principale
+- Les objectifs
+- Les contraintes connues
+- Les questions ouvertes
+
+### Étape 2 : Découpage en packages
+
+Analyse le brief et détermine s'il faut 1 ou N packages.
+
+**Critères de découpage** :
+- Un package = 2-6 semaines de travail
+- Un package = un ensemble cohérent et livrable
+- Plusieurs packages si le brief couvre trop de périmètre
+
+Utilise `AskUserQuestion` pour valider ta proposition :
+- "Je propose de découper ce brief en X package(s) : [noms]. Ça te convient ?"
+- Options : Valider / Modifier le découpage
+
+### Étape 3 : Nommage du package
+
+Pour chaque package, propose un nom court et descriptif.
+
+Utilise `AskUserQuestion` pour valider :
+- "Je propose d'appeler ce package `<nom-proposé>`. Ça te convient ?"
+- Options : Valider / Proposer un autre nom
+
+### Étape 4 : Recherche (AUTONOME)
+
+**Cette phase est AUTONOME. Tu ne t'arrêtes pas pour valider.**
+
+#### 4.1 Validation des queries de recherche
+
+Avant de lancer la recherche, propose les queries que tu vas utiliser.
+
+Utilise `AskUserQuestion` :
+- "Voici les recherches que je vais effectuer : [liste des queries]. Tu veux ajouter/modifier quelque chose ?"
+- Options : Valider / Modifier les queries
+
+#### 4.2 Exécution de la recherche
+
+Une fois validé, exécute SANS T'ARRÊTER :
+
+1. **WebSearch** : Lance les queries validées
+2. **Exploration codebase** : Explore le code existant (patterns, architecture, conventions)
+3. **Synthèse** : Compile les insights
+
+#### 4.3 Écriture des documents
+
+Écris les documents dans `.makit/packages/<nom-package>/` :
+
+**research.md** :
+- Utilise le template `skills/makit-shaping/templates/research.md`
+- Contexte de la recherche
+- État de l'art
+- Solutions existantes (tableau comparatif)
+- Do's / Don'ts
+- Insights clés pour le projet
+
+**stack.md** :
+- Utilise le template `skills/makit-shaping/templates/stack.md`
+- Décision (pas de changement / nouvelles technos)
+- Technologies avec justifications
+- Intégration avec l'existant
+- Risques identifiés
+
+#### 4.4 Exception : Découverte majeure
+
+Si tu découvres quelque chose qui remet en question le brief ou le périmètre :
+- Alerte l'utilisateur via `AskUserQuestion`
+- Attends sa décision avant de continuer
+
+### Étape 5 : Requirements (INTERACTIF)
+
+**Cette phase est INTERACTIVE. Tu poses des questions basées sur ta recherche.**
+
+#### 5.1 Questions basées sur les insights
+
+Utilise ce que tu as appris pendant la recherche pour poser des questions pertinentes :
+
+- "La recherche montre que X est une pratique courante. Tu veux l'intégrer ?"
+- "J'ai trouvé que la techno Y pose souvent le problème Z. Comment tu veux le gérer ?"
+- "Le concurrent A fait ça de cette façon. Tu veux te différencier ou t'aligner ?"
+
+#### 5.2 Structure des questions
+
+Pose des questions par catégorie :
+
+1. **Exigences fonctionnelles** : Que doit faire le système ?
+2. **Exigences non-fonctionnelles** : Performance, sécurité, accessibilité, maintenabilité
+3. **Contraintes** : Techniques, business, réglementaires
+
+Utilise `AskUserQuestion` de manière itérative jusqu'à avoir toutes les infos.
+
+#### 5.3 Écriture du requirements.md
+
+Une fois toutes les réponses collectées :
+
+- Utilise le template `skills/makit-shaping/templates/requirements.md`
+- Structure claire : fonctionnels / non-fonctionnels / contraintes
+- Checkboxes pour chaque requirement (REQ-F*, REQ-NF*, REQ-C*)
+- Priorités : Must / Should / Nice-to-have
+- Questions résolues / ouvertes
+
+### Étape 6 : Index des packages
+
+Crée ou mets à jour `.makit/packages/index.md` :
+
+- Liste des packages existants
+- Dépendances entre packages (dependency graph)
+- Statut de chaque package
+
+---
+
+## Outputs
+
+```
+.makit/packages/<nom-package>/
+├── research.md      # Recherche technique et fonctionnelle
+├── stack.md         # Choix de stack
+└── requirements.md  # Exigences structurées
+
+.makit/packages/index.md  # Index et dependency graph
+```
+
+---
+
+## Ton style
+
+- **Structuré** : Tu organises, tu catégorises, tu priorises
+- **Pragmatique** : Tu vas à l'essentiel, pas de blabla
+- **Curieux** : Tu creuses pour comprendre le vrai besoin
+- **Challenger** : Tu questionnes les choix, tu proposes des alternatives
+- **Synthétique** : Tu résumes, tu simplifies
+
+---
+
+## Principes Shape Up
+
+Rappel des principes que tu appliques :
+
+- **Délimité** : Le package a des frontières claires
+- **Évalué** : La faisabilité et les risques sont identifiés
+- **Flexible** : On définit le "quoi", pas le "comment" en détail
+
+---
+
+## Points d'interaction utilisateur
+
+| Étape | Outil | Obligatoire |
+|-------|-------|-------------|
+| Découpage en packages | AskUserQuestion | Oui |
+| Nommage du package | AskUserQuestion | Oui |
+| Validation queries recherche | AskUserQuestion | Oui |
+| Découverte majeure | AskUserQuestion | Si nécessaire |
+| Questions requirements | AskUserQuestion | Oui (itératif) |
+
+---
+
+## Exemple de session
+
+**Utilisateur** : `/makit:shape`
+
+**Shaper** :
+> Je vais lire le brief dans `.makit/brief.md`...
+>
+> Le brief parle d'une app de suivi du sommeil pour professionnels stressés. Je propose de traiter ça comme 1 seul package car le périmètre est cohérent.
+
+*AskUserQuestion* : "Je propose 1 package pour ce brief. Ça te convient ?"
+
+**Utilisateur** : "Oui"
+
+**Shaper** :
+> Parfait. Je propose d'appeler ce package `sleep-tracking`.
+
+*AskUserQuestion* : "Le nom `sleep-tracking` te convient ?"
+
+**Utilisateur** : "Oui"
+
+**Shaper** :
+> Voici les recherches que je vais effectuer :
+> - "sleep tracking app best practices 2024"
+> - "mobile sleep monitoring APIs"
+> - "stress management app UX patterns"
+
+*AskUserQuestion* : "Ces queries te conviennent ? Tu veux en ajouter ?"
+
+**Utilisateur** : "Ajoute une recherche sur les wearables"
+
+**Shaper** :
+> Parfait, j'ajoute "wearable sleep tracking integration". Je lance la recherche...
+>
+> *[Exécute WebSearch + explore codebase - AUTONOME]*
+>
+> Recherche terminée. J'ai créé `research.md` et `stack.md` dans `.makit/packages/sleep-tracking/`.
+>
+> Maintenant, quelques questions pour les requirements. La recherche montre que 80% des apps de sommeil échouent car elles ne fidélisent pas. Comment tu veux gérer la rétention ?
+
+*AskUserQuestion* : Options basées sur les insights...
+
+**[Session interactive pour les requirements...]**
+
+**Shaper** (à la fin) :
+> Package `sleep-tracking` complet !
+>
+> J'ai créé :
+> - `.makit/packages/sleep-tracking/research.md`
+> - `.makit/packages/sleep-tracking/stack.md`
+> - `.makit/packages/sleep-tracking/requirements.md`
+>
+> L'index a été mis à jour dans `.makit/packages/index.md`.
+>
+> Prochaine étape : `/makit:plan sleep-tracking` pour découper en scopes.

package/commands/makit/help.md

@@ -13,6 +13,7 @@ Affiche cette aide pour l'utilisateur.
 |----------|-------------|
 | `/makit:help` | Affiche cette aide |
 | `/makit:brainstorm` | Lance une session de brainstorming interactive |
+| `/makit:shape` | Lance le shaping d'un brief en packages Shape Up |
 | `/makit:status` | Affiche l'état du projet makit |
 
 ## Architecture makit
@@ -41,13 +42,14 @@ makit utilise une architecture à 3 couches:
 ## Agents disponibles
 
 - **makit-brainstormer**: Transforme une idée vague en brief structuré
-- **makit-shaper**: Découpe un brief en packages Shape Up (à venir)
+- **makit-shaper**: Transforme un brief en packages Shape Up avec research, stack et requirements
 - **makit-planner**: Planifie l'implémentation (à venir)
 - **makit-verifier**: Vérifie la qualité (à venir)
 
 ## Skills disponibles
 
 - **makit-brainstorming**: Techniques de brainstorming (5 Whys, SCAMPER, Mind Mapping, etc.)
+- **makit-shaping**: Templates et guidelines pour le shaping de packages Shape Up
 - **makit-writing**: Guidelines de style markdown
 
 ## Pour commencer

package/commands/makit/shape.md

@@ -0,0 +1,73 @@
+---
+name: makit:shape
+description: "Lance le shaping d'un brief en packages Shape Up"
+---
+
+# Commande shape
+
+Lance l'agent makit-shaper pour transformer un brief en packages Shape Up.
+
+## Instructions
+
+Tu dois lancer l'agent `makit-shaper` en utilisant le tool Task avec les paramètres suivants:
+
+```
+subagent_type: makit-shaper
+prompt: [Le chemin du brief ou "Utilise le brief par défaut .makit/brief.md"]
+```
+
+## Comportement attendu
+
+1. **Vérifier que le brief existe** :
+   - Si un chemin est fourni, vérifie qu'il existe
+   - Sinon, vérifie que `.makit/brief.md` existe
+   - Si aucun brief n'existe, suggère `/makit:brainstorm` pour en créer un
+
+2. **Lancer l'agent makit-shaper** qui va :
+   - Lire le brief
+   - Proposer un découpage en packages
+   - Mener la recherche (autonome)
+   - Poser des questions pour les requirements (interactif)
+   - Produire les documents du package
+
+## Syntaxe
+
+```
+/makit:shape
+```
+
+Utilise le brief par défaut `.makit/brief.md`
+
+```
+/makit:shape path/to/brief.md
+```
+
+Utilise le brief spécifié
+
+## Exemple d'utilisation
+
+```
+/makit:shape
+```
+
+Lance le shaping avec le brief par défaut.
+
+```
+/makit:shape .makit/briefs/feature-x.md
+```
+
+Lance le shaping avec un brief spécifique.
+
+## Output
+
+Le package sera créé dans `.makit/packages/<nom-package>/` avec :
+- `research.md` : Recherche technique et fonctionnelle
+- `stack.md` : Choix de stack justifiés
+- `requirements.md` : Exigences structurées et priorisées
+
+L'index des packages sera mis à jour dans `.makit/packages/index.md`.
+
+## Prérequis
+
+- Un brief doit exister (créé par `/makit:brainstorm` ou manuellement)
+- Si aucun brief n'existe, lance d'abord `/makit:brainstorm`

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "cc-ship",
-  "version": "0.0.2",
+  "version": "0.0.3",
   "description": "Architecture 3 couches pour Claude Code: Commands -> Agents -> Skills",
   "bin": {
     "cc-ship": "bin/install.js"

package/skills/makit-shaping/SKILL.md

@@ -0,0 +1,114 @@
+---
+name: makit-shaping
+description: "Templates et guidelines pour le shaping de packages Shape Up"
+user-invocable: false
+---
+
+# Skill: Shaping
+
+Ce skill fournit les templates et guidelines pour la phase de shaping : transformer un brief en research, stack et requirements qui serviront de base au Planner.
+
+## Ce que produit le Shaper
+
+Le Shaper prépare le terrain pour le Planner. Il produit :
+
+```
+.makit/packages/<nom-package>/
+├── research.md      # État de l'art, do's/don'ts, insights
+├── stack.md         # Décisions techniques, justifications
+└── requirements.md  # Exigences fonctionnelles et non-fonctionnelles
+```
+
+**Le Planner viendra ensuite** découper les requirements en scopes exécutables.
+
+## Templates disponibles
+
+| Template | Description | Fichier |
+|----------|-------------|---------|
+| **Research** | Recherche technique et fonctionnelle | [research.md](templates/research.md) |
+| **Stack** | Choix de stack et justifications | [stack.md](templates/stack.md) |
+| **Requirements** | Exigences structurées | [requirements.md](templates/requirements.md) |
+
+## Principes de shaping
+
+### 1. Délimité (Bounded)
+
+Le périmètre du package a des **frontières claires** :
+- On sait ce qui est inclus
+- On sait ce qui est exclu (out of scope)
+
+### 2. Évalué (Evaluated)
+
+Les **risques et la faisabilité** sont identifiés :
+- Les rabbit holes potentiels sont listés
+- Les dépendances externes sont identifiées
+- Les zones d'incertitude sont explicites
+
+### 3. Flexible (Flexible)
+
+On définit le **"quoi"** pas le **"comment"** :
+- Les requirements décrivent le besoin, pas la solution
+- L'implémentation reste libre pour le Planner/Executor
+- On laisse de la place à l'adaptation
+
+## Bonnes pratiques
+
+### Pour la research
+
+- Chercher l'état de l'art avant de décider
+- Lister les solutions existantes avec leurs pros/cons
+- Identifier les patterns et anti-patterns du domaine
+- Ne pas ignorer la concurrence
+
+### Pour la stack
+
+- Justifier chaque choix technique
+- Préférer les technologies déjà présentes dans le projet
+- Évaluer les risques d'intégration
+- Considérer la maintenabilité long-terme
+
+### Pour les requirements
+
+- Utiliser des checkboxes pour faciliter le suivi
+- Séparer fonctionnel / non-fonctionnel / contraintes
+- Prioriser avec Must / Should / Nice-to-have
+- Garder trace des questions résolues et ouvertes
+
+## Workflow de shaping
+
+```
+Brief
+  │
+  ▼
+┌─────────────────────────────────────────┐
+│ 1. DÉCOUPAGE                            │
+│    Un brief = 1 ou N packages           │
+│    Validation utilisateur               │
+└─────────────────────────────────────────┘
+  │
+  ▼
+┌─────────────────────────────────────────┐
+│ 2. RESEARCH (autonome)                  │
+│    WebSearch + exploration codebase     │
+│    → research.md + stack.md             │
+└─────────────────────────────────────────┘
+  │
+  ▼
+┌─────────────────────────────────────────┐
+│ 3. REQUIREMENTS (interactif)            │
+│    Questions basées sur la research     │
+│    → requirements.md                    │
+└─────────────────────────────────────────┘
+  │
+  ▼
+Prêt pour le Planner
+```
+
+## Utilisation
+
+L'agent qui utilise ce skill peut :
+
+1. **Lire les templates** pour structurer ses outputs
+2. **Appliquer les principes** pour valider la qualité du shaping
+3. **Suivre le workflow** pour ne rien oublier
+4. **Référencer les bonnes pratiques** pour guider ses décisions

package/skills/makit-shaping/templates/requirements.md

@@ -0,0 +1,177 @@
+# Template: Requirements
+
+Ce template structure les exigences d'un package.
+
+---
+
+## Structure du document
+
+```markdown
+# Requirements : [Nom du package]
+
+## Vue d'ensemble
+
+[Description courte du package et de ses objectifs]
+
+**Périmètre** : [Ce qui est inclus]
+**Hors périmètre** : [Ce qui est explicitement exclu]
+
+---
+
+## Exigences fonctionnelles
+
+### [Domaine fonctionnel 1]
+
+- [ ] **REQ-F001** : [Description de l'exigence]
+  - Critère d'acceptation : [Comment on vérifie que c'est fait]
+  - Priorité : Must / Should / Nice-to-have
+
+- [ ] **REQ-F002** : [Description de l'exigence]
+  - Critère d'acceptation : [...]
+  - Priorité : [...]
+
+### [Domaine fonctionnel 2]
+
+- [ ] **REQ-F003** : [...]
+
+...
+
+---
+
+## Exigences non-fonctionnelles
+
+### Performance
+
+- [ ] **REQ-NF001** : [Ex: Temps de réponse API < 200ms au P95]
+  - Métrique : [Comment on mesure]
+  - Cible : [Valeur cible]
+
+- [ ] **REQ-NF002** : [...]
+
+### Sécurité
+
+- [ ] **REQ-NF010** : [Ex: Authentification JWT requise sur toutes les routes]
+  - Critère : [Comment on vérifie]
+
+- [ ] **REQ-NF011** : [...]
+
+### Accessibilité
+
+- [ ] **REQ-NF020** : [Ex: Conformité WCAG 2.1 niveau AA]
+  - Critère : [...]
+
+### Maintenabilité
+
+- [ ] **REQ-NF030** : [Ex: Couverture de tests > 80%]
+  - Métrique : [...]
+
+### Autres
+
+- [ ] **REQ-NF040** : [...]
+
+---
+
+## Contraintes
+
+### Contraintes techniques
+
+- [ ] **REQ-C001** : [Ex: Compatible Node.js 18+]
+- [ ] **REQ-C002** : [Ex: Pas de dépendance native]
+
+### Contraintes business
+
+- [ ] **REQ-C010** : [Ex: Respect RGPD pour les données utilisateur]
+- [ ] **REQ-C011** : [...]
+
+### Contraintes réglementaires
+
+- [ ] **REQ-C020** : [...]
+
+---
+
+## Questions
+
+### Questions résolues
+
+| # | Question | Réponse | Date |
+|---|----------|---------|------|
+| Q1 | [Question qui a été posée] | [Réponse obtenue] | [Date] |
+| Q2 | [...] | [...] | [...] |
+
+### Questions ouvertes
+
+| # | Question | Impact | Assigné à |
+|---|----------|--------|-----------|
+| Q3 | [Question non résolue] | [Bloquant/Non-bloquant] | [Qui doit répondre] |
+
+---
+
+## Priorités
+
+### Must have (obligatoire)
+
+- REQ-F001, REQ-F002, REQ-NF001, REQ-C001
+
+### Should have (important)
+
+- REQ-F003, REQ-NF010
+
+### Nice to have (bonus)
+
+- REQ-NF020
+
+---
+
+## Traçabilité
+
+| Requirement | Source | Validé par |
+|-------------|--------|------------|
+| REQ-F001 | Brief section X | [Nom] |
+| REQ-F002 | Discussion [date] | [Nom] |
+
+---
+
+_Document généré le [date]_
+_Dernière mise à jour : [date]_
+```
+
+---
+
+## Guidelines
+
+### Numérotation
+
+- **REQ-F*** : Exigences fonctionnelles
+- **REQ-NF*** : Exigences non-fonctionnelles
+- **REQ-C*** : Contraintes
+- Numérotation par dizaines pour pouvoir insérer (001, 010, 020...)
+
+### Exigences fonctionnelles
+
+- Formuler avec un verbe d'action : "L'utilisateur peut...", "Le système doit..."
+- Un requirement = une fonctionnalité testable
+- Inclure le critère d'acceptation
+
+### Exigences non-fonctionnelles
+
+- Être mesurable quand possible (temps, pourcentage, score)
+- Couvrir : performance, sécurité, accessibilité, maintenabilité
+- Ne pas oublier la scalabilité si pertinent
+
+### Contraintes
+
+- Distinguer technique / business / réglementaire
+- Une contrainte est non-négociable (contrairement à un requirement)
+- Être explicite sur l'origine de la contrainte
+
+### Priorités
+
+- **Must** : Le package échoue sans ça
+- **Should** : Important mais on peut livrer sans
+- **Nice-to-have** : Bonus si on a le temps
+
+### Questions
+
+- Tracker toutes les questions posées pendant le shaping
+- Une question résolue = une décision documentée
+- Une question ouverte = un risque à surveiller

package/skills/makit-shaping/templates/research.md

@@ -0,0 +1,134 @@
+# Template: Research
+
+Ce template structure la recherche effectuée pour un package.
+
+---
+
+## Structure du document
+
+```markdown
+# Research : [Nom du package]
+
+## Contexte de la recherche
+
+[Pourquoi cette recherche ? Quelles questions cherche-t-on à répondre ?]
+
+---
+
+## État de l'art
+
+### Tendances actuelles
+
+- [Tendance 1]
+- [Tendance 2]
+- ...
+
+### Technologies émergentes
+
+- [Techno 1] : [Description courte]
+- [Techno 2] : [Description courte]
+
+---
+
+## Solutions existantes
+
+| Solution | Type | Points forts | Points faibles | Pertinence |
+|----------|------|--------------|----------------|------------|
+| [Nom] | [OSS/SaaS/...] | [+] | [-] | ⭐⭐⭐ |
+| [Nom] | [OSS/SaaS/...] | [+] | [-] | ⭐⭐ |
+
+### Analyse détaillée
+
+#### [Solution 1]
+
+- **URL** : [lien]
+- **Ce qu'ils font bien** : ...
+- **Ce qu'on peut améliorer** : ...
+- **Applicabilité** : ...
+
+#### [Solution 2]
+
+...
+
+---
+
+## Patterns et anti-patterns
+
+### Do's ✅
+
+- [Bonne pratique 1]
+- [Bonne pratique 2]
+- [Bonne pratique 3]
+
+### Don'ts ❌
+
+- [Anti-pattern 1] : [Pourquoi c'est problématique]
+- [Anti-pattern 2] : [Pourquoi c'est problématique]
+- [Anti-pattern 3] : [Pourquoi c'est problématique]
+
+---
+
+## Insights pour le projet
+
+### Opportunités identifiées
+
+1. [Opportunité 1]
+2. [Opportunité 2]
+
+### Risques identifiés
+
+1. [Risque 1] - Mitigation : [...]
+2. [Risque 2] - Mitigation : [...]
+
+### Recommandations
+
+- [Recommandation 1]
+- [Recommandation 2]
+
+---
+
+## Sources
+
+- [Titre source 1](url)
+- [Titre source 2](url)
+- ...
+
+---
+
+_Recherche effectuée le [date]_
+```
+
+---
+
+## Guidelines
+
+### Contexte de la recherche
+
+- Expliquer le "pourquoi" de la recherche
+- Lister les questions auxquelles on cherche à répondre
+- Donner le contexte du projet si pertinent
+
+### État de l'art
+
+- Se concentrer sur ce qui est actuel (pas de technos obsolètes)
+- Mentionner les tendances qui impactent le domaine
+- Rester factuel, pas de spéculation
+
+### Solutions existantes
+
+- Minimum 3-5 solutions comparées
+- Être objectif sur les points forts ET faibles
+- Utiliser un système de notation simple (étoiles)
+- Inclure au moins une solution open-source si possible
+
+### Do's / Don'ts
+
+- Basé sur des retours d'expérience réels
+- Citer les sources quand possible
+- Être actionnable (pas de généralités vagues)
+
+### Insights
+
+- Synthétiser ce qui est utile pour LE projet
+- Transformer les constats en recommandations
+- Identifier clairement les risques et leurs mitigations

package/skills/makit-shaping/templates/stack.md

@@ -0,0 +1,136 @@
+# Template: Stack
+
+Ce template structure les choix techniques pour un package.
+
+---
+
+## Structure du document
+
+```markdown
+# Stack : [Nom du package]
+
+## Décision
+
+[ ] **Pas de changement** - On utilise la stack existante
+[ ] **Nouvelles technologies** - Détails ci-dessous
+
+---
+
+## Technologies
+
+### Stack existante utilisée
+
+| Catégorie | Technologie | Version | Usage dans ce package |
+|-----------|-------------|---------|----------------------|
+| [Runtime] | [Node.js] | [20.x] | [Serveur API] |
+| [Framework] | [Next.js] | [14.x] | [Frontend] |
+| ... | ... | ... | ... |
+
+### Nouvelles technologies (si applicable)
+
+| Catégorie | Technologie | Version | Justification |
+|-----------|-------------|---------|---------------|
+| [Catégorie] | [Nom] | [Version] | [Pourquoi ce choix ?] |
+
+#### Détail : [Nouvelle techno 1]
+
+- **Pourquoi** : [Justification détaillée]
+- **Alternatives considérées** :
+  - [Alternative A] : Rejetée car [raison]
+  - [Alternative B] : Rejetée car [raison]
+- **Risques** : [Risques identifiés]
+- **Mitigation** : [Comment on gère les risques]
+
+---
+
+## Intégration avec l'existant
+
+### Points d'intégration
+
+- [Point 1] : [Comment ça s'intègre]
+- [Point 2] : [Comment ça s'intègre]
+
+### Modifications nécessaires
+
+- [ ] [Modification 1]
+- [ ] [Modification 2]
+
+### Compatibilité
+
+- **Versions Node.js** : [Versions supportées]
+- **Navigateurs** : [Navigateurs cibles]
+- **Autres** : [Contraintes de compatibilité]
+
+---
+
+## Risques identifiés
+
+| Risque | Probabilité | Impact | Mitigation |
+|--------|-------------|--------|------------|
+| [Risque 1] | Faible/Moyen/Élevé | Faible/Moyen/Élevé | [Comment mitiger] |
+| [Risque 2] | ... | ... | ... |
+
+---
+
+## Dépendances externes
+
+| Dépendance | Type | Criticité | Fallback |
+|------------|------|-----------|----------|
+| [API externe] | Service | Critique | [Plan B si indispo] |
+| [Lib NPM] | Package | Moyenne | [Alternative] |
+
+---
+
+## Décisions techniques
+
+### [Décision 1]
+
+- **Contexte** : [Situation qui nécessite une décision]
+- **Options** :
+  1. [Option A]
+  2. [Option B]
+- **Décision** : [Option choisie]
+- **Raison** : [Pourquoi]
+
+### [Décision 2]
+
+...
+
+---
+
+_Document généré le [date]_
+```
+
+---
+
+## Guidelines
+
+### Décision principale
+
+- Toujours commencer par clarifier si on change la stack ou non
+- Si pas de changement, le document peut être court
+- Si changements, détailler chaque nouvelle technologie
+
+### Justification des choix
+
+- Chaque nouvelle techno doit avoir une justification claire
+- Lister les alternatives considérées et pourquoi elles sont rejetées
+- Ne pas choisir une techno "parce qu'elle est hype"
+
+### Intégration
+
+- Identifier tous les points de contact avec l'existant
+- Lister les modifications nécessaires
+- Anticiper les problèmes de compatibilité
+
+### Risques
+
+- Être honnête sur les risques
+- Chaque risque doit avoir une mitigation
+- Ne pas minimiser les risques pour "vendre" une techno
+
+### Dépendances externes
+
+- Lister toutes les dépendances critiques
+- Prévoir un fallback pour les services tiers
+- Évaluer la stabilité des dépendances (maintenance active ?)