---
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/<scope>/_inventory.md`. Hands off to `/ba-modeling-detail`.
allowed-tools: [Read, Write, Glob, Grep]
---

# 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/<APP>/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/<scope>/_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.

## Output — the inventory planning file

Write to **`.smartstack/ba/<scope>/_inventory.md`**, where `<scope>` 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
<!-- ba:inventory scope=CRM/PIPELINE/opportunites -->
# 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 `<!-- ba:inventory scope=<path> -->` — 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-<APP>-<MOD>-<SEC>-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 `<APP>/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.
