Pipeline Business Analyse — 32 skillsBusiness Analysis pipeline — 32 skills
SmartStack v5 introduit un pipeline d'analyse métier complet, basé sur des fichiers markdown sous .smartstack/ba/. Aucune base de données, aucune dépendance MCP, aucun envelope JSON : tout est lisible, diff-able et committable.
SmartStack v5 ships a complete business analysis pipeline backed by markdown files under .smartstack/ba/. No database, no MCP dependency, no JSON envelopes: everything is readable, diff-able and committable.
Pipeline en un coup d'œilPipeline at a glance
7 phases métier + 1 synthèse PRD, chacune vérifiée par son audit dédié avant la suivante ; l'audit final /ba-audit-prd émet le verdict GO / NO-GO (score ≥ 80) qui débloque (ou bloque) /ba-develop. Deux phases d'organisation encadrent le tout : la phase 1.5 (/ba-create-ba-order) ordonne les modules, et la phase 0.5 (/ba-reconcile-menu) réconcilie les documents quand le menu a été modifié après coup. En pratique, les phases 2 → 7 se pilotent par /ba-loop, l'orchestrateur autonome.
7 business phases + 1 PRD synthesis, each verified by its dedicated audit before the next; the final /ba-audit-prd audit emits the GO / NO-GO verdict (score ≥ 80) that unblocks (or blocks) /ba-develop. Two organisational phases frame the whole: phase 1.5 (/ba-create-ba-order) orders the modules, and phase 0.5 (/ba-reconcile-menu) reconciles the documents when the menu changed afterwards. In practice, phases 2 → 7 are driven through /ba-loop, the autonomous orchestrator.
Modèle de fichiersFile model
Tout le pipeline écrit sous .smartstack/ba/. Chaque niveau de la hiérarchie a un fichier autoritaire dédié :
The whole pipeline writes under .smartstack/ba/. Each level of the hierarchy owns a dedicated authoritative file:
| NiveauLevel | Chemin typeTypical path | FichiersFiles |
|---|---|---|
| ProjetProject | .smartstack/ba/ |
racine, audits transversesroot, cross-cutting audits |
| ApplicationApplication | .smartstack/ba/<APP>/ |
index.md, acteur.md |
| ModuleModule | .smartstack/ba/<APP>/<MODULE>/ |
index.md, entité.md, rbac.md, prd.md |
| SectionSection | .smartstack/ba/<APP>/<MODULE>/<SECTION>/ |
index.md, use-case.md, règles-métier.md, screen.md |
Phases du pipelinePipeline phases
Chaque phase « define / generate » est immédiatement vérifiable par son audit dédié — la colonne de droite. L'audit écrit un verdict sous _audit/<dimension>.md que vous relisez avant de passer à la phase suivante. Depuis la 5.18, les règles mécaniques de ces audits sont évaluées par le moteur déterministe /ba-audit-run — les skills d'audit ne gardent que le jugement métier.
Each define/generate phase is immediately verifiable through its dedicated audit — the right-hand column. The audit writes a verdict under _audit/<dimension>.md that you review before moving to the next phase. Since 5.18, the mechanical rules of these audits are evaluated by the deterministic /ba-audit-run engine — the audit skills keep only the business judgment.
| Phase | Skill | ÉcritWrites | AuditAudit |
|---|---|---|---|
| 1 — MenuMenu | /ba-create-menu |
arbre index.mdindex.md tree |
/ba-audit-menu + /ba-audit-sections |
| 2 — ActeursActors | /ba-create-actors |
acteur.md |
/ba-audit-actors |
| 3 — Cas d'usageUse cases | /ba-create-use-case |
use-case.md |
/ba-audit-use-cases |
| 4 — Règles métierBusiness rules | /ba-create-business-rules |
règles-métier.md |
/ba-audit-rules |
| 5 — RBAC | /ba-create-rbac |
rbac.md |
/ba-audit-rbac |
| 6 — Modèle de donnéesData model | /ba-create-data-model |
entité.md |
/ba-audit-data-model + /ba-audit-cross-ref-code |
| 6.5 — Jeu de test (optionnel)Test dataset (optional) | /ba-create-test-data |
jeu-de-test.md (5-8 lignes fictives par entité métier, validées par le client — le second palier de seed : dev/test/qual, jamais prod)(5-8 fictitious rows per business entity, validated by the client — the second seed tier: dev/test/qual, never prod) |
/ba-audit-data-model (DM-029..032 : présent, cohérent avec le MCD et les modules cités, jamais sur un référentiel, chaque statut de Flow porté)(DM-029..032: present, coherent with the MCD and the cited modules, never on a reference table, every Flow status carried) |
| 7 — ÉcransScreens | /ba-create-screen |
screen.md (actions CRUD + custom)(CRUD + custom actions) |
/ba-audit-screens (SCR-001..025, dont la structure des actions custom et les onglets liés de la vue 360)(SCR-001..025, incl. custom-action structure and the 360 view's related tabs) |
| SynthèseSynthesis | /ba-create-prd |
prd.md + 3 slices + pagespecs/*.md |
/ba-audit-prd (PRD-001..136, porte GO/NO-GO score ≥ 80 ; couvre notamment le contrat custom-action, l'élégance des listes, les sections de formulaire et le cycle de vie)(PRD-001..136, GO/NO-GO gate score ≥ 80; covers the custom-action contract, list elegance, form sections and lifecycle among others) |
ℹ️ Les User Stories et critères d'acceptation ne sont pas dans le PRD : les critères d'acceptation vivent sous chaque cas d'usage dans use-case.md — c'est là que le scaffolder de tests les lit (un test [Fact] par critère).
ℹ️ User Stories and acceptance criteria are NOT in the PRD: acceptance criteria live under each use case in use-case.md — that is where the test scaffolder reads them (one [Fact] test per criterion).
Comment se déroule un échange — la méthode 3 paliersHow an exchange works — the 3-tier method
Chaque phase create est conversationnelle et suit la même méthode : le skill recherche le domaine, rédige un brouillon interne, l'auto-audite, puis vous présente sa proposition en 3 paliers : Each create phase is conversational and follows the same method: the skill researches the domain, drafts internally, self-audits the draft, then presents its proposal in 3 tiers:
| PalierTier | SensMeaning |
|---|---|
| ObligatoireMandatory | Le socle sans lequel le périmètre ne fonctionne pas — à valider tel quel ou à amenderThe base without which the scope does not work — validate as-is or amend |
| SuggestionSuggestion | Ce que la pratique du domaine recommande — à retenir ou écarter cas par casWhat domain practice recommends — keep or discard case by case |
| ÉlargissementExtension | Les extensions possibles du périmètre — pour décider en connaissance de cause, sans obligationPossible scope extensions — informed decisions, no obligation |
Vous validez (ou corrigez), puis le skill écrit les fichiers. Rien n'est écrit sans votre accord. You validate (or correct), then the skill writes the files. Nothing is written without your approval.
/ba-loop — le mode autonome/ba-loop — the autonomous mode
/ba-loop est le mode d'emploi principal des phases 2 → 7 : il enchaîne acteurs → cas d'usage → règles → RBAC → modèle de données → écrans, module par module dans l'ordre des vagues (lu depuis _plan/ba-order.json), chaque phase tournant en sous-agent avec le cycle créer → auditer → corriger. Si le menu a été modifié après la création de contenu, il lance automatiquement /ba-reconcile-menu (phase 0.5) avant de démarrer.
/ba-loop is the primary way to run phases 2 → 7: it chains actors → use cases → rules → RBAC → data model → screens, module by module in wave order (read from _plan/ba-order.json), each phase running as a sub-agent with the create → audit → fix cycle. If the menu was modified after content was created, it automatically runs /ba-reconcile-menu (phase 0.5) before starting.
/ba-create-menu → /ba-create-ba-order → /ba-loop → /ba-audit-pre-dev (GO)
(phase 1) (phase 1.5) (2 → 7) ↓
/ba-create-prd + /ba-audit-prd (GO ≥ 80)
↓
/ba-create-plan-development → /ba-develop
Ordonnancement et multi-modulesOrdering and multi-module work
/ba-create-ba-order(phase 1.5) — tri topologique des modules selon leurs dépendances →_plan/ba-order.md+.json: l'ordre dans lequel travailler les phases BA(phase 1.5) — topological sort of the modules by dependency →_plan/ba-order.md+.json: the order in which to work the BA phases/ba-create-plan-development— après les audits, ordonne les modules en vagues de développement parallèles →_plan/dev-plan.md+.json, consommé par/ba-develop-plan— after the audits, orders the modules into parallel development waves →_plan/dev-plan.md+.json, consumed by/ba-develop-plan
Maintenance du référentiel BAMaintaining the BA tree
/ba-reconcile-menu(phase 0.5) — le menu a été renommé/élagué APRÈS la création de contenu ? Ce skill détecte les renommages et suppressions, vous montre le diff, puis réécrit les documents aval (codes UC/SCR/BR/RBAC, blocs orphelins). Idempotent.(phase 0.5) — menu renamed/pruned AFTER content was created? This skill detects renames and deletions, shows you the diff, then rewrites the downstream documents (UC/SCR/BR/RBAC codes, stranded blocks). Idempotent./ba-translate-prd— un PRD existant contient des placeholders[en]/[it]/[de]non traduits ? Ce skill les remplace par de vraies traductions depuis le français autoritaire, puis vous re-scaffoldez le frontend.— an existing PRD carries untranslated[en]/[it]/[de]placeholders? This skill replaces them with real translations from the authoritative French, then you re-scaffold the frontend.
Actions custom — comment les déclarerCustom actions — how to declare them
À côté des actions CRUD standard (create / read / list / edit / delete), un écran peut exposer des actions custom métier — un bouton « Synchroniser depuis PCE », un bouton « Ouvrir l'historique ». La déclaration se fait dans screen.md sous forme de bullet structurée :
Alongside standard CRUD actions (create / read / list / edit / delete), a screen can expose custom business actions — a "Sync from PCE" button, an "Open history" button. The declaration is a structured bullet in screen.md:
- **Actions personnalisées** :
- `syncFromPce` — kind: api, scope: header, endpoint: sync-from-proconcept,
httpMethod: POST, permission: referentiels.types-affaire.execute,
UC: UC-APP-REF-TYPEAFFAIRE-007, label: « Synchroniser depuis PCE »
- `openHistory` — kind: navigate, scope: row,
targetScreen: SCR-APP-HIST-001, permission: referentiels.types-affaire.read,
label: « Ouvrir l'historique »
Deux discriminateurs kind :
Two kind discriminators:
kind |
Sémantique métierBusiness semantics | Champs requisRequired fields |
|---|---|---|
api |
Action qui déclenche une opération côté serveur (lecture, écriture, calcul…)Action triggering a server-side operation (read, write, computation…) | endpoint, httpMethod, permission, UC |
navigate |
Action qui ouvre un autre écran (navigation pure, pas d'appel serveur)Action opening another screen (pure navigation, no server call) | targetScreen, permission |
Le champ endpoint est traité comme la source de vérité par le pipeline en aval — la déclaration BA est ainsi le seul endroit à modifier quand on renomme l'action.
The endpoint field is treated as the source of truth by the downstream pipeline — the BA declaration is the single place to edit when an action is renamed.
Les audits BA /ba-audit-screens et /ba-audit-prd vérifient que la déclaration est complète, que l'endpoint est unique par entité, que le targetScreen est résoluble et que le contrat est valide. Une action de type fichier (type: file) est refusée : les pièces jointes passent par le pattern attachments de la plateforme.
The BA audits /ba-audit-screens and /ba-audit-prd verify that the declaration is complete, the endpoint is unique per entity, the targetScreen is resolvable, and the contract is valid. A file-typed action (type: file) is refused: attachments go through the platform's attachments pattern.
/ba-audit-run — le moteur d'audit déterministe/ba-audit-run — the deterministic audit engine
Historiquement, chaque audit était rendu par un agent LLM qui relisait le corpus et appliquait les règles « à l'œil ». Sur un vrai projet (4 apps, 20 modules, 3,2 Mo de markdown), une campagne complète a coûté 394 millions de tokens — pour des règles à ~80 % mécaniques (existence, référence, comptage, parité, nommage). Le CLI audit-ba remplace ce mode : une seule exécution charge tout le corpus en mémoire, évalue les ~113 règles mécaniques des 10 dimensions, écrit tous les verdicts _audit/<dim>.md (au format existant) plus le rapport machine _audit/audit-ba.json, et publie les totaux de parsing (UC, critères, règles, codes d'erreur, entités, écrans lus) — la seule façon de vérifier qu'un « 0 erreur » porte sur quelque chose.
Historically each audit was rendered by an LLM agent re-reading the corpus and applying the rules "by eye". On a real project (4 apps, 20 modules, 3.2 MB of markdown), one full campaign cost 394 million tokens — for rules that are ~80% mechanical (existence, reference, counting, parity, naming). The audit-ba CLI replaces that mode: one execution loads the whole corpus in memory, evaluates the ~113 mechanical rules of all 10 dimensions, writes every _audit/<dim>.md verdict (existing format) plus the machine record _audit/audit-ba.json, and publishes the parse totals (UCs, criteria, rules, error codes, entities, screens actually read) — the only way a "0 errors" verdict stays verifiable.
npx --prefer-offline tsx skills/ba-audit-run/cli/audit-ba/index.ts \
--spec '{"baRoot":".smartstack/ba","projectRoot":"."}'
| PropriétéProperty | ComportementBehaviour |
|---|---|
| Fail-closedFail-closed | Des comptages de contrôle indépendants sont comparés aux totaux parsés : un document que le parseur ne lit pas (0 parsé alors que le contrôle en voit) = exit 3 « parsing suspect », jamais « 0 finding ». Aucun verdict vert ne peut naître d'un parseur muet.Independent control counts are reconciled against the parsed totals: a document the parser fails to read (0 parsed while the control sees items) = exit 3 "parsing suspect", never "0 findings". No green verdict can be born from a silent parser. |
| JugementJudgment | Les 9 règles sémantiques (périmètre métier, similarités cross-app…) sortent en judgmentNeeded[] — question + extraits compacts (≤ 2 Ko), jamais un fichier entier. Le skill arbitre et renvoie ses décisions via --judgments ; le CLI réécrit les verdicts.The 9 semantic rules (business scope, cross-app similarity…) come out as judgmentNeeded[] — question + compact excerpts (≤ 2 KB), never a whole file. The skill arbitrates and returns decisions via --judgments; the CLI rewrites the verdicts. |
| Conventions projetProject conventions | Une convention massive mesurée dans le corpus (≥ 90 % — p. ex. segments de section en minuscules, codes d'erreur en kebab plat) devient UN warn de portée projet (CONV-001/002), jamais une erreur par occurrence. --strict restaure la lettre des règles.A massive convention measured in the corpus (≥ 90% — e.g. lowercase section segments, flat-kebab error codes) becomes ONE project-scoped warn (CONV-001/002), never an error per occurrence. --strict restores the letter of the rules. |
| FraîcheurFreshness | Chaque verdict porte ruleset= + sources= (hash) dans son ancre : un verdict rendu sous un ancien jeu de règles ou sur des sources modifiées est détectable. Après chaque mise à jour des skills (ss install), relancez l'audit — il coûte une minute, le delta EST la liste de mise à niveau.Every verdict carries ruleset= + sources= (hash) in its anchor: a verdict rendered under an older ruleset or on since-modified sources is detectable. After every skills update (ss install), re-run the audit — it costs a minute, the delta IS the upgrade list. |
| Exit codesExit codes | 0 conforme · 1 avertissements · 2 bloquants · 3 parsing suspect · 4 usage0 compliant · 1 warnings · 2 blockers · 3 parsing suspect · 4 usage |
Les skills /ba-audit- restent les points d'entrée par dimension : ils invoquent ce moteur scopé ("dimensions":["use-cases"]…), arbitrent le jugement de leur dimension, et n'appliquent plus jamais une règle mécanique à la main. Le hook ba-audit-guard (voir Hooks) bloque toute tentative de relancer l'ancienne campagne par agents.
The /ba-audit- skills remain the per-dimension entry points: they invoke this engine scoped ("dimensions":["use-cases"]…), arbitrate their dimension's judgment, and never apply a mechanical rule by hand again. The ba-audit-guard hook (see Hooks) blocks any attempt to relaunch the old agent campaign.
Audits transversesCross-cutting audits
Au-delà des audits par phase ci-dessus, trois entrées vérifient la cohérence globale : Beyond the per-phase audits above, three entries verify the overall coherence:
/ba-audit-run— le moteur déterministe ci-dessus : toutes les dimensions du projet en une passe (1 minute)the deterministic engine above: every dimension of the whole project in one pass (1 minute)/ba-audit-cross-dimension— cohérence inter-dimensions (un champ d'état est-il bien couvert par une règle, un UC et un écran ?)cross-dimension coherence (is a state field properly covered by a rule, a UC and a screen?)/ba-audit-pre-dev— orchestrateur lecture-seule : agrège tous les verdicts_audit/.mdet émet un GO/NO-GO projetread-only orchestrator: aggregates every_audit/.mdverdict and emits a project-level GO/NO-GO
Modélisation rapide (optionnel)Fast modelling (optional)
Pour les modules grands, le passage en deux étapes accélère l'inventaire : For large modules, the two-pass approach speeds up the inventory:
/ba-modeling-inventory— pass 1 : listing rapide de tous les UC + règles avec un flag simple/moderate/complexpass 1: fast listing of all UCs + rules tagged simple/moderate/complex/ba-modeling-detail— pass 2 : expansion d'un itempass 2: expand a single item
Quand la phase de synthèse a écrit le PRD et que l'audit a renvoyé GO, l'analyse métier est terminée. Le passage au code se fait via /ba-develop, documenté sur sa page dédiée.
When the synthesis phase has written the PRD and the audit returned GO, business analysis is done. Hand-off to code is documented on the dedicated /ba-develop page.
Dans quel cas ?Which situation, which command?
| Je suis dans ce cas…I am in this situation… | …alors je fais…then I do |
|---|---|
| Je démarre un nouveau projet, page blancheI start a new project from scratch | /ba-create-menu puis /ba-create-ba-order puis /ba-loop/ba-create-menu then /ba-create-ba-order then /ba-loop |
| Je veux travailler UNE phase à la main (p. ex. affiner les règles)I want to work ONE phase by hand (e.g. refine the rules) | le skill de la phase, p. ex. /ba-create-business-rules, puis son auditthat phase's skill, e.g. /ba-create-business-rules, then its audit |
| J'ai renommé/supprimé des sections du menu après coupI renamed/deleted menu sections afterwards | /ba-reconcile-menu |
| Je veux ajouter ou modifier un seul élément après coup (un cas d'usage oublié, une règle, un acteur, une permission, un attribut, une entité, un écran) sans relancer une phase entièreI want to add or modify one element after the fact (a forgotten use case, a rule, an actor, a permission, an attribute, an entity, a screen) without re-running a whole phase | /ba-change — alloue le prochain code, déroule la checklist aval (règles, RBAC, écran, pagespec), vérifie la réécriture, puis /ba-develop sans --force/ba-change — allocates the next code, walks the downstream checklist (rules, RBAC, screen, pagespec), verifies the re-Write, then /ba-develop without --force |
| Le module est très grand, l'inventaire traîneThe module is huge, the inventory drags | /ba-modeling-inventory puis /ba-modeling-detail item par item/ba-modeling-inventory then /ba-modeling-detail item by item |
| Je veux savoir si le projet est prêt pour le devI want to know whether the project is dev-ready | /ba-audit-pre-dev — agrège tous les verdicts, GO/NO-GO projet/ba-audit-pre-dev — aggregates every verdict, project GO/NO-GO |
| L'analyse est finie, je veux le PRDAnalysis is done, I want the PRD | /ba-create-prd puis /ba-audit-prd (GO ≥ 80 requis pour /ba-develop)/ba-create-prd then /ba-audit-prd (GO ≥ 80 required for /ba-develop) |
Le PRD affiche des libellés [en] … non traduitsThe PRD shows untranslated [en] … labels |
/ba-translate-prd |
| Plusieurs modules interdépendants à développerSeveral interdependent modules to develop | /ba-create-plan-development puis /ba-develop-plan/ba-create-plan-development then /ba-develop-plan |
L'annuaire des 32 skills BA (avec leur fiche détaillée) est sur la page Skills BA dans l'Annuaire. The directory of the 32 BA skills (with their full cards) lives on the BA Skills page in the Directory.