gg-skill-dep-tree

GG-SKILL-DEP-TREE — Codebase Dependency Tree + Physical Data Model

Produce a readable indented dependency tree grouped by domain, showing what each module uses, triggers, or depends on. Optionally includes a UML-like Physical Data Model (MPD) extracted from migrations/schema files.

Two use cases:

1. Documentation — global map of codebase architecture
2. Pre-feature orientation — highlight impacted modules, integration points, and risk zones before writing code

Output language: French for relationship labels; English for module/component names (as they appear in code).

---

Mode Detection

Mode -u / -update — called automatically by gg-skill-phase at end of phase execution, or manually after any code change:

• Do NOT regenerate the full tree
• Read dep-tree.md, identify its Last updated header
• Inspect only files modified during the phase (git diff --name-only since last dep-tree update)
• Re-analyze only affected modules and their direct neighbors
• Update the relevant sections in dep-tree.md in place
• Update the freshness header
• Append a ## Changelog entry at the bottom:

### Phase N — {date}
- [ModuleX] nouvelle dépendance → ServiceY ajoutée
- [ModuleZ] relation modifiée : utilise → déclenche
- [NewModule] ajouté, dépend de Database + Auth

Feature Mode — if a target is specified (e.g. add payment module):

• Produce the full tree, then add a dedicated section highlighting:
  • Which existing modules will be directly impacted
  • Where the new feature should plug in (integration points)
  • Which dependencies it will inherit or create
  • Risk zones (modules with high coupling that the feature touches)

Full generation — no flag and no target: produce the complete tree from scratch.

---

Step 1 — Project Detection

Identify:

• Project type (React, Vue, Laravel, Symfony, Node, Python, etc.)
• Entry points (main files, routes, index files)
• Architecture style (feature-based, layer-based, monolith, etc.)

Read: package.json, composer.json, pyproject.toml, or equivalent. Scan: src/, app/, lib/, components/, modules/, services/ — whatever exists.

---

Step 2 — Domain Grouping

Identify the top-level domains (3–10 max):

• Feature modules (Auth, Dashboard, Users, API...)
• Infrastructure layers (Database, Cache, Queue, Storage...)
• Shared services (Router, EventBus, Logger, Config...)

Each domain becomes a root node in the tree.

---

Step 3 — Dependency Mapping

For each domain, identify its children (sub-components, services, hooks, controllers...).

For each node, determine the relationship type using these labels:

Label	Meaning
→ utilise	direct import / dependency
→ dépend de	requires another module to function
→ déclenche	emits event / calls callback
→ modifie	writes to / mutates state or data
→ exposé par	provided by parent / injected
→ utilisé par	reverse dependency (consumed elsewhere)

Use actual imports, function calls, and event listeners — not guesswork.

---

Step 4 — Output Format

Render the tree using box-drawing characters:

DomainName → [optional: dépend de OtherDomain]
├─ SubComponent → utilise ServiceA + ServiceB
│  ├─ ChildComponent → modifie SubComponent state
│  └─ onEventName → déclenche DomainB + DomainC
└─ OtherSub → utilisé par 4 modules

Rules:

• ├─ for non-last children, └─ for last child, │ for continuation lines
• Max depth: 3 levels (domain → component → sub-element)
• If deeper: collapse with [+N éléments]
• Cross-cutting concerns (Database, Logger, etc.) listed last with usage count

---

Step 5 — Relation Summary

After the tree, add a compact relation index:

DÉPENDANCES CROISÉES
─────────────────────
Database     ← utilisé par 6 modules
EventBus     ← utilisé par 4 modules
AuthService  ← utilisé par Dashboard, Profile, Admin

---

Step 6 — Physical Data Model (MPD)

If the project has a database layer (migrations, schema files, ORM models), generate a UML-like MPD section in dep-tree.md.

See references/mpd-extraction.md for full extraction rules, output format, and FK notation.

Source priority:

1. Laravel — database/migrations/*.php
2. Symfony/Doctrine — src/Entity/*.php
3. Prisma — prisma/schema.prisma
4. Raw SQL — *.sql files
5. Eloquent models — supplement migrations only, do not replace

Mode -u behavior: re-read only migrations newer than Last updated date. Add/modify only affected table blocks. Do not regenerate the full MPD.

If no database layer found: skip this step silently.

---

Output Rules

• Write result to dep-tree.md at the project root
• Do NOT print the tree in chat — only confirm the file was written and its path
• Plain text inside the file, monospace-friendly, wrapped in a fenced code block
• No markdown headers inside the tree itself
• French labels, English module/component names
• If codebase is too large: ask user to specify a subdirectory or feature scope
• If architecture is unclear: state the ambiguity, propose 2 grouping options

Freshness header — always present at the top of dep-tree.md:

> dep-tree.md — Last updated: {ISO date} | Phase: {N} | Mode: full|update
> Stale if: current phase > {N} and dep-tree not updated after phase {N} close

---

Failure Modes to Avoid

• Do NOT invent relationships not found in the code
• Do NOT group by file type (no "all controllers together") — group by domain/feature
• Do NOT show every file — synthesize at the component/service level
• Do NOT produce a flat list — the tree structure is the entire point

---

Example Output

Authentication
├─ LoginFlow → utilise AuthService + Router
│  ├─ OAuthProvider → utilisé par LoginFlow
│  └─ SessionManager → utilisé par Login + Dashboard
└─ onAuthStateChange → déclenche Dashboard + Notifications

Dashboard → dépend de Authentication
├─ ClientList → utilise Database + SearchService
│  ├─ Filters → modifie ClientList
│  └─ onClientSelect → déclenche ClientDetail
└─ ClientDetail → utilise Database + API

Database — Supabase → utilisé par 6 modules

---

Workflow Position

gg-skill-dep-tree   ← you are here (init or update)
    ↓
gg-skill-phase      (auto-calls dep-tree -u after each phase)
    ↓
gg-skill-recette