Communitygithub.com

deepinit

Initialisation profonde de codebase avec génération hiérarchique de documentation AGENTS.md

Qu'est-ce que deepinit ?

deepinit est un skill conçu pour les agents IA (comme Claude Code, Cursor ou Codex) qui génère automatiquement une documentation hiérarchique AGENTS.md sur l'ensemble d'un codebase. Chaque fichier AGENTS.md agit comme une fiche « lisible par l'IA » décrivant le rôle d'un répertoire, ses fichiers clés, ses sous-répertoires, les instructions pour les agents, les dépendances internes/externes et les conventions de code. Un système de balisage hiérarchique (via <!-- Parent: ../AGENTS.md -->) permet de créer un arbre de navigation complet, de la racine aux sous-répertoires les plus profonds. Le skill automatise l'exploration de l'arborescence, l'analyse des fichiers, la génération de contenu par niveau (parents d'abord, enfants ensuite), et la validation des références. Il gère intelligemment la mise à jour des fichiers existants en préservant les sections manuelles, et optimise les performances via la parallélisation par niveau et le cache des listings de répertoires. deepinit est particulièrement utile pour les codebases complexes où plusieurs agents IA collaborent, car il leur donne une compréhension contextuelle précise sans avoir à explorer manuellement chaque dossier.

Compatible avec~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/Yeachan-Heo/oh-my-claudecode/tree/main/skills/deepinit

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

Documentation

Skill Deep Init

Crée une documentation hiérarchique complète AGENTS.md sur l'ensemble du codebase.

Concept central

Les fichiers AGENTS.md servent de documentation lisible par l'IA qui aide les agents à comprendre :

  • Ce que contient chaque répertoire
  • Comment les composants sont liés entre eux
  • Instructions spéciales pour travailler dans cette zone
  • Dépendances et relations

Système de balisage hiérarchique

Chaque AGENTS.md (sauf la racine) inclut une balise de référence parent :

<!-- Parent: ../AGENTS.md -->

Cela crée une hiérarchie navigable :

/AGENTS.md                          ← Racine (pas de balise parent)
├── src/AGENTS.md                   ← <!-- Parent: ../AGENTS.md -->
│   ├── src/components/AGENTS.md    ← <!-- Parent: ../AGENTS.md -->
│   └── src/utils/AGENTS.md         ← <!-- Parent: ../AGENTS.md -->
└── docs/AGENTS.md                  ← <!-- Parent: ../AGENTS.md -->

Modèle AGENTS.md

<!-- Parent: {chemin_relatif_parent}/AGENTS.md -->
<!-- Généré: {horodatage} | Mis à jour: {horodatage} -->

# {Nom du répertoire}

## Objectif
{Description d'un paragraphe de ce que contient ce répertoire et son rôle}

## Fichiers clés
{Liste chaque fichier important avec une description d'une ligne}

| Fichier | Description |
|---------|-------------|
| `file.ts` | Brève description de l'objectif |

## Sous-répertoires
{Liste chaque sous-répertoire avec un bref objectif}

| Répertoire | Objectif |
|------------|----------|
| `subdir/` | Ce qu'il contient (voir `subdir/AGENTS.md`) |

## Pour les agents IA

### Travailler dans ce répertoire
{Instructions spéciales pour les agents IA modifiant des fichiers ici}

### Exigences de test
{Comment tester les changements dans ce répertoire}

### Schémas courants
{Schémas de code ou conventions utilisés ici}

## Dépendances

### Internes
{Références à d'autres parties du codebase dont cela dépend}

### Externes
{Principaux paquets/bibliothèques externes utilisés}

<!-- MANUAL: Toute note ajoutée manuellement en dessous de cette ligne est conservée lors de la régénération -->

Flux d'exécution

Étape 1 : Cartographier la structure des répertoires

Task(subagent_type="explore", model="haiku",
  prompt="Lister tous les répertoires de manière récursive. Exclure : node_modules, .git, dist, build, __pycache__, .venv, coverage, .next, .nuxt")

Étape 2 : Créer un plan de travail

Générer des éléments todo pour chaque répertoire, organisés par niveau de profondeur :

Niveau 0 : / (racine)
Niveau 1 : /src, /docs, /tests
Niveau 2 : /src/components, /src/utils, /docs/api
...

Étape 3 : Générer niveau par niveau

IMPORTANT : Générer d'abord les niveaux parents avant les niveaux enfants pour garantir que les références parent sont valides.

Pour chaque répertoire :

  1. Lire tous les fichiers du répertoire
  2. Analyser l'objectif et les relations
  3. Générer le contenu AGENTS.md
  4. Écrire le fichier avec la référence parent appropriée

Étape 4 : Comparer et mettre à jour (si existant)

Lorsque AGENTS.md existe déjà :

  1. Lire le contenu existant
  2. Identifier les sections :
    • Sections générées automatiquement (peuvent être mises à jour)
    • Sections manuelles (<!-- MANUAL --> conservées)
  3. Comparer :
    • Nouveaux fichiers ajoutés ?
    • Fichiers supprimés ?
    • Structure modifiée ?
  4. Fusionner :
    • Mettre à jour le contenu généré automatiquement
    • Conserver les annotations manuelles
    • Mettre à jour l'horodatage

Étape 5 : Valider la hiérarchie

Après génération, exécuter des contrôles de validation :

VérificationComment vérifierAction corrective
Les références parent résolventLire chaque AGENTS.md, vérifier que le chemin <!-- Parent: --> existeCorriger le chemin ou supprimer l'orphelin
Pas de AGENTS.md orphelinComparer les emplacements AGENTS.md à la structure des répertoiresSupprimer les fichiers orphelins
ComplétudeLister tous les répertoires, vérifier la présence de AGENTS.mdGénérer les fichiers manquants
Horodatages à jourVérifier les dates <!-- Généré: -->Régénérer les fichiers obsolètes

Script de validation type :

# Trouver tous les fichiers AGENTS.md
find . -name "AGENTS.md" -type f

# Vérifier les références parent
grep -r "<!-- Parent:" --include="AGENTS.md" .

Délégation intelligente

TâcheAgent
Cartographie des répertoiresexplore
Analyse des fichiersarchitect
Génération de contenuwriter
Écriture des AGENTS.mdwriter

Gestion des répertoires vides

Lors de la rencontre de répertoires vides ou presque vides :

ConditionAction
Aucun fichier, aucun sous-répertoireIgnorer - ne pas créer AGENTS.md
Aucun fichier, a des sous-répertoiresCréer un AGENTS.md minimal avec uniquement la liste des sous-répertoires
Uniquement des fichiers générés (*.min.js, *.map)Ignorer ou AGENTS.md minimal
Uniquement des fichiers de configurationCréer AGENTS.md décrivant l'objectif de la configuration

Exemple de AGENTS.md minimal pour les conteneurs de répertoires uniquement :

<!-- Parent: ../AGENTS.md -->
# {Nom du répertoire}

## Objectif
Répertoire conteneur pour organiser les modules connexes.

## Sous-répertoires
| Répertoire | Objectif |
|------------|----------|
| `subdir/` | Description (voir `subdir/AGENTS.md`) |

Règles de parallélisation

  1. Répertoires de même niveau : Traiter en parallèle
  2. Niveaux différents : Séquentiel (parent d'abord)
  3. Gros répertoires : Lancer un agent dédié par répertoire
  4. Petits répertoires : Regrouper plusieurs dans un seul agent

Standards de qualité

Doit inclure

  • Descriptions de fichiers précises
  • Références parent correctes
  • Liens vers les sous-répertoires
  • Instructions pour les agents IA

Doit éviter

  • Modèle générique
  • Noms de fichiers incorrects
  • Références parent cassées
  • Fichiers importants manquants

Exemple de résultat

AGENTS.md racine

<!-- Généré: 2024-01-15 | Mis à jour: 2024-01-15 -->

# mon-projet

## Objectif
Une application web pour gérer les tâches utilisateur avec des fonctionnalités de collaboration en temps réel.

## Fichiers clés
| Fichier | Description |
|---------|-------------|
| `package.json` | Dépendances et scripts du projet |
| `tsconfig.json` | Configuration TypeScript |
| `.env.example` | Modèle de variables d'environnement |

## Sous-répertoires
| Répertoire | Objectif |
|------------|----------|
| `src/` | Code source de l'application (voir `src/AGENTS.md`) |
| `docs/` | Documentation (voir `docs/AGENTS.md`) |
| `tests/` | Suites de tests (voir `tests/AGENTS.md`) |

## Pour les agents IA

### Travailler dans ce répertoire
- Toujours installer les dépendances après avoir modifié le manifeste du projet
- Utiliser le mode strict TypeScript
- Suivre les règles ESLint

### Exigences de test
- Exécuter les tests avant de commit
- Garantir >80% de couverture

### Schémas courants
- Utiliser les exports barrel (index.ts)
- Préférer les composants fonctionnels

## Dépendances

### Externes
- React 18.x - Framework UI
- TypeScript 5.x - Sécurité des types
- Vite - Outil de build

<!-- MANUAL: Des notes personnalisées sur le projet peuvent être ajoutées ci-dessous -->

AGENTS.md imbriqué

<!-- Parent: ../AGENTS.md -->
<!-- Généré: 2024-01-15 | Mis à jour: 2024-01-15 -->

# components

## Objectif
Composants React réutilisables organisés par fonctionnalité et complexité.

## Fichiers clés
| Fichier | Description |
|---------|-------------|
| `index.ts` | Export barrel pour tous les composants |
| `Button.tsx` | Composant bouton principal |
| `Modal.tsx` | Composant boîte de dialogue modale |

## Sous-répertoires
| Répertoire | Objectif |
|------------|----------|
| `forms/` | Composants liés aux formulaires (voir `forms/AGENTS.md`) |
| `layout/` | Composants de mise en page (voir `layout/AGENTS.md`) |

## Pour les agents IA

### Travailler dans ce répertoire
- Chaque composant a son propre fichier
- Utiliser les modules CSS pour le style
- Exporter via index.ts

### Exigences de test
- Tests unitaires dans le sous-répertoire `__tests__/`
- Utiliser React Testing Library

### Schémas courants
- Interfaces de props définies au-dessus du composant
- Utiliser forwardRef pour les composants exposant le DOM

## Dépendances

### Internes
- `src/hooks/` - Hooks personnalisés utilisés par les composants
- `src/utils/` - Fonctions utilitaires

### Externes
- `clsx` - Noms de classes conditionnels
- `lucide-react` - Icônes

<!-- MANUAL: -->

Déclenchement du mode mise à jour

Lors de l'exécution sur un codebase existant avec des fichiers AGENTS.md :

  1. Détecter d'abord les fichiers existants
  2. Lire et analyser le contenu existant
  3. Analyser l'état actuel du répertoire
  4. Générer un diff entre l'existant et l'actuel
  5. Appliquer les mises à jour tout en préservant les sections manuelles

Considérations de performance

  • Mettre en cache les listes de répertoires - Ne pas rescanner les mêmes répertoires
  • Regrouper les petits répertoires - Traiter plusieurs à la fois
  • Ignorer les inchangés - Si le répertoire n'a pas changé, sauter la régénération
  • Écritures parallèles - Plusieurs agents écrivent différents fichiers simultanément

Individual skills in this repo

This repo contains 20 individual skills — each has its own dedicated page.

agent-doc-discipline

Writing-time discipline for documents agents consume (the five surfaces, specs, tickets, .omc/skills/) — every rule checkable and carrying a why, steps before reference, one meaning in one home, no restating what the environment already says. Mandatory at drydock seed generation and the launch C5 sediment pass; opt-in for any other agent-facing doc edit. The companion of minimal-code-discipline: that one disciplines code, this one disciplines papers.

ai-slop-cleaner

Clean AI-generated code slop with a regression-safe, deletion-first workflow and optional reviewer-only mode

ask

Process-first advisor routing for Claude, Codex, Gemini, Antigravity, Grok, or Cursor via `omc ask`, with artifact capture and no raw CLI assembly

ask-navigator

Shipyard

autopilot

Full autonomous execution from idea to working code

autoresearch

Stateful single-mission improvement loop with strict evaluator contract, markdown decision logs, and max-runtime stop behavior

cancel

Cancel any active OMC mode (autopilot, ralph, ultragoal, swarm, ultrapilot, pipeline, team) and clean up retired legacy state

configure-notifications

Configure notification integrations (Telegram, Discord, Slack) via natural language

debug

Diagnose the current OMC session or repo state using logs, traces, state, and focused reproduction

deep-interview

Socratic deep interview with mathematical ambiguity gating before explicit execution approval

drydock

Lay the keel of the shipyard harness in any repo — the 4-pillar shared environment (Context, Rules, Tools, Standards) across 5 surfaces (CLAUDE.md, skills, design-system, mcp/cli, shared context) so that every human and agent inherits the same design language and anyone can ship. Run once per repo; re-run with --check to audit drift.

execute

Carry an approved task through to working, verified code

external-context

Invoke parallel document-specialist agents for external web searches and documentation lookup

graph

Deterministic orchestration graph runtime - declarative DAG pipelines with journal-based crash recovery

harbor

Harbor intake for external work — the captain only handles unresolved decisions. Sweeps incoming issues and PRs, verifies every claim before disposition, reuses every decision already made, and hands the maintainer a docket whose pending items each carry one question with options, recommendation, impact and evidence. Agent-autonomous for facts and for actions covered by standing authorization; signed for every new judgment. Never merges.

hud

Configure HUD display options (layout, presets, display elements)

launch

Shipyard

loft

Loft the shape before cutting steel — answer a design question that prose cannot settle by building a throwaway artifact: a pure logic module in a clickable shell, or structurally different UI variants behind one route. The captain reacts to the artifact; the answer folds into the decision; the artifact never docks. Use when a design question stalls in words, when a navigator map carries a loft ticket, or when a spec discussion reaches

minimal-code-discipline

YAGNI-ladder coding discipline for writing changes — existence-first, reuse before writing, dependency ladder, shortest correct diff, with non-negotiables that must never be minimized away

omc-doctor

Diagnose and fix oh-my-claudecode installation issues

Skills associés