@atlashub/smartstack-cli 1.1.0

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

@@ -0,0 +1,191 @@
+---
+name: business-analyse
+description: |
+  Analyses business requirements and generates functional specifications (FRD) for SmartStack.
+  Produces HTML documentation in the web project. Restricted to Business context only.
+  Use when:
+  - User asks to analyze a business need or requirement
+  - User mentions "specification", "FRD", "user story", "business rules"
+  - User wants to document a new module or feature in Business context
+  - User needs functional documentation for client-facing features
+  Context: Business > Application > Module > Section only
+---
+
+# Skill Business Analyse SmartStack
+
+> **Workflow orienté projet:** Business > Application > Module > Section
+> **Output:** Composants React dans `web/smartstack-web/src/pages/docs/business/`
+
+## PHASE 0: VALIDATION CONTEXTE BUSINESS (CRITIQUE)
+
+```
+╔══════════════════════════════════════════════════════════════════════════════╗
+║  RESTRICTION: CONTEXTE BUSINESS UNIQUEMENT                                   ║
+╠══════════════════════════════════════════════════════════════════════════════╣
+║                                                                              ║
+║  AVANT toute analyse, VÉRIFIER:                                              ║
+║                                                                              ║
+║  ❌ REFUSER si contexte = "platform" (réservé core SmartStack)               ║
+║  ❌ REFUSER si contexte = "personal" (réservé espace utilisateur)            ║
+║  ❌ REFUSER si contexte = "system" (réservé infrastructure)                  ║
+║                                                                              ║
+║  ✅ ACCEPTER uniquement contexte = "business"                                ║
+║                                                                              ║
+║  MESSAGE ERREUR:                                                             ║
+║  "La Business Analyse est réservée au contexte 'business' pour les          ║
+║   modules client. Les contextes platform/personal/system sont gérés          ║
+║   par l'équipe core SmartStack."                                             ║
+║                                                                              ║
+║  Contact: support@atlshub.ch                                                 ║
+║                                                                              ║
+╚══════════════════════════════════════════════════════════════════════════════╝
+```
+
+## QUAND CE SKILL S'ACTIVE
+
+| Déclencheur | Exemple |
+|-------------|---------|
+| Demande explicite | "Analyse le besoin de gestion des tickets" |
+| Mention spec/FRD | "Il faut créer les specs pour le module CRM" |
+| Nouveau module business | "Ajouter un module de facturation client" |
+| Documentation fonctionnelle | "Documenter les règles métier du SLA" |
+
+---
+
+## WORKFLOW 7 PHASES (FRD → HTML)
+
+```
+════════════════════════════════════════════════════════════════════════════════
+
+   INIT       DISCOVER      ANALYSE       SPECIFY      VALIDATE      HANDOFF      DOC-HTML
+  ┌─────┐    ┌─────────┐   ┌─────────┐   ┌─────────┐   ┌────────┐   ┌─────────┐  ┌─────────┐
+  │Setup│───►│Elicit   │──►│Model    │──►│FRD      │──►│Approve │──►│Prompt   │─►│React    │
+  └─────┘    └─────────┘   └─────────┘   └─────────┘   └────────┘   └─────────┘  └─────────┘
+     │            │             │             │             │             │            │
+     ▼            ▼             ▼             ▼             ▼             ▼            ▼
+ Structure   Discovery     BRD.md        FRD.md       Approval     Dev Prompt    FrdDocPage
+ Validate    (40+ Q)       Process       Use Cases     Gate        Autonomous    .tsx
+ Context7                  Rules         Wireframes    ↓ NOK                     i18n
+                                                       → ANALYSE
+                                                       (revise)
+
+             [OPUS]       [SONNET]      [SONNET]                   [OPUS]       [SONNET]
+
+════════════════════════════════════════════════════════════════════════════════
+```
+
+---
+
+## STRUCTURE HIÉRARCHIQUE (Alignée navigation)
+
+```
+business/                          # Contexte (SEUL autorisé)
+├── {application}/                 # Ex: crm, support, billing
+│   ├── context.md                 # Description application
+│   └── {module}/                  # Ex: tickets, customers, invoices
+│       ├── context.md             # Description module
+│       └── {section}/             # Ex: settings, reports (optionnel)
+│           └── features/
+│               └── FEAT-XXX-name/
+│                   ├── 1-discovery.md
+│                   ├── 2-brd.md
+│                   ├── 3-frd.md
+│                   ├── 4-handoff.md
+│                   └── validation.json
+```
+
+---
+
+## OUTPUT HTML - DESTINATION
+
+| Type | Chemin | Exemple |
+|------|--------|---------|
+| FRD Module | `web/.../pages/docs/business/{app}/{module}/FrdPage.tsx` | `docs/business/support/tickets/FrdPage.tsx` |
+| i18n | `web/.../i18n/locales/{lang}/docs-business.json` | FR, EN, IT, DE obligatoires |
+| Index | `web/.../pages/docs/business/{app}/index.tsx` | Index application |
+
+---
+
+## STRATÉGIE MODÈLES (Qualité optimale)
+
+| Phase | Modèle | Raison | Coût estimé |
+|-------|--------|--------|-------------|
+| 1-init | **Haiku** | Setup structure, pas de décision | ~$0.02 |
+| 2-discover | **Opus** | Elicitation exhaustive, ULTRATHINK | ~$0.30 |
+| 3-analyse | **Sonnet** | Modélisation, règles métier | ~$0.15 |
+| 4-specify | **Sonnet** | FRD complet, use cases | ~$0.18 |
+| 5-validate | **Haiku** | Gate approbation, oui/non | ~$0.01 |
+| 6-handoff | **Opus** | Prompt one-shot, zéro ambiguïté | ~$0.35 |
+| 7-doc-html | **Sonnet** | Génération React + i18n + Context7 | ~$0.20 |
+| **Total** | | | **~$1.21** |
+
+---
+
+## RÈGLES ABSOLUES
+
+1. **Contexte BUSINESS uniquement** - Refuser platform/personal/system
+2. **JAMAIS de code dans les specs** - Tables, diagrammes textuels, pas de C#/JS
+3. **Context7 pour génération React** - Toujours utiliser pour code frontend
+4. **4 langues obligatoires** - FR, EN, IT, DE dans i18n
+5. **Permission path aligné** - `business.{app}.{module}.{action}`
+6. **Validation Phase 5 obligatoire** - Avant handoff
+
+---
+
+## UTILISATION CONTEXT7 (OBLIGATOIRE pour code)
+
+```
+╔══════════════════════════════════════════════════════════════════════════════╗
+║  CONTEXT7: Documentation à jour pour génération de code                      ║
+╠══════════════════════════════════════════════════════════════════════════════╣
+║                                                                              ║
+║  QUAND utiliser Context7:                                                    ║
+║  • Phase 7 (doc-html): Génération composants React                           ║
+║  • Templates React: Patterns actuels React 19                                ║
+║  • i18n: API react-i18next                                                   ║
+║  • Routing: React Router v7                                                  ║
+║                                                                              ║
+║  COMMENT utiliser:                                                           ║
+║  • Ajouter "use context7" dans les prompts de génération                     ║
+║  • Ou utiliser library ID: "/facebook/react", "/i18next/react-i18next"       ║
+║                                                                              ║
+║  EXEMPLE prompt phase 7:                                                     ║
+║  "use context7 with /facebook/react to generate a FRD documentation          ║
+║   page component following SmartStack patterns"                              ║
+║                                                                              ║
+╚══════════════════════════════════════════════════════════════════════════════╝
+```
+
+---
+
+## COMMANDES DISPONIBLES
+
+| Phase | Commande | Description |
+|-------|----------|-------------|
+| 1 | `/business-analyse:1-init` | Initialiser structure + valider contexte |
+| 2 | `/business-analyse:2-discover` | Elicitation besoins (ULTRATHINK) |
+| 3 | `/business-analyse:3-analyse` | Analyse métier BRD |
+| 4 | `/business-analyse:4-specify` | Spécifications FRD |
+| 5 | `/business-analyse:5-validate` | Gate validation utilisateur |
+| 6 | `/business-analyse:6-handoff` | Prompt développement |
+| 7 | `/business-analyse:7-doc-html` | Génération documentation React |
+| + | `/business-analyse:bug` | Documentation bug |
+| ⚡ | `/business-analyse:hotfix` | Fix urgent léger |
+| 🔄 | `/business-analyse:change-request` | Changement post-handoff |
+
+---
+
+## FICHIERS RÉFÉRENCE
+
+- **Templates FRD:** [templates-frd.md](templates-frd.md)
+- **Templates React:** [templates-react.md](templates-react.md)
+- **Questionnaire élicitation:** [questionnaire.md](questionnaire.md)
+- **Commande complète:** `.claude/commands/business-analyse.md`
+
+---
+
+## SUPPORT
+
+> **Questions sur la Business Analyse SmartStack?**
+>
+> 📧 **support@atlshub.ch**

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

@@ -0,0 +1,283 @@
+# Questionnaire Élicitation - Business Analyse
+
+> **Usage:** Questions structurées pour la phase 2-discover
+> **Standard:** BABOK v3 - Techniques d'élicitation
+> **Modèle:** OPUS avec ULTRATHINK
+
+---
+
+## RÈGLE ULTRATHINK
+
+```
+╔══════════════════════════════════════════════════════════════════════════════╗
+║  ULTRATHINK: Mode réflexion approfondie pour élicitation exhaustive          ║
+╠══════════════════════════════════════════════════════════════════════════════╣
+║                                                                              ║
+║  Pendant la phase discover, Claude DOIT:                                     ║
+║  • Considérer TOUS les edge cases avant de formuler une question             ║
+║  • Challenger CHAQUE hypothèse du stakeholder                                ║
+║  • Anticiper les besoins NON exprimés                                        ║
+║  • Valider la complétude avant de passer à la question suivante              ║
+║                                                                              ║
+║  NE PAS FAIRE:                                                               ║
+║  • Accepter des réponses vagues                                              ║
+║  • Sauter des catégories de questions                                        ║
+║  • Supposer que le stakeholder a pensé à tout                                ║
+║                                                                              ║
+╚══════════════════════════════════════════════════════════════════════════════╝
+```
+
+---
+
+## Catégorie 1: Contexte Business
+
+### 1.1 Besoin fondamental
+
+| # | Question | Type réponse |
+|---|----------|--------------|
+| Q1.1 | Quel problème business ce module/feature doit-il résoudre? | Texte libre |
+| Q1.2 | Quelle est la situation actuelle (AS-IS)? | Description |
+| Q1.3 | Quelle est la situation cible (TO-BE)? | Description |
+| Q1.4 | Quels sont les KPIs de succès mesurables? | Liste + valeurs |
+
+### 1.2 Valeur business
+
+| # | Question | Type réponse |
+|---|----------|--------------|
+| Q1.5 | Quel ROI attendez-vous? (temps, argent, efficacité) | Quantitatif |
+| Q1.6 | Quelles économies ou gains ce module apportera-t-il? | Estimation |
+| Q1.7 | Que se passe-t-il si ce module n'est PAS développé? | Impact |
+| Q1.8 | Quelle est la priorité par rapport aux autres besoins? | High/Medium/Low |
+
+---
+
+## Catégorie 2: Stakeholders
+
+### 2.1 Identification
+
+| # | Question | Type réponse |
+|---|----------|--------------|
+| Q2.1 | Qui sont les utilisateurs finaux directs? | Liste rôles |
+| Q2.2 | Qui sont les bénéficiaires indirects? | Liste |
+| Q2.3 | Qui est le sponsor/décideur final? | Nom + fonction |
+| Q2.4 | Qui peut bloquer le projet? | Liste + raisons |
+
+### 2.2 Besoins par rôle
+
+| # | Question | Type réponse |
+|---|----------|--------------|
+| Q2.5 | Pour chaque rôle: Quelles tâches doit-il accomplir? | Par rôle |
+| Q2.6 | Quelle fréquence d'utilisation par rôle? | Daily/Weekly/Monthly |
+| Q2.7 | Quel niveau d'expertise technique par rôle? | Novice/Intermédiaire/Expert |
+| Q2.8 | Quelles frustrations actuelles par rôle? | Liste pain points |
+
+---
+
+## Catégorie 3: Périmètre fonctionnel
+
+### 3.1 Fonctionnalités
+
+| # | Question | Type réponse |
+|---|----------|--------------|
+| Q3.1 | Listez les fonctionnalités ESSENTIELLES (Must-Have) | Liste |
+| Q3.2 | Listez les fonctionnalités SOUHAITÉES (Should-Have) | Liste |
+| Q3.3 | Listez les fonctionnalités OPTIONNELLES (Could-Have) | Liste |
+| Q3.4 | Qu'est-ce qui est EXPLICITEMENT exclu? | Liste exclusions |
+
+### 3.2 Processus métier
+
+| # | Question | Type réponse |
+|---|----------|--------------|
+| Q3.5 | Décrivez le flux principal de l'utilisateur | Étapes |
+| Q3.6 | Quels sont les points de décision dans le flux? | Liste |
+| Q3.7 | Quels flux alternatifs existent? | Par condition |
+| Q3.8 | Quels sont les cas d'erreur possibles? | Liste |
+
+---
+
+## Catégorie 4: Données
+
+### 4.1 Entités
+
+| # | Question | Type réponse |
+|---|----------|--------------|
+| Q4.1 | Quelles sont les entités principales manipulées? | Liste |
+| Q4.2 | Pour chaque entité: attributs importants? | Par entité |
+| Q4.3 | Quelles relations entre entités? | Schéma texte |
+| Q4.4 | Volume de données attendu? | Estimation |
+
+### 4.2 Règles de données
+
+| # | Question | Type réponse |
+|---|----------|--------------|
+| Q4.5 | Quelles validations sur les données? | Liste règles |
+| Q4.6 | Quels champs sont obligatoires vs optionnels? | Par champ |
+| Q4.7 | Quels formats/contraintes spécifiques? | Liste |
+| Q4.8 | Données sensibles à protéger? | Liste + niveau |
+
+---
+
+## Catégorie 5: Intégrations
+
+### 5.1 Systèmes existants
+
+| # | Question | Type réponse |
+|---|----------|--------------|
+| Q5.1 | Avec quels systèmes internes doit-on s'intégrer? | Liste |
+| Q5.2 | Avec quels systèmes externes? | Liste |
+| Q5.3 | APIs existantes à utiliser? | Documentation |
+| Q5.4 | Données à importer depuis autre système? | Liste + format |
+
+### 5.2 Flux de données
+
+| # | Question | Type réponse |
+|---|----------|--------------|
+| Q5.5 | Sens du flux? (entrée/sortie/bidirectionnel) | Par système |
+| Q5.6 | Fréquence de synchronisation? | Temps réel/Batch |
+| Q5.7 | Gestion des conflits de données? | Stratégie |
+| Q5.8 | Fallback si système externe indisponible? | Comportement |
+
+---
+
+## Catégorie 6: Sécurité & Permissions
+
+### 6.1 Accès
+
+| # | Question | Type réponse |
+|---|----------|--------------|
+| Q6.1 | Qui peut VOIR les données? | Liste rôles |
+| Q6.2 | Qui peut CRÉER des entrées? | Liste rôles |
+| Q6.3 | Qui peut MODIFIER? | Liste rôles |
+| Q6.4 | Qui peut SUPPRIMER? | Liste rôles |
+
+### 6.2 Restrictions
+
+| # | Question | Type réponse |
+|---|----------|--------------|
+| Q6.5 | Restrictions géographiques? | Pays/régions |
+| Q6.6 | Restrictions temporelles? (horaires, périodes) | Plages |
+| Q6.7 | Audit trail requis? Quelles actions? | Liste |
+| Q6.8 | Conformité réglementaire? (GDPR, etc.) | Liste normes |
+
+---
+
+## Catégorie 7: Interface utilisateur
+
+### 7.1 Expérience
+
+| # | Question | Type réponse |
+|---|----------|--------------|
+| Q7.1 | Devices cibles? (desktop, mobile, tablet) | Liste |
+| Q7.2 | Navigateurs à supporter? | Liste + versions |
+| Q7.3 | Accessibilité requise? (WCAG level) | A/AA/AAA |
+| Q7.4 | Mode sombre/clair requis? | Oui/Non |
+
+### 7.2 Écrans
+
+| # | Question | Type réponse |
+|---|----------|--------------|
+| Q7.5 | Écrans principaux nécessaires? | Liste |
+| Q7.6 | Maquettes/wireframes existants? | Documents |
+| Q7.7 | Informations clés par écran? | Par écran |
+| Q7.8 | Actions possibles par écran? | Par écran |
+
+---
+
+## Catégorie 8: Performance & Qualité
+
+### 8.1 Performance
+
+| # | Question | Type réponse |
+|---|----------|--------------|
+| Q8.1 | Temps de réponse acceptable? | Millisecondes |
+| Q8.2 | Nombre d'utilisateurs simultanés? | Estimation |
+| Q8.3 | Pics de charge attendus? | Quand + volume |
+| Q8.4 | Disponibilité requise? (SLA) | Pourcentage |
+
+### 8.2 Qualité
+
+| # | Question | Type réponse |
+|---|----------|--------------|
+| Q8.5 | Taux d'erreur acceptable? | Pourcentage |
+| Q8.6 | Tests spécifiques requis? | Types |
+| Q8.7 | Environnements de test disponibles? | Liste |
+| Q8.8 | Critères d'acceptation globaux? | Liste |
+
+---
+
+## Catégorie 9: Contraintes
+
+### 9.1 Techniques
+
+| # | Question | Type réponse |
+|---|----------|--------------|
+| Q9.1 | Stack technique imposée? | Technologies |
+| Q9.2 | Limites d'infrastructure? | Description |
+| Q9.3 | Dépendances technologiques? | Liste |
+| Q9.4 | Contraintes de compatibilité? | Liste |
+
+### 9.2 Organisationnelles
+
+| # | Question | Type réponse |
+|---|----------|--------------|
+| Q9.5 | Budget disponible? | Montant |
+| Q9.6 | Deadline fixe ou flexible? | Date + flexibilité |
+| Q9.7 | Ressources disponibles? | Équipe |
+| Q9.8 | Processus d'approbation? | Étapes |
+
+---
+
+## Catégorie 10: Documentation & Support
+
+### 10.1 Documentation
+
+| # | Question | Type réponse |
+|---|----------|--------------|
+| Q10.1 | Documentation utilisateur nécessaire? | Oui/Non + type |
+| Q10.2 | Documentation technique nécessaire? | Oui/Non + type |
+| Q10.3 | Formation des utilisateurs prévue? | Plan |
+| Q10.4 | Base de connaissances à créer? | Scope |
+
+### 10.2 Support
+
+| # | Question | Type réponse |
+|---|----------|--------------|
+| Q10.5 | Niveau de support attendu? | SLA |
+| Q10.6 | Qui assure le support niveau 1? | Équipe |
+| Q10.7 | Escalade vers niveau 2? | Processus |
+| Q10.8 | Monitoring et alertes requis? | Liste |
+
+---
+
+## Utilisation du questionnaire
+
+### Phase découverte
+
+1. **Début:** Commencer par Catégorie 1 (Contexte Business)
+2. **Adapter:** Sauter les questions non pertinentes au contexte
+3. **Approfondir:** Poser des questions de suivi sur les réponses vagues
+4. **Challenger:** Ne pas accepter "on verra plus tard" sur les Must-Have
+
+### Questions de suivi
+
+Pour chaque réponse vague, utiliser:
+- "Pouvez-vous donner un exemple concret?"
+- "Comment mesurez-vous cela aujourd'hui?"
+- "Que se passe-t-il si cette règle n'est pas respectée?"
+- "Qui est impacté par cette décision?"
+
+### Documentation
+
+Chaque réponse doit être documentée avec:
+- Source (qui a répondu)
+- Date
+- Niveau de confiance (Confirmé/À valider/Hypothèse)
+- Questions de suivi ouvertes
+
+---
+
+## Support
+
+> **Questions sur l'élicitation des besoins?**
+>
+> 📧 **support@atlshub.ch**