--- name: ba-modeling-inventory description: > Pass 1 of the optional Two-Pass fast-modeling path. In ONE fast pass, emit a lightweight inventory of ALL candidate use cases + business rules for a scope (application / module / section), each flagged `simple | moderate | complex` so a detail pass can route effort. Reads the `.smartstack/ba/` menu tree + actors for context and writes a planning checklist to `.smartstack/ba//_inventory.md`. Hands off to `/ba-modeling-detail`. allowed-tools: [Read, Write, Glob, Grep, Bash] # Bash: sources-search CLI (client sources) --- # ba-modeling-inventory — fast inventory of UCs + rules (Pass 1 of 2) You are running **Pass 1 of the optional Two-Pass BA modeling flow**. Instead of elaborating one section at a time conversationally (the default `/ba-create-use-case` → `/ba-create-business-rules` path), this fast path first **enumerates every candidate use case and business rule** for a scope in a single pass, flags each by complexity, and writes the list to a planning file. Pass 2 (`/ba-modeling-detail`) then expands the moderate/complex items into the real authoritative docs, while simple items can be written directly. Your job here is breadth, not depth: list everything modelable for the scope, give each item a one-line intent and an honest complexity flag — **no flows, no preconditions, no examples**. Those are Pass 2's work. ## File model — state lives in `.smartstack/ba/` (read first) There is **no Studio, no SQLite, no injected state block, no action/question envelope, no persistence step, no injected current-state block, no sidecar, no frontend, no i18n label codes**. Your state is the `.smartstack/ba/` markdown tree in the user's project (see `_workflow/ba-files.md`). You **Read** the tree to gather context and **Write** a single `.md` planning file with the Write tool. On every run: 1. **Read the menu tree**: `Glob .smartstack/ba/**/index.md` → the Application → Module → Section → Resource hierarchy (folders = the hierarchy; each `index.md` holds the node label + `## Contexte` + `## Hors-périmètre`). 2. **Read the scope's context**: the in-scope node's `index.md` (and its children's `index.md` when the scope is an app/module) for labels, context and out-of-scope boundaries. 3. **Read the app's actors**: `.smartstack/ba//acteur.md` — the ONLY source of valid `BA-…-AC-…` actor codes. Grep the `### BA-…-AC-…` headings for the available codes + labels. 4. **Read what already exists** (additive merge): the scope's authoritative `use-case.md` and `règles-métier.md` (and a prior `_inventory.md` if present), so you preserve codes that are already taken and don't re-propose items that already exist in detail. 5. **Write** the inventory to `.smartstack/ba//_inventory.md` (overwrite). If `.smartstack/ba/` is empty (no `index.md`), defer: tell the user to build the menu first via `/ba-create-menu`. If the app's `acteur.md` has no actors, defer to `/ba-create-actors` — every UC must reference a real actor; never invent one. ## Client sources (read + reference) If `.smartstack/sources/index.json` exists, read it and the in-scope `source.md` (by `scopes`/`tags`) before inventorying: client documents are the richest candidate mine. Tag a candidate drawn from a source with its code in the line (e.g. `… — SRC-001 §2`) so the detail pass carries the citation into the real `**Sources**` line. Never read `raw/` nor the whole corpus. ## Output — the inventory planning file Write to **`.smartstack/ba//_inventory.md`**, where `` is the folder path of the in-scope node (e.g. `CRM`, `CRM/PIPELINE`, or `CRM/PIPELINE/opportunites`). This file is a **planning artifact, not an authoritative doc** — it carries no `ba:node`/`ba:rollup` authority and is **overwritten on every run**. It does not replace `use-case.md` / `règles-métier.md`; Pass 2 produces those. Shape (content in the user's language; codes verbatim): ```markdown # Inventaire de modélisation — CRM / PIPELINE / opportunites _Pass 1 (rapide) · planning · à détailler via /ba-modeling-detail · régénéré à chaque passage_ ## Cas d'usage candidats | Item | Type | Intention (1 ligne) | Acteur principal | Complexité | |------|------|---------------------|------------------|------------| | UC-CRM-PIPELINE-OPPORTUNITES-001 | UC | Créer une opportunité depuis un prospect | BA-001-AC-001 (Commercial) | simple | | UC-CRM-PIPELINE-OPPORTUNITES-002 | UC | Faire valider une remise > 20 % par le manager | BA-001-AC-002 (Manager) | complex | ## Règles métier candidates | Item | Type | Intention (1 ligne) | Portée | Complexité | |------|------|---------------------|--------|------------| | BR-001 | BR | Remise > 20 % exige l'aval manager | CRM / PIPELINE | moderate | | BR-002 | BR | L'email d'un contact est unique par compte | CRM / PIPELINE | simple | ``` Rules for the file: - One `## Cas d'usage candidats` table and one `## Règles métier candidates` table. An empty scope is fine — keep the heading and write `_(aucun cas d'usage modélisable pour l'instant)_` under it. - **Item** is the code (see formats below). **Type** is literally `UC` or `BR`. **Intention** is ONE short line (`verb + object`, ~3-7 words) matching the actor's mental model. **Complexité** is exactly one of `simple | moderate | complex`. - For UCs, name the **Acteur principal** by its verbatim `BA-…-AC-…` code + label. For rules, give the **Portée** as the node path the rule attaches to (`CRM / PIPELINE` or `… / opportunites`). - The anchor first line is `` — a planning marker, deliberately NOT one of the authoritative `kind=` values, so audits and `create-prd` skip it. ## Code formats (match the authoritative docs verbatim) These are the **native** formats the detail pass and the audits expect — copy them, never compose or translate (see `_workflow/code-discipline.md`): - **Use case** — `UC-{APP}-{MOD}-{SEC}-NNN`, where `{APP}`/`{MOD}` are the UPPERCASE app/module folder codes and `{SEC}` is the section folder code UPPERCASED with `-` → `_` (folder `exchange-history` → `EXCHANGE_HISTORY`, `opportunites` → `OPPORTUNITES`). `NNN` is a zero-padded 3-digit counter **scoped to the section**, restarting at `001` per section. - **Business rule** — `BR-{NNN}`, a 3-digit counter **scoped to the doc** (the rule's deepest declared scope). The number, never the title, is the identity. Before numbering, **Grep** the scope's existing `use-case.md` / `règles-métier.md` headings (and any prior `_inventory.md`) for the highest taken number and increment. Preserve any code that already exists — this is an additive merge, so a re-run keeps prior codes stable and only appends new candidates. > Note: this differs from the legacy Studio scheme that namespaced rule codes per > section (`BR----NNN`). Native BA uses the simpler `BR-{NNN}` > scoped to the owning doc — match the authoritative `règles-métier.md`. ## Complexity taxonomy (critical — drives Pass 2 effort routing) - **simple** → CRUD-shaped UCs, trivial validations (unique, required, format), one actor, one entity, no cross-entity impact. Pass 2 can write these directly with little elaboration. - **moderate** → multi-step flows (≥3 steps), 2+ actors, single aggregate, conditional branches. Pass 2 elaborates the full flow / examples. - **complex** → multi-entity impact, state machines, approvals / workflows, temporal constraints, externally-triggered side effects, audit trails. Pass 2 spends the most effort here. Be **honest** with the flags. A mis-flagged `simple` that is really `complex` yields a shallow detail pass; a mis-flagged `complex` wastes effort on a trivial flow. When in doubt, flag `moderate`. ## Hard rules - Read the tree first; **Write exactly one file** (`_inventory.md` for the scope). No conversational back-and-forth is required for Pass 1 — it is a fast enumeration. (You may ask one closed scope-clarifying question if the user's scope is ambiguous, but the default is: infer the scope and produce the file.) - Include **all** relevant UCs + rules for the scope. An empty scope is valid — write the headings with an `_(aucun …)_` note. - Every UC must reference an **existing** actor from `/acteur.md`. Never invent an actor — that belongs to `/ba-create-actors`. - **No flows, no preconditions, no examples, no expressions, no diagrams.** The inventory is SHALLOW by design — Pass 2 fills those in for the flagged items. - Never invent a UC, rule, actor, section, module or app code. Copy actor codes from `acteur.md`, node codes from the folder names; if something is missing, defer to its owner phase (`/ba-create-menu`, `/ba-create-actors`). - Never switch languages mid-scope — write the file in the user's language; this SKILL.md stays English. ## After writing → hand off to the detail pass Acknowledge in one line ("Inventaire `opportunites` — 6 cas d'usage, 4 règles.") and tell the user the next step: **`/ba-modeling-detail`** expands each **moderate** and **complex** item into the real authoritative docs (`use-case.md` / `règles-métier.md`), one item per call; **simple** items can be written directly via `/ba-create-use-case` / `/ba-create-business-rules` without further elaboration. The `_inventory.md` is the checklist driving that pass; it is regenerated, not edited by hand. ## Talking to the user Speak like a business analyst, not a tool. Don't surface skill names, file paths, anchors, or the `.smartstack/ba/` layout to the end user — talk about "the menu", "the actors", "the use cases and rules for this scope". The `/ba-*` references in this file are for your own routing.