@atlashub/smartstack-cli 4.19.0 → 4.20.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@atlashub/smartstack-cli",
-  "version": "4.19.0",
+  "version": "4.20.0",
   "description": "SmartStack Claude Code automation toolkit - GitFlow, EF Core migrations, prompts and more",
   "author": {
     "name": "SmartStack",

package/templates/skills/business-analyse/SKILL.md

@@ -197,11 +197,11 @@ STEP 06 (review) — CLIENT LOOP ENTRY
 
 | File | Questions | Focus |
 |------|-----------|-------|
-| `questionnaire/01-context.md` | ~20 | Problem, current state, vision, triggers |
-| `questionnaire/02-stakeholders-scope.md` | ~25 | User profiles, priorities, scope boundaries |
-| `questionnaire/03-data-ui.md` | ~20 | Data entities, UI expectations, integrations |
-| `questionnaire/04-risks-metrics.md` | ~15 | Risks, success criteria, constraints |
-| `questionnaire/05-cross-module.md` | ~10 | Cross-module dependencies, shared data |
+| `questionnaire/01-context.md` | 3 | Business process, friction points, vision |
+| `questionnaire/02-stakeholders-scope.md` | 10 | User profiles, access levels, scope boundaries |
+| `questionnaire/03-data-ui.md` | ~15 | Data entities, UI expectations, dashboards |
+| `questionnaire/04-risks-metrics.md` | — | NOT USED (risks/metrics out of BA scope) |
+| `questionnaire/05-cross-module.md` | ~8 | Cross-module dependencies, integration impact |
 
 ## Entry Point
 

package/templates/skills/business-analyse/html/ba-interactive.html

@@ -1960,7 +1960,7 @@ body {
                 </div>
 
                 <!-- SECTION: Risques et hypotheses -->
-                <div class="section" id="cadrage-risks" style="display:none;">
+                <div class="section" id="cadrage-risks" style="display:none;" data-vibe-hide>
                     <h2 class="section-title">Risques et hypotheses</h2>
                     <p class="section-subtitle">Ce qui pourrait mal tourner et les certitudes non verifiees.</p>
 
@@ -2562,7 +2562,7 @@ function buildCadrageItems() {
     return renderNavItem('cadrage-context', 'Contexte') +
         renderNavItem('cadrage-stakeholders', 'Parties prenantes', data.cadrage.stakeholders.length) +
         renderNavItem('cadrage-scope', 'Perimetre fonctionnel') +
-        renderNavItem('cadrage-risks', 'Risques et hypotheses', data.cadrage.risks.length) +
+        (isVibeCoding ? '' : renderNavItem('cadrage-risks', 'Risques et hypotheses', data.cadrage.risks.length)) +
         renderNavItem('cadrage-success', 'Criteres de reussite');
 }
 
@@ -4399,7 +4399,7 @@ function renderHandoffStats() {
         <div class="stat-card"><div class="stat-value">${totalStakeholders}</div><div class="stat-label">Profils utilisateurs</div></div>
         <div class="stat-card"><div class="stat-value">${data.dependencies.length}</div><div class="stat-label">Dependances</div></div>
         <div class="stat-card"><div class="stat-value">${data.consolidation.e2eFlows.length}</div><div class="stat-label">Parcours bout en bout</div></div>
-        <div class="stat-card"><div class="stat-value">${data.cadrage.risks.length}</div><div class="stat-label">Risques identifies</div></div>
+        ${isVibeCoding ? '' : `<div class="stat-card"><div class="stat-value">${data.cadrage.risks.length}</div><div class="stat-label">Risques identifies</div></div>`}
     `;
 }
 

package/templates/skills/business-analyse/html/src/partials/cadrage-risks.html

@@ -1,5 +1,5 @@
                 <!-- SECTION: Risques et hypotheses -->
-                <div class="section" id="cadrage-risks" style="display:none;">
+                <div class="section" id="cadrage-risks" style="display:none;" data-vibe-hide>
                     <h2 class="section-title">Risques et hypotheses</h2>
                     <p class="section-subtitle">Ce qui pourrait mal tourner et les certitudes non verifiees.</p>
 

package/templates/skills/business-analyse/html/src/scripts/02-navigation.js

@@ -113,7 +113,7 @@ function buildCadrageItems() {
     return renderNavItem('cadrage-context', 'Contexte') +
         renderNavItem('cadrage-stakeholders', 'Parties prenantes', data.cadrage.stakeholders.length) +
         renderNavItem('cadrage-scope', 'Perimetre fonctionnel') +
-        renderNavItem('cadrage-risks', 'Risques et hypotheses', data.cadrage.risks.length) +
+        (isVibeCoding ? '' : renderNavItem('cadrage-risks', 'Risques et hypotheses', data.cadrage.risks.length)) +
         renderNavItem('cadrage-success', 'Criteres de reussite');
 }
 

package/templates/skills/business-analyse/html/src/scripts/07-render-handoff.js

@@ -24,7 +24,7 @@ function renderHandoffStats() {
         <div class="stat-card"><div class="stat-value">${totalStakeholders}</div><div class="stat-label">Profils utilisateurs</div></div>
         <div class="stat-card"><div class="stat-value">${data.dependencies.length}</div><div class="stat-label">Dependances</div></div>
         <div class="stat-card"><div class="stat-value">${data.consolidation.e2eFlows.length}</div><div class="stat-label">Parcours bout en bout</div></div>
-        <div class="stat-card"><div class="stat-value">${data.cadrage.risks.length}</div><div class="stat-label">Risques identifies</div></div>
+        ${isVibeCoding ? '' : `<div class="stat-card"><div class="stat-value">${data.cadrage.risks.length}</div><div class="stat-label">Risques identifies</div></div>`}
     `;
 }
 

package/templates/skills/business-analyse/html/src/template.html

@@ -193,7 +193,7 @@
                 </div>
 
                 <!-- SECTION: Risques et hypotheses -->
-                <div class="section" id="cadrage-risks" style="display:none;">
+                <div class="section" id="cadrage-risks" style="display:none;" data-vibe-hide>
                     <h2 class="section-title">Risques et hypotheses</h2>
                     <p class="section-subtitle">Ce qui pourrait mal tourner et les certitudes non verifiees.</p>
 

package/templates/skills/business-analyse/questionnaire/01-context.md

@@ -1,157 +1,32 @@
 # Categorie 1 : Contexte metier
 
-> **Usage :** Questions fondamentales pour comprendre le besoin metier en profondeur
+> **Usage :** Questions fondamentales pour comprendre le besoin metier
 > **Quand charger :** TOUJOURS (noyau)
-> **Objectif :** Comprendre le POURQUOI avant de parler du QUOI
+> **Objectif :** Comprendre le processus metier, les frictions, et la vision cible
 
 ---
 
-## 1.1 Le probleme a resoudre
-
-> **But :** Identifier la douleur reelle, pas la solution imaginee.
+## 1.1 Le processus metier
 
 | # | Question | Type de reponse |
 |---|----------|-----------------|
-| Q1.1 | Decrivez en quelques phrases le probleme que vous rencontrez aujourd'hui. Qu'est-ce qui ne fonctionne pas, ou pas assez bien ? | Texte libre |
-| Q1.2 | Qui souffre le plus de ce probleme au quotidien ? Quel impact a-t-il sur leur travail ? | Description des personnes impactees |
-| Q1.3 | Depuis combien de temps ce probleme existe-t-il ? A-t-il empire recemment ? | Historique et evolution |
-
-**Reformulation guidee pour Q1.1 :**
-```
-question: "Decrivez le probleme que vous rencontrez aujourd'hui"
-header: "Probleme"
-options:
-  - label: "Processus trop lent"
-    description: "Des taches repetitives prennent trop de temps et ralentissent le travail quotidien"
-  - label: "Informations dispersees"
-    description: "Les donnees sont eparpillees entre plusieurs outils, fichiers ou personnes"
-  - label: "Manque de visibilite"
-    description: "Impossible de suivre l'avancement, les chiffres ou l'etat d'une situation en temps reel"
-  - label: "Erreurs frequentes"
-    description: "Des erreurs humaines se produisent regulierement par manque d'outil adapte"
-```
+| Q1.1 | Decrivez en quelques phrases le processus metier que cette application doit gerer. Qu'est-ce qui se passe, qui intervient, et quel est le resultat attendu ? | Texte libre |
 
 ---
 
-## 1.2 La situation actuelle
-
-> **But :** Comprendre comment les choses se passent AUJOURD'HUI, concretement.
+## 1.2 Les points de friction
 
 | # | Question | Type de reponse |
 |---|----------|-----------------|
-| Q1.4 | Comment gerez-vous ce sujet aujourd'hui ? Avec quels outils (tableur, email, papier, logiciel) ? | Description des outils et methodes actuels |
-| Q1.5 | Decrivez les etapes principales de votre processus actuel, du debut a la fin. | Liste d'etapes ordonnees |
-| Q1.6 | Quelles sont les etapes les plus penibles ou les plus longues dans ce processus ? | Points de douleur precis |
-| Q1.7 | Quelles erreurs ou problemes reviennent regulierement ? Donnez 2 a 3 exemples concrets. | Exemples de dysfonctionnements |
-
-**Reformulation guidee pour Q1.4 :**
-```
-question: "Comment gerez-vous ce sujet aujourd'hui ?"
-header: "Outils"
-options:
-  - label: "Tableur (Excel, Sheets)"
-    description: "Fichiers Excel ou Google Sheets partages ou individuels"
-  - label: "Email et documents"
-    description: "Echanges par email avec pieces jointes, documents Word ou PDF"
-  - label: "Logiciel existant"
-    description: "Un logiciel est deja en place mais ne repond plus aux besoins"
-  - label: "Processus manuel"
-    description: "Papier, appels telephoniques, reunions en personne"
-```
+| Q1.4 | Quels sont les points de friction actuels ? Qu'est-ce qui bloque, ralentit, ou genere des erreurs dans ce processus ? | Description des frictions |
 
 ---
 
-## 1.3 La situation souhaitee
-
-> **But :** Definir clairement ce que le client veut OBTENIR, pas ce qu'il veut CONSTRUIRE.
+## 1.3 La vision souhaitee
 
 | # | Question | Type de reponse |
 |---|----------|-----------------|
-| Q1.8 | Si le probleme etait resolu demain, que feriez-vous differemment dans votre journee de travail ? | Description du changement concret |
-| Q1.9 | Quels resultats concrets attendez-vous ? Citez 2 a 3 ameliorations mesurables (gain de temps, reduction d'erreurs, meilleure visibilite...). | Liste de resultats attendus |
-| Q1.10 | Comment saurez-vous que le projet est un succes ? Quel est le signe visible qui montrera que le probleme est resolu ? | Critere de succes observable |
-
-**Reformulation guidee pour Q1.8 :**
-```
-question: "Si le probleme etait resolu demain, que changeriez-vous dans votre journee ?"
-header: "Vision"
-options:
-  - label: "Gain de temps"
-    description: "Des taches qui prennent des heures se feraient en quelques minutes"
-  - label: "Decisions plus rapides"
-    description: "Les informations seraient disponibles immediatement pour decider"
-  - label: "Moins d'erreurs"
-    description: "Les controles automatiques empecheraient les erreurs courantes"
-  - label: "Meilleure collaboration"
-    description: "Tout le monde verrait les memes informations a jour en temps reel"
-```
-
----
-
-## 1.4 Le declencheur et l'urgence
-
-> **But :** Comprendre pourquoi MAINTENANT et calibrer les attentes.
-
-| # | Question | Type de reponse |
-|---|----------|-----------------|
-| Q1.11 | Qu'est-ce qui a declenche cette demande ? Pourquoi maintenant et pas il y a 6 mois ? | Evenement declencheur |
-| Q1.12 | Que se passerait-il si ce projet n'etait PAS realise ? Quelles consequences a court et moyen terme ? | Impact de l'inaction |
-
-**Reformulation guidee pour Q1.11 :**
-```
-question: "Qu'est-ce qui a declenche cette demande maintenant ?"
-header: "Declencheur"
-options:
-  - label: "Croissance de l'activite"
-    description: "Le volume de travail a augmente et les outils actuels ne suivent plus"
-  - label: "Obligation reglementaire"
-    description: "Une nouvelle regle ou loi impose de changer la facon de travailler"
-  - label: "Probleme critique"
-    description: "Un incident recent a mis en lumiere un dysfonctionnement grave"
-  - label: "Opportunite strategique"
-    description: "Un changement d'organisation ou de strategie ouvre une fenetre d'action"
-```
-
----
-
-## Guide d'elicitation approfondi
-
-### Techniques de relance par question
-
-| Question | Si la reponse est vague ou insuffisante | Relance recommandee |
-|----------|----------------------------------------|---------------------|
-| Q1.1 (probleme) | Le client decrit une solution au lieu d'un probleme | "Oublions la solution un instant. Fermez les yeux et pensez a un moment recent ou ce probleme vous a frustre. Racontez-moi cette situation." |
-| Q1.2 (qui souffre) | Reponse generique "tout le monde" | "Prenons une personne precise, celle qui est la plus impactee. Quel est son poste ? Que fait-elle quand elle est bloquee par ce probleme ?" |
-| Q1.4 (outils actuels) | "On se debrouille" sans details | "Prenons un exemple concret : la derniere fois que ce probleme s'est presente, qu'avez-vous fait exactement, etape par etape ?" |
-| Q1.5 (processus actuel) | Moins de 3 etapes decrites | "Reprenons depuis le debut : quelqu'un a besoin de faire cette tache. Qu'est-ce qu'il fait en premier ? Puis ensuite ? Qui d'autre intervient ? Quand considere-t-on que c'est termine ?" |
-| Q1.6 (etapes penibles) | "Tout va bien sauf..." (minimisation) | "Si je chronometrais chaque etape de votre processus, laquelle prendrait le plus de temps ? Laquelle fait le plus soupirer vos equipes ?" |
-| Q1.7 (erreurs frequentes) | "Ca arrive rarement" | "La derniere fois qu'une erreur s'est produite, quel a ete l'impact ? Combien de temps pour la corriger ? Qui a du intervenir ?" |
-| Q1.8 (vision) | Reponse vague "ca irait mieux" | "Concretement, imaginez que vous arrivez lundi matin et que tout fonctionne parfaitement. Quelle est la premiere chose que vous faites differemment de d'habitude ?" |
-| Q1.9 (resultats) | Pas de chiffres ni de mesures | "Aujourd'hui, combien de temps prend ce processus ? Combien d'erreurs par mois ? Si on divisait par deux, est-ce que ca suffirait ?" |
-| Q1.10 (critere succes) | "Que les utilisateurs soient contents" | "Imaginons que 3 mois apres le lancement, je vous demande si le projet est un succes. Que me montrez-vous concretement comme preuve ?" |
-| Q1.12 (consequences inaction) | "Ca continuera comme avant" | "Et si ca continue encore 1 an comme ca ? 2 ans ? Quels risques voyez-vous : perte de clients, surcharge des equipes, non-conformite ?" |
-
-### Signaux d'alerte a detecter
-
-| Signal du client | Probleme sous-jacent | Action de l'analyste |
-|------------------|---------------------|----------------------|
-| "Il faudrait un bouton pour..." ou "On a besoin d'un ecran qui..." | **Le client decrit une solution, pas un besoin** | Reformuler : "Quel probleme ce bouton/ecran resoudrait-il ? Qu'est-ce qui est difficile aujourd'hui sans lui ?" |
-| "C'est evident" ou "Tout le monde le sait" | **Hypothese implicite non validee** | "Pouvez-vous me l'expliquer comme si c'etait ma premiere journee dans votre entreprise ? Je veux etre sur de bien comprendre." |
-| "On verra plus tard" ou "C'est pas prioritaire" | **Sujet potentiellement critique esquive** | "Je comprends. Pouvez-vous quand meme me donner un exemple pour que je le note ? On decidera ensemble de la priorite." |
-| Mots vagues : "optimiser", "ameliorer", "moderniser" | **Besoin non concretise** | "Quand vous dites 'optimiser', pouvez-vous me donner un exemple precis de ce qui serait different ?" |
-| "On fait comme le concurrent X" | **Besoin copie sans reflexion** | "Qu'est-ce qui fonctionne bien chez le concurrent X selon vous ? Et qu'est-ce qui ne vous conviendrait pas dans leur approche ?" |
-| Pas de reponse a Q1.12 (consequences inaction) | **Besoin possiblement artificiel** | Approfondir : si l'absence de solution n'a pas de consequence, le besoin est-il reel ? |
-
-### Regles d'enchainement
-
-| Apres | Si la reponse indique... | Alors |
-|-------|-------------------------|-------|
-| Q1.1 | Le client decrit un besoin technique | Poser Q1.2 pour recentrer sur les personnes impactees |
-| Q1.4 | Aucun outil existant | Sauter Q1.7 (pas d'erreurs a corriger dans un processus inexistant) |
-| Q1.5 | Processus tres simple (< 3 etapes) | Reduire la profondeur sur Q1.6, accelerer vers la vision (Q1.8) |
-| Q1.9 | Resultats non mesurables | Revenir a Q1.10 et insister sur le critere de succes observable |
-| Q1.11 | Obligation reglementaire | Charger le questionnaire de securite (categorie 06) en priorite |
-| Q1.12 | Consequences graves | Marquer le projet comme priorite haute, insister sur les risques dans le cadrage |
+| Q1.8 | Qu'est-ce qui doit changer ? Si le probleme etait resolu demain, que feriez-vous differemment dans votre journee de travail ? | Description du changement concret |
 
 ---
 
@@ -159,27 +34,6 @@ options:
 
 | Reponse | Alimente |
 |---------|----------|
-| Q1.1, Q1.2, Q1.3 | `cadrage.problem` |
-| Q1.4, Q1.5, Q1.6, Q1.7 | `cadrage.asIs` |
-| Q1.8, Q1.9, Q1.10 | `cadrage.toBe` + `cadrage.acceptanceCriteria` |
-| Q1.11, Q1.12 | `cadrage.trigger` + `cadrage.risks` |
-
----
-
-## Strategie de questionnement
-
-### Ordre des questions en 3 lots
-
-**Lot 1 (Q1.1, Q1.2, Q1.3, Q1.4) : Comprendre le probleme**
-- Commencer par le probleme et les personnes impactees
-- Poser ensuite la question des outils actuels pour ancrer dans le concret
-
-**Lot 2 (Q1.5, Q1.6, Q1.7) : Cartographier le processus actuel**
-- Detailler les etapes du processus existant
-- Identifier les points de friction et les erreurs recurrentes
-- Ce lot peut etre raccourci si le processus est simple
-
-**Lot 3 (Q1.8, Q1.9, Q1.10, Q1.11, Q1.12) : Definir la vision et l'urgence**
-- Projeter le client dans l'avenir : que changerait une solution ?
-- Quantifier les attentes : resultats mesurables
-- Comprendre le declencheur et les consequences de l'inaction
+| Q1.1 | `cadrage.problem` |
+| Q1.4 | `cadrage.asIs` |
+| Q1.8 | `cadrage.toBe` |

package/templates/skills/business-analyse/questionnaire/02-stakeholders-scope.md

@@ -1,40 +1,34 @@
 # Categorie 2 : Parties prenantes et perimetre
 
-> **Usage :** Identifier les acteurs, leurs besoins, et delimiter le perimetre fonctionnel
+> **Usage :** Identifier les profils utilisateurs, leurs droits, et delimiter le perimetre fonctionnel
 > **Quand charger :** TOUJOURS (noyau)
-> **Objectif :** Comprendre QUI utilise le systeme, COMMENT, et QUOI il doit faire
+> **Objectif :** Comprendre QUI utilise le systeme, avec quels DROITS, et QUOI il doit faire
 
 ---
 
 ## 2.1 Identification des utilisateurs
 
-> **But :** Dresser la carte complete de toutes les personnes qui interagiront avec le systeme.
+> **But :** Identifier les types de profils/roles qui interagiront avec le systeme.
 
 | # | Question | Type de reponse |
 |---|----------|-----------------|
-| Q2.1 | Qui sont les personnes qui utiliseront ce systeme au quotidien ? Decrivez leurs postes et ce qu'ils font dans l'entreprise. | Liste de profils utilisateurs |
-| Q2.2 | Y a-t-il des personnes qui ne l'utiliseront pas directement mais qui beneficieront des resultats (rapports, donnees, decisions) ? | Liste de beneficiaires indirects |
-| Q2.3 | Qui est le decideur final sur ce projet ? Qui peut dire "oui, on lance" ou "non, on arrete" ? | Nom et role du decideur |
-| Q2.4 | Y a-t-il des personnes ou des services qui pourraient s'opposer a ce projet ou le freiner ? Pourquoi ? | Liste de resistances potentielles |
+| Q2.1 | Qui sont les types de profils qui utiliseront ce systeme ? Decrivez leurs roles et ce qu'ils font. | Liste de profils utilisateurs |
 
 ---
 
-## 2.2 Le quotidien de chaque utilisateur
+## 2.2 Taches par profil
 
-> **But :** Comprendre concretement ce que chaque type d'utilisateur fait et a besoin de faire.
+> **But :** Comprendre concretement ce que chaque type d'utilisateur fait.
 
 | # | Question | Type de reponse |
 |---|----------|-----------------|
 | Q2.5 | Pour chaque type d'utilisateur : quelles sont les 3 a 5 taches principales qu'il doit accomplir avec ce systeme ? | Taches par profil utilisateur |
-| Q2.6 | A quelle frequence chaque utilisateur se servira-t-il du systeme ? Tous les jours ? Plusieurs fois par jour ? Une fois par semaine ? | Frequence d'utilisation par profil |
-| Q2.7 | Quel est le niveau de confort de chaque utilisateur avec les outils informatiques ? | Niveau d'aisance par profil |
-| Q2.8 | Pour chaque utilisateur : quelles sont ses 2 a 3 plus grandes frustrations avec la facon de travailler actuelle ? | Frustrations par profil |
 
 ---
 
 ## 2.3 Les niveaux d'acces
 
-> **But :** Definir qui peut voir quoi et faire quoi, en langage simple.
+> **But :** Definir qui peut voir quoi et faire quoi.
 
 | # | Question | Type de reponse |
 |---|----------|-----------------|
@@ -52,7 +46,6 @@
 |---|----------|-----------------|
 | Q2.12 | Listez toutes les fonctionnalites que vous souhaitez dans ce systeme. Ne vous censurez pas. | Liste libre de fonctionnalites |
 | Q2.13 | Parmi cette liste, quelles sont les fonctionnalites INDISPENSABLES ? Celles sans lesquelles le systeme n'a aucun interet ? | Liste de fonctionnalites vitales |
-| Q2.14 | Quelles fonctionnalites seraient tres utiles mais pourraient attendre une deuxieme version ? | Liste de fonctionnalites importantes |
 | Q2.15 | Y a-t-il des choses que le systeme ne doit explicitement PAS faire ? Des limites claires a poser ? | Liste d'exclusions |
 
 **Test de priorite :**
@@ -73,19 +66,6 @@
 
 ---
 
-## 2.6 Besoins transversaux
-
-> **But :** Identifier les fonctionnalites qui traversent tout le systeme.
-
-| # | Question | Type de reponse |
-|---|----------|-----------------|
-| Q2.19 | Les utilisateurs ont-ils besoin de recevoir des notifications ou des alertes ? Si oui, dans quelles situations ? | Liste de situations de notification |
-| Q2.20 | Faut-il pouvoir exporter des donnees du systeme (rapports, fichiers, impressions) ? Dans quel format et pour qui ? | Besoins d'export |
-| Q2.21 | Faut-il pouvoir importer des donnees dans le systeme depuis une source externe ? | Besoins d'import |
-| Q2.22 | Faut-il garder un historique de qui a fait quoi et quand ? Pour quelles actions ? | Besoins de tracabilite |
-
----
-
 ## Guide d'elicitation approfondi
 
 ### Techniques de relance
@@ -93,7 +73,6 @@
 | Question | Si la reponse est vague | Relance recommandee |
 |----------|------------------------|---------------------|
 | Q2.1 (utilisateurs) | Un seul type mentionne | "Pensez aux differents moments de la journee : qui saisit ? Qui consulte les rapports ? Qui gere les cas particuliers ?" |
-| Q2.4 (oppositions) | "Personne ne s'opposera" | "Quand un nouvel outil est introduit, qui doit changer ses habitudes le plus ?" |
 | Q2.5 (taches) | Taches generiques | "Quand il arrive le matin et ouvre le systeme, quelle est sa premiere action ?" |
 | Q2.9 (visibilite) | Reponse ambigue | "Un employe du service A peut-il voir les donnees du service B ? Un stagiaire voit-il la meme chose qu'un directeur ?" |
 | Q2.13 (indispensable) | Tout est indispensable | "Si vous ne pouviez garder que 3 fonctionnalites pour un premier lancement, lesquelles ?" |
@@ -116,27 +95,7 @@
 
 | Reponse | Alimente |
 |---------|----------|
-| Q2.1-Q2.4 | `cadrage.stakeholders[]` |
-| Q2.5-Q2.8 | `cadrage.stakeholders[].tasks`, `.frequency`, `.painPoints` |
+| Q2.1, Q2.5 | `cadrage.stakeholders[]` |
 | Q2.9-Q2.11 | `cadrage.applicationRoles[]` |
-| Q2.12-Q2.15 | `cadrage.globalScope` (vital, important, optional, excluded) |
+| Q2.12-Q2.13, Q2.15 | `cadrage.globalScope` (vital, important, excluded) |
 | Q2.16-Q2.18 | `cadrage.coverageMatrix` + base pour les cas d'utilisation |
-| Q2.19-Q2.22 | `cadrage.coverageMatrix` + detection de modules transversaux |
-
----
-
-## Strategie de questionnement
-
-### Ordre des questions en 4 lots
-
-**Lot 1 (Q2.1-Q2.4) : Qui est concerne ?**
-- Identifier tous les acteurs du projet
-
-**Lot 2 (Q2.5-Q2.11) : Que font-ils et quels droits ?**
-- Detailler les taches, frequences et niveaux d'acces par profil
-
-**Lot 3 (Q2.12-Q2.15) : Quel perimetre ?**
-- Lister et hierarchiser les fonctionnalites
-
-**Lot 4 (Q2.16-Q2.22) : Comment ca se deroule ?**
-- Cartographier le parcours principal et les besoins transversaux

package/templates/skills/business-analyse/questionnaire/03-data-ui.md

@@ -13,7 +13,6 @@
 | Q3.1 | Quelles sont les entites principales gerees par ce module ? | Liste d'entites |
 | Q3.2 | Pour chaque entite : quels sont les attributs importants ? | Par entite |
 | Q3.3 | Quelles relations existent entre les entites ? (appartient a, contient, reference) | Schema relationnel |
-| Q3.4 | Volume de donnees attendu ? (dizaines, centaines, milliers, millions) | Estimation par entite |
 | Q3.5 | Pour chaque entite : le Code doit-il etre auto-genere ou saisi par l'utilisateur ? | Par entite |
 | Q3.6 | Si auto-genere : quelle strategie ? (sequentiel, timestamp, annee, UUID court) | Par entite |
 
@@ -56,7 +55,6 @@
 | Q3.1 (entites) | Mention de "User" | "L'utilisateur est gere par la plateforme. Decrivez l'entite METIER (Client, Employee, Contact...)" |
 | Q3.2 (attributs) | Champs techniques (ID, CreatedDate) | "Les champs techniques sont auto-geres. Quels sont les attributs METIER ?" |
 | Q3.3 (relations) | "1:N" sans detail | "Un {Parent} peut avoir combien de {Children} max ? Un {Child} peut-il exister sans {Parent} ?" |
-| Q3.4 (volume) | "Beaucoup" | "Ordre de grandeur : dizaines, centaines, milliers, millions ? Croissance par mois ?" |
 | Q3.11 (ecrans) | "Un ecran de liste" | "Avec pages dediees pour creation et edition ? Detail en page avec onglets ?" |
 | Q3.13 (actions) | "CRUD classique" | "Actions metier specifiques ? (valider, dupliquer, archiver, changer statut, assigner)" |
 | Q3.14 (dashboards) | "Juste des chiffres" | "Les tendances ne seraient-elles pas plus lisibles en graphique ?" |
@@ -88,7 +86,7 @@
 
 | Reponse | Alimente |
 |---------|----------|
-| Q3.1-Q3.6 | `entities.json` (entites, attributs, relations, codePattern) |
+| Q3.1-Q3.3, Q3.5-Q3.6 | `entities.json` (entites, attributs, relations, codePattern) |
 | Q3.7-Q3.9 | `rules.json` (regles metier de validation et securite) |
 | Q3.10-Q3.13 | `screens.json` (sections, resources, colonnes, actions) |
 | Q3.14-Q3.16 | `screens.json` (sections dashboard, KPI resources) |

package/templates/skills/business-analyse/questionnaire/04-risks-metrics.md

@@ -1,150 +1,6 @@
 # Categorie 4 : Risques et criteres de reussite
 
-> **Usage :** Identifier les risques et definir comment mesurer le succes
-> **Quand charger :** TOUJOURS (noyau, charge dans le cadrage)
-> **Objectif :** Anticiper les problemes et etablir des criteres observables
-
----
-
-## 4.1 Les risques identifies
-
-> **But :** Lister tout ce qui pourrait empecher le projet de reussir.
-
-| # | Question | Type de reponse |
-|---|----------|-----------------|
-| Q4.1 | Quels sont les principaux risques que vous voyez pour ce projet ? Qu'est-ce qui pourrait mal tourner ? | Liste de risques |
-| Q4.2 | Parmi ces risques, lesquels auraient les consequences les plus graves ? | Hierarchisation par gravite |
-| Q4.3 | Pour chaque risque grave : avez-vous une idee de comment le prevenir ou le reduire ? | Mesures de mitigation |
-
-**Reformulation guidee pour Q4.1 :**
-```
-question: "Quels sont les principaux risques que vous voyez pour ce projet ?"
-header: "Risques"
-multiSelect: true
-options:
-  - label: "Adoption par les utilisateurs"
-    description: "Les utilisateurs pourraient ne pas vouloir changer leurs habitudes"
-  - label: "Qualite des donnees existantes"
-    description: "Les donnees actuelles sont incompletes, incorrectes ou dispersees"
-  - label: "Complexite des regles metier"
-    description: "Certaines regles sont mal documentees ou connues uniquement par quelques personnes"
-  - label: "Dependances externes"
-    description: "Le projet depend de systemes ou decisions externes qui pourraient retarder"
-```
-
----
-
-## 4.2 Les hypotheses a valider
-
-> **But :** Rendre explicites les certitudes non verifiees.
-
-| # | Question | Type de reponse |
-|---|----------|-----------------|
-| Q4.4 | Quelles hypotheses faites-vous sur le projet ? Qu'est-ce que vous tenez pour acquis sans l'avoir verifie ? | Liste d'hypotheses |
-| Q4.5 | Parmi ces hypotheses, lesquelles seraient les plus graves si elles se revelaient fausses ? | Hierarchisation par impact |
-| Q4.6 | Comment pourriez-vous verifier ces hypotheses avant que le projet avance trop loin ? | Methodes de validation |
-
----
-
-## 4.3 Les lecons du passe
-
-| # | Question | Type de reponse |
-|---|----------|-----------------|
-| Q4.7 | Y a-t-il eu des projets similaires dans l'entreprise ? Qu'est-ce qui a fonctionne ou echoue ? | Retour d'experience |
-| Q4.8 | Si ce projet devait echouer, quelle serait la raison la plus probable ? | Cause d'echec anticipee |
-
----
-
-## 4.4 La definition du succes
-
-> **But :** Determiner concretement ce qui fera dire "ce projet est un succes".
-
-| # | Question | Type de reponse |
-|---|----------|-----------------|
-| Q4.9 | Quand le systeme sera en place, comment saurez-vous que le projet est un succes ? Quel changement concret observerez-vous ? | Description du succes observable |
-| Q4.10 | Si vous deviez convaincre votre direction que le projet a reussi, quels chiffres presenteriez-vous ? | Metriques de succes |
-| Q4.11 | Au bout de combien de temps apres le lancement pourrez-vous juger si ca fonctionne ? | Delai d'evaluation |
-
-**Reformulation guidee pour Q4.9 :**
-```
-question: "Comment saurez-vous que le projet est un succes ?"
-header: "Succes"
-options:
-  - label: "Gain de temps mesurable"
-    description: "Un processus qui prenait X heures ne prend plus que Y minutes"
-  - label: "Reduction des erreurs"
-    description: "Le nombre d'erreurs a diminue de maniere significative"
-  - label: "Meilleure satisfaction"
-    description: "Les utilisateurs expriment que leur quotidien s'est ameliore"
-  - label: "Indicateurs en hausse"
-    description: "Des chiffres cles se sont ameliores"
-```
-
----
-
-## 4.5 Les objectifs mesurables
-
-| # | Question | Type de reponse |
-|---|----------|-----------------|
-| Q4.12 | Pour chaque amelioration attendue, pouvez-vous donner un objectif chiffre ? | Objectifs quantifies |
-| Q4.13 | Quels indicateurs suivez-vous deja aujourd'hui qui pourraient servir de reference ? | Indicateurs existants |
-
----
-
-## 4.6 Les criteres d'acceptation
-
-| # | Question | Type de reponse |
-|---|----------|-----------------|
-| Q4.14 | Quelles sont les conditions minimales pour que vous acceptiez de mettre le systeme en service ? | Liste de conditions obligatoires |
-| Q4.15 | Qui decide officiellement que le systeme est pret a etre utilise ? | Processus de validation |
-
----
-
-## Guide d'elicitation approfondi
-
-### Techniques de relance
-
-| Question | Si la reponse est vague | Relance recommandee |
-|----------|------------------------|---------------------|
-| Q4.1 (risques) | "Je ne vois pas de risque" | "Pensez aux projets passes : qu'est-ce qui a coince ? Les delais ? L'adoption ? La qualite des donnees ?" |
-| Q4.4 (hypotheses) | "On ne fait pas d'hypotheses" | "Est-on certain que tous les utilisateurs ont un ordinateur ? Que les donnees actuelles sont completes ?" |
-| Q4.8 (echec) | Refuse de repondre | "C'est une question difficile mais importante. Imaginons le pire scenario : cela nous aide a le prevenir." |
-| Q4.9 (succes) | "Que tout fonctionne bien" | "Imaginons que je visite votre bureau 3 mois apres le lancement. Qu'est-ce que je verrais de different ?" |
-| Q4.12 (objectifs) | "Difficile a chiffrer" | "Meme approximativement : le processus prend combien de temps aujourd'hui ? Quel serait un temps acceptable ?" |
-| Q4.14 (conditions) | "Il faut que tout soit parfait" | "Si vous deviez lancer avec seulement 80% des fonctionnalites, lesquelles seraient dans ces 80% ?" |
-
-### Signaux d'alerte
-
-| Signal du client | Probleme sous-jacent | Action |
-|------------------|---------------------|--------|
-| "Il n'y a aucun risque" | Manque de recul | Proposer des risques standards |
-| Risques uniquement techniques | Vision incomplete | Ajouter dimensions humaines et organisationnelles |
-| Aucun critere mesurable | Succes non defini | Proposer metriques standards : temps, erreurs, adoption, satisfaction |
-| "Ca doit etre parfait" | Attentes irrealistes | "Quel est le niveau minimum acceptable pour un premier lancement ?" |
-
----
-
-## Mapping vers le cadrage
-
-| Reponse | Alimente |
-|---------|----------|
-| Q4.1-Q4.3 | `cadrage.risks[]` |
-| Q4.4-Q4.6 | `cadrage.risks[]` (type: "assumption") |
-| Q4.7-Q4.8 | `cadrage.risks[]` (enrichissement contexte historique) |
-| Q4.9-Q4.13 | `cadrage.acceptanceCriteria[]` |
-| Q4.14-Q4.15 | `cadrage.acceptanceCriteria[]` (conditions de livraison) |
-
----
-
-## Strategie de questionnement
-
-### Ordre en 3 lots
-
-**Lot 1 (Q4.1-Q4.6) : Risques et hypotheses**
-- Commencer par les risques visibles puis les hypotheses implicites
-
-**Lot 2 (Q4.7-Q4.8) : Lecons du passe**
-- Tirer les lecons des experiences precedentes
-
-**Lot 3 (Q4.9-Q4.15) : Succes et acceptation**
-- Definir le succes, quantifier, etablir les conditions de livraison
+> **NOT USED** — Les risques projet, hypotheses, lecons du passe, metriques de succes et conditions de livraison
+> ne sont pas du scope de la BA en vibe coding.
+>
+> La documentation technique est generee automatiquement par `/documentation` apres `/ralph-loop`.

package/templates/skills/business-analyse/questionnaire/05-cross-module.md

@@ -2,7 +2,7 @@
 
 > **Usage :** Analyser l'impact sur les modules existants et les dependances partagees
 > **Quand charger :** TOUJOURS pour les nouveaux modules (pas les ameliorations)
-> **Objectif :** Detecter les interactions, les entites partagees et les risques de conflit
+> **Objectif :** Detecter les interactions, les entites partagees et les impacts d'integration
 
 ---
 
@@ -21,8 +21,8 @@
 |---|----------|-----------------|
 | Q5.5 | Les modules existants doivent-ils etre modifies pour supporter ce nouveau module ? | Liste de changements |
 | Q5.6 | Y a-t-il des composants UI ou des changements de navigation partages ? | Liste |
-| Q5.7 | Ce module affectera-t-il les permissions ou roles existants ? | Oui/Non + detail |
-| Q5.8 | Y a-t-il un risque de conflit de modele de donnees ? (meme entite modifiee par 2 modules) | Evaluation du risque |
+| Q5.7 | Ce module affectera-t-il les permissions ou roles existants ? Quel impact sur l'integration ? | Oui/Non + detail |
+| Q5.8 | Y a-t-il des entites partagees modifiees par plusieurs modules ? Quel impact sur l'integration ? | Evaluation de l'impact |
 
 ---
 
@@ -49,7 +49,7 @@
 | Q5.2 (donnees partagees) | "Je ne sais pas" | Utiliser le `{codebase_context}` : "J'ai trouve les entites {list}. Ce module a-t-il besoin de les referencer ?" |
 | Q5.3 (FK references) | Vague | "Une {entity} de ce module appartient-elle a un {existing_entity} ?" |
 | Q5.4 (evenements) | "Non" | "Quand un {entity} est cree/modifie/supprime, faut-il notifier un autre module ?" |
-| Q5.8 (conflits) | "Pas de risque" | "Deux modules modifient-ils la meme entite ?" |
+| Q5.8 (impact) | "Pas d'impact" | "Deux modules modifient-ils la meme entite ? Quel est l'impact sur l'integration ?" |
 
 ### Anti-patterns a detecter
 
@@ -66,4 +66,4 @@
 | Reponse | Alimente |
 |---------|----------|
 | Q5.1-Q5.4 | `consolidation.crossModuleInteractions[]`, `consolidation.sharedEntities[]` |
-| Q5.5-Q5.8 | `consolidation.globalRiskAssessment[]`, `consolidation.permissionCoherence` |
+| Q5.5-Q5.8 | `consolidation.impactAssessment[]`, `consolidation.permissionCoherence` |

package/templates/skills/business-analyse/questionnaire.md

@@ -3,7 +3,7 @@
 > **Usage:** Structured questions for step-01-cadrage and step-03-specify
 > **Standard:** BABOK v3 - Elicitation Techniques (Interactive analysis)
 > **Model:** OPUS with ULTRATHINK
-> **Total:** ~90 targeted questions across 5 questionnaire files
+> **Total:** ~20 targeted questions across 4 active questionnaire files
 
 ---
 
@@ -34,11 +34,11 @@
 
 | File | Questions | Phase | Focus |
 |------|-----------|-------|-------|
-| `questionnaire/01-context.md` | ~20 | step-01-cadrage | Problem, current state, vision, triggers, application identity |
-| `questionnaire/02-stakeholders-scope.md` | ~25 | step-01-cadrage | User profiles, priorities, scope boundaries, MoSCoW |
-| `questionnaire/03-data-ui.md` | ~20 | step-03-specify (per module) | Data entities, UI expectations, integrations |
-| `questionnaire/04-risks-metrics.md` | ~15 | step-01-cadrage | Risks, success criteria, constraints, performance |
-| `questionnaire/05-cross-module.md` | ~10 | step-03-specify (conditional) | Cross-module dependencies, shared data, E2E flows |
+| `questionnaire/01-context.md` | 3 | step-01-cadrage | Business process, friction points, vision |
+| `questionnaire/02-stakeholders-scope.md` | 10 | step-01-cadrage | User profiles, access levels, scope boundaries, MoSCoW |
+| `questionnaire/03-data-ui.md` | ~15 | step-03-specify (per module) | Data entities, UI expectations, dashboards |
+| `questionnaire/04-risks-metrics.md` | — | NOT USED | Risks/metrics out of BA scope |
+| `questionnaire/05-cross-module.md` | ~8 | step-03-specify (conditional) | Cross-module dependencies, integration impact |
 
 ---
 
@@ -48,7 +48,7 @@
 
 | Phase | Questionnaires charges |
 |-------|----------------------|
-| step-01-cadrage | 01-context, 02-stakeholders-scope, 04-risks-metrics |
+| step-01-cadrage | 01-context, 02-stakeholders-scope |
 | step-03-specify (par module) | 03-data-ui, conditionnellement 05-cross-module |
 
 ### Phase de cadrage (step-01)
@@ -58,7 +58,6 @@
 3. **Approfondir :** Poser des questions de relance sur les reponses vagues
 4. **Challenger :** Ne pas accepter "on verra plus tard" sur les fonctionnalites indispensables
 5. **Par lots :** Presenter 3 a 4 questions par interaction (AskUserQuestion)
-6. **Risques et succes :** Charger 04-risks-metrics en fin de cadrage
 
 ### Phase de specification (step-03)
 

package/templates/skills/business-analyse/steps/step-01-cadrage.md

@@ -209,13 +209,11 @@ options:
 #### 4a. Business Context (ALWAYS — from `questionnaire/01-context.md`)
 
 > Load the full questionnaire reference for elicitation guides and alert signals.
+> The questionnaire contains 3 targeted questions: Q1.1 (business process), Q1.4 (friction points), Q1.8 (vision).
 
-Select the most relevant questions from Q1.1-Q1.12.
-**Mandatory minimum:** Q1.1 (problem), Q1.4 (current tools), Q1.8 (vision), Q1.11 (trigger).
+Ask all 3 questions in 1 batch via AskUserQuestion.
 
-Ask in 1-2 batches via AskUserQuestion (max 4 questions per batch).
-
-Apply ULTRATHINK after each batch:
+Apply ULTRATHINK after the batch:
 - If answer is vague → probe deeper using the elicitation guide from 01-context.md
 - If answer is solution-oriented → apply Technique 1 (reformulate as need)
 - If answer is superficial → apply Technique 2 (chain of whys)
@@ -223,7 +221,9 @@ Apply ULTRATHINK after each batch:
 
 #### 4b. Stakeholders (ALWAYS — from `questionnaire/02-stakeholders-scope.md`)
 
-**Mandatory minimum:** Q2.1 (users), Q2.5 (tasks per profile), Q2.9 (access levels).
+> The questionnaire contains 10 targeted questions covering profiles, tasks, access levels, scope, and user journey.
+
+**Mandatory minimum:** Q2.1 (users), Q2.5 (tasks per profile), Q2.9-Q2.11 (access levels).
 
 Ask in 1-2 batches. After each batch:
 - If only 1 user type mentioned → probe: "Who else interacts? Managers? Admins? External users?"
@@ -232,7 +232,7 @@ Ask in 1-2 batches. After each batch:
 
 #### 4c. Functional Scope (ALWAYS — from `questionnaire/02-stakeholders-scope.md`)
 
-**Mandatory minimum:** Q3.2 (must-have), Q3.4 (exclusions), Q3.5 (main journey).
+**Mandatory minimum:** Q2.13 (must-have), Q2.15 (exclusions), Q2.16 (main journey).
 
 Ask in 1-2 batches. After each batch:
 - If everything is "must-have" → **BLOCKING**: apply MoSCoW prioritization question
@@ -441,15 +441,7 @@ options:
 
 > **CRITICAL:** The intelligence of this step is in the ULTRATHINK analysis. The AI must REASON about domain coherence, score the entity, and recommend — not just present 4 neutral options. The client can always override the recommendation, but they should benefit from expert architectural guidance.
 
-#### 4e. Risks & Success Criteria (ALWAYS — from `questionnaire/04-risks-metrics.md`)
-
-Select the most pertinent questions:
-- **04-risks-metrics.md:** Risk identification, assumptions validation
-- **04-risks-metrics.md:** Success definition, measurable objectives
-
-Ask in 1 batch via AskUserQuestion.
-
-#### 4f. Conditional Deep-Dives
+#### 4e. Conditional Deep-Dives
 
 Based on brief analysis, load additional materials if relevant:
 
@@ -460,33 +452,6 @@ Based on brief analysis, load additional materials if relevant:
 | Performance requirements | Additional probing on non-functional needs |
 | Technical constraints | Additional probing on platform constraints |
 
-#### 4g. Documentation Needs (ALWAYS — from `questionnaire/03-data-ui.md`)
-
-> **Every application requires documentation decisions made upfront, not as an afterthought.**
-> Load relevant documentation section from questionnaire/03-data-ui.md
-
-Ask in 1 batch via AskUserQuestion (max 3 questions):
-- Will users need documentation (guide, FAQ, in-app tooltips)?
-- Is technical documentation required (API docs, ERD, developer guide)?
-- Who is responsible for maintaining documentation after delivery?
-
-After the batch:
-- If "Non" to both → probe: "Pas même les docs API ou un guide d'accueil pour les nouveaux utilisateurs ?"
-- If "Oui" without detail → ask format: "Tooltips intégrés ? Guide PDF ? Wiki ? Portail dédié ?"
-- If "La doc se fera après" → challenge: "La documentation est planifiée maintenant et générée par `/documentation` après `/ralph-loop`. Quel niveau souhaitez-vous ?"
-
-**Store in `cadrage.documentation`:**
-```json
-{
-  "userDocumentation": { "needed": true, "format": "tooltips|guide|wiki|pdf|portal", "audience": "..." },
-  "technicalDocumentation": { "needed": true, "format": "swagger|erd|developer-guide", "generated": true },
-  "owner": "who maintains it",
-  "skill": "/documentation — runs after /ralph-loop"
-}
-```
-
-This feeds directly into handoff step-05 category `documentation` in `filesToCreate`.
-
 ---
 
 ## PHASE 4: ANTICIPATION (Suggest Unexpressed Needs)
@@ -677,20 +642,16 @@ ba-writer.enrichSection({
     problem: {from Phase 3, section 4a — Q1.1 answer or refined problem},
     asIs: {from Phase 3, section 4a — Q1.4 answer},
     toBe: {from Phase 3, section 4a — Q1.8 answer},
-    trigger: {from Phase 3, section 4a — Q1.11 answer},
     stakeholders: [{from Phase 3, section 4b}],
     globalScope: {
       mustHave: [{from Phase 3, section 4c + Phase 4 accepted suggestions}],
       shouldHave: [{from coverage matrix}],
       couldHave: [{from coverage matrix}],
-      outOfScope: [{from Phase 3, section 4c — Q3.4 exclusions}]
+      outOfScope: [{from Phase 3, section 4c — Q2.15 exclusions}]
     },
     applicationRoles: [{from Phase 5, section 6}],
     errorFlows: [{from Phase 3, section 4c}],
-    risks: [{from Phase 3, section 4e}],
-    acceptanceCriteria: [{from Phase 3, section 4e}],
     coverageMatrix: [{from Phase 5, section 7 — with anticipatedSections and anticipatedResources}],
-    documentation: {from Phase 3, section 4g},
     codebaseContext: "{string summary of codebase findings}"
   }
 })
@@ -708,7 +669,6 @@ ba-writer.updateStatus({feature_id}, "framed")
 | Stakeholders | {count} |
 | Must-have scope items | {count} |
 | Application roles | {count} |
-| Risks identified | {count} |
 | Suggestions accepted | {count} |
 | Anticipated sections | {total across all modules} |
 

package/templates/skills/documentation/SKILL.md

@@ -22,10 +22,17 @@ Works in synergy with the `/documentation module` command.
 <quick_start>
 ## WHEN THIS SKILL ACTIVATES
 
+### PREREQUISITE — ONLY post-implementation
+This skill requires the feature page to already exist (generated by /ralph-loop).
+It reads real TSX pages, controllers, and entities. Without them, nothing to document.
+
+→ For reviewing/editing the analysis BEFORE implementation: use ba-interactive.html (/business-analyse step-05)
+
 Claude automatically invokes this skill when it detects:
 
 | Trigger | Example |
 |---------|---------|
+| ❌ NEVER during BA | Before /ralph-loop — feature page does not exist yet |
 | Explicit request | "Document the SLA module" |
 | Documentation mention | "We should create the doc for..." |
 | After implementation | "The feature is done, generate the doc" |