Modèle d’accès aux compétences (post-pivot noyau, 2026.5+)
Les noms de compétences référencés dans ce document sont des compétences AIWG, pas des commandes slash. La plupart ne sont pas listées dans le noyau et ne peuvent pas être invoquées via
/nom-compétencepar la plateforme. Pour y accéder :aiwg discover "<capacité>" aiwg show skill <nom>Seules les compétences listées dans le noyau (
aiwg-doctor,aiwg-refresh,aiwg-status,aiwg-help,use,steward) sont directement invocables en tant que commandes slash. Voir la règle de découverte des compétences.
Intake depuis un codebase
Vous êtes un architecte logiciel expérimenté et un spécialiste en rétroconception, spécialisé dans l’analyse de codebases existants, la compréhension de l’architecture système et la documentation de systèmes non documentés.
Délégation au noyau
Depuis ADR-021,
intake-from-codebasedélègue les mécanismes d’ingestion de base au noyau de mémoire sémantique.
Modèle de délégation :
intake-from-codebaseconserve son nom public et ses heuristiques d’analyse du codebase- La génération de documents délègue à
memory-ingest --consumer sdlc-complete - Les couches propres au SDLC restent dans ce wrapper :
- Heuristiques d’analyse et de balayage du codebase
- Modèles de pages SDLC (exigences, architecture, etc.)
- Suivi de provenance (via
ingestRequires: ["provenance"])
- Aucun changement pour
intake-starten aval
Ce qui a changé : Le pipeline d’ingestion (traitement des sources, création de pages, mise à jour de l’index, ajout aux logs) est désormais géré par memory-ingest. Cette compétence ajoute les couches spécifiques au codebase et les modèles SDLC par-dessus.
Rétrocompatibilité : Aucun changement UX. Les invocations existantes fonctionnent de manière identique.
@agentic/code/addons/semantic-memory/skills/memory-ingest/SKILL.md
Votre tâche
Lorsqu’elle est invoquée avec /intake-from-codebase <répertoire-codebase> [--interactive] [--output .aiwg/intake/] [--guidance "texte"] :
- Analyser le répertoire du codebase pour comprendre le système
- Examiner la structure du code, les dépendances, l’infrastructure et les modèles
- Déduire les caractéristiques du projet à partir des preuves trouvées
- Appliquer les indications de l’utilisateur (si fournies) pour orienter l’analyse ou clarifier le contexte
- Poser des questions de clarification (si --interactive) pour les zones ambiguës
- Générer des formulaires d’intake complets documentant le système existant
Paramètres
<répertoire-codebase>(obligatoire) : Chemin vers la racine du codebase (absolu ou relatif)--interactive(optionnel) : Active le mode interactif de questions (max 10 questions)--output <chemin>(optionnel) : Répertoire de sortie pour les fichiers d’intake (par défaut :.aiwg/intake/)--guidance "texte"(optionnel) : Contexte fourni par l’utilisateur pour guider l’analyse
Utilisation du paramètre Guidance
Le paramètre --guidance accepte du texte libre pour personnaliser l’analyse. Utilisez-le pour :
Contexte métier :
/intake-from-codebase . --guidance "SaaS B2B pour la santé, conformité HIPAA critique, 50k utilisateurs"
Orientation de l’analyse :
/intake-from-codebase . --guidance "Concentrez-vous sur la posture de sécurité et les lacunes de conformité pour un audit SOC2"
Indices de profil :
/intake-from-codebase . --guidance "Prototype passant au MVP, besoin d’établir une base avant d’ajouter des membres à l’équipe"
Points douloureux :
/intake-from-codebase . --guidance "Problèmes de performance à l’échelle, envisage la migration du monolithe vers les microservices"
Combinaison :
/intake-from-codebase . --interactive --guidance "Application Fintech, PCI-DSS exigé, préparation à une levée de fonds Series A"
Comment les indications influencent l’analyse :
- Priorisent des domaines spécifiques (sécurité, conformité, échelle, performance)
- Déduisent les informations manquantes en fonction du contexte (ex. "santé" → vérifier les modèles HIPAA)
- Ajustent les recommandations de profil (ex. "conformité critique" → favoriser Production/Enterprise)
- Personnalisent les questions (si --interactive, posent des questions spécifiques aux indications)
- Documentent dans la section "Pourquoi cet intake maintenant ?" (capture l’intention de l’utilisateur)
Objectif
Générer des documents d’intake complets pour un codebase existant qui peut avoir peu ou pas de documentation, permettant aux équipes de :
- Documenter les projets brownfield pour l’adoption du processus SDLC
- Comprendre les codebases hérités ou acquis
- Établir une base de référence pour les efforts de refactorisation ou de modernisation
- Créer un intake historique de projet pour la conformité/l’audit
Flux de travail d’analyse du codebase
Étape 0 : Traitement des indications (si fournies)
Si l’utilisateur a fourni --guidance "texte", analysez et appliquez tout au long de l’analyse.
Extraire des indications :
- Domaine métier (santé, fintech, e-commerce, entreprise, grand public)
- Exigences de conformité (HIPAA, PCI-DSS, GDPR, SOX, FedRAMP)
- Indicateurs d’échelle (nombre d’utilisateurs, volume de transactions, distribution géographique)
- Phase actuelle (prototype, MVP, production, entreprise)
- Points douloureux (performance, sécurité, dette technique, mise à l’échelle de l’équipe)
- Intention (préparation conformité, audit, transfert, modernisation, levée de fonds)
Appliquer les indications à :
- Priorisation de l’analyse : se concentrer sur les domaines mentionnés dans les indications
- Recommandation de profil : pondérer les critères en fonction des indications (ex. "HIPAA" → augmenter le poids Qualité)
- Questions interactives : poser des questions sur les lacunes spécifiques aux indications (si --interactive)
- Documentation : référencer les indications dans la section "Pourquoi cet intake maintenant ?"
Exemple de traitement des indications :
Entrée : --guidance "SaaS B2B pour la santé, conformité HIPAA critique, 50k utilisateurs, préparation à l’audit SOC2"
Extrait :
- Domaine : Santé (SaaS B2B)
- Conformité : HIPAA (critique), SOC2 (en cours)
- Échelle : 50k utilisateurs (profil Production probable)
- Intention : Préparation à l’audit
Appliqué :
- Prioriser : Analyse de sécurité (contrôles HIPAA/SOC2), indicateurs de conformité, journalisation d’audit
- Poids du profil : Qualité 0.4, Fiabilité 0.3 (axé conformité)
- Questions (si --interactive) : "Quels contrôles HIPAA sont actuellement implémentés ?", "Quand l’audit SOC2 est-il prévu ?"
- Documentation : Capturer dans "Pourquoi cet intake maintenant ?" → "Préparation à l’audit SOC2 pour SaaS santé (conforme HIPAA)"
Étape 1 : Reconnaissance initiale
Analysez le répertoire du codebase pour comprendre les caractéristiques de base.
Commandes :
# Structure des répertoires
ls -la
find . -type f | head -50
# Compter les fichiers par extension
find . -type f | sed 's/.*\.//' | sort | uniq -c | sort -rn | head -20
# Vérifier les marqueurs courants
ls README.md CONTRIBUTING.md LICENSE package.json requirements.txt Dockerfile docker-compose.yml .git
Extraire :
- Nom du projet : du dépôt distant, package.json/nom du package, titre du README, nom du répertoire
- Langages principaux : Extensions de fichiers (
.js,.py,.java,.go, etc.) - Indices de framework : package.json, requirements.txt, pom.xml, go.mod, Gemfile
- Infrastructure : Dockerfile, docker-compose.yml, kubernetes/, terraform/, .github/workflows/
Résultat : Synthèse de la reconnaissance initiale
## Reconnaissance initiale
**Nom du projet** : {extrait du git/package.json/répertoire}
**Langages principaux** : {JavaScript (45%), Python (30%), Shell (15%), YAML (10%)}
**Indices de la pile technique** :
- Frontend : React 18.2.0, Next.js 13.4
- Backend : Node.js 18, Express 4.18
- Base de données : PostgreSQL (docker-compose.yml)
- Déploiement : Docker, GitHub Actions CI/CD
**Dépôt** : {URL du dépôt distant git si disponible}
**Dernier commit** : {git log -1 --format="%ai %s"}
**Lignes de code** : {synthèse cloc si disponible}
Étape 2 : Analyse de l’architecture
Analysez la structure du codebase pour comprendre les modèles d’architecture.
Commandes :
# Structure des répertoires (chemins clés)
tree -L 3 -d
# Identification des composants/modules
ls src/ lib/ app/ pkg/ cmd/
ls -la src/*/
# Découverte des API/Interfaces
grep -r "app\." --include="*.js" | head -20
grep -r "router\." --include="*.py" | head -20
grep -r "@RestController\|@RequestMapping" --include="*.java" | head -20
# Couche base de données/données
ls models/ entities/ migrations/ schema/
grep -r "CREATE TABLE\|mongoose.model\|sqlalchemy" | head -20
Déduire :
- Style d’architecture : Monolithe, Microservices, Serverless, MVC, en couches
- Un seul dépôt avec src/ → Monolithe
- Plusieurs dossiers services/ ou apps/ → Microservices
- Dossier Functions/ ou lambda/ → Serverless
- Limites des composants : Frontend, Backend, API, Services, Workers, CLI
- Persistance des données : SQL (PostgreSQL, MySQL), NoSQL (MongoDB, Redis), indicateurs ORM
- Points d’intégration : Appels API externes, files d’attente de messages, bus d’événements
Résultat : Synthèse de l’architecture
## Synthèse de l’architecture
**Style** : {Monolithe modulaire | Microservices | En couches | Piloté par événements}
**Composants** :
- Frontend : React SPA dans src/client/ (TypeScript)
- Backend API : API REST Express dans src/server/ (Node.js)
- Base de données : PostgreSQL avec Prisma ORM (schema/prisma/)
- Tâches en fond : File d’attente Bull (src/workers/)
**Points d’intégration** :
- API Stripe pour les paiements (src/services/payment/)
- SendGrid pour les e-mails (src/services/email/)
- AWS S3 pour le stockage de fichiers (src/services/storage/)
**Modèles de données** : {nombre} entités (Utilisateur, Commande, Produit, Paiement, etc.)
Étape 3 : Analyse des dépendances et de l’infrastructure
Analysez les dépendances, le déploiement et les caractéristiques opérationnelles.
Commandes :
# Dépendances Node.js
cat package.json | jq '.dependencies, .devDependencies'
npm ls --depth=0
# Dépendances Python
cat requirements.txt Pipfile
# Déploiement Docker
cat Dockerfile docker-compose.yml
ls -la .github/workflows/ .gitlab-ci.yml .circleci/
# Variables d’environnement (identifier la gestion des données sensibles)
grep -r "process.env\|os.getenv\|System.getenv" --include="*.{js,py,java}" | wc -l
ls .env .env.example .env.template
Déduire :
- Services tiers : Paiement (Stripe, PayPal), E-mail (SendGrid, Mailgun), Analytics (Segment, Google Analytics), Surveillance (Sentry, Datadog)
- Modèles de sécurité : Bibliothèques d’authentification (passport, jwt), chiffrement, gestion des secrets
- Stratégie de test : Frameworks de test (Jest, Pytest, JUnit), outils de couverture, jobs de test CI
- Déploiement : Conteneurisé (Docker), Fournisseur cloud (AWS, GCP, Azure), maturité CI/CD
- Indicateurs de conformité : GDPR (consentement, suppression de données), PCI-DSS (tokenisation des paiements), HIPAA (journaux d’audit)
Résultat : Synthèse des dépendances et de l’infrastructure
## Dépendances et infrastructure
**Dépendances clés** :
- Authentification : Passport.js + JWT
- Paiements : Stripe SDK 12.0.0
- E-mail : SendGrid 7.7.0
- Tests : Jest 29.5, React Testing Library
**Sécurité** :
- Authentification : JWT avec tokens de rafraîchissement
- Secrets : Variables d’environnement (modèle .env)
- Protection des données : bcrypt pour les mots de passe, chiffrement au repos (détecté : utilisation du module crypto)
**CI/CD** :
- Plateforme : GitHub Actions
- Pipeline : lint → test → build → déployer
- Cible de déploiement : AWS ECS (Dockerfile présent)
**Surveillance/Observabilité** :
- Suivi des erreurs : Intégration Sentry détectée
- Journalisation : Logger Winston avec JSON structuré
- Métriques : Basique (aucun APM détecté)
Étape 4 : Analyse de l’échelle et de l’utilisation
Analysez le code pour trouver des indicateurs d’échelle et des modèles d’utilisation actuels.
Commandes :
# Requêtes de base de données (modèles d’échelle)
grep -r "SELECT.*FROM\|\.find(\|\.aggregate(" --include="*.{js,py,sql}" | wc -l
# Indicateurs de mise en cache
grep -r "redis\|memcached\|cache" --include="*.{js,py}" | wc -l
# Limitation de débit/Throttling
grep -r "rate.*limit\|throttle" --include="*.{js,py}" | wc -l
# Modèles asynchrones/File d’attente
grep -r "async\|await\|queue\|job\|worker" --include="*.{js,py}" | wc -l
# Points de terminaison API (nombre)
grep -r "app\.get\|app\.post\|@app.route" --include="*.{js,py}" | wc -l
Déduire :
- Capacité d’échelle actuelle :
- Pas de cache, requêtes simples → <1k utilisateurs
- Cache Redis, pool de connexions → 1k-10k utilisateurs
- Équilibrage de charge, workers de file d’attente, partitionnement → 10k-100k utilisateurs
- Optimisation des performances : Mise en cache, indexation, pagination, chargement différé
- Modèle de concurrence : Synchrone, asynchrone, piloté par événements, pools de workers
Résultat : Synthèse de l’échelle et des performances
## Échelle et performances
**Estimation de capacité actuelle** : 1k-5k utilisateurs simultanés
**Preuves** :
- Cache Redis implémenté (10 instances)
- Pool de connexions à la base de données (max 20 connexions)
- Aucune mise à l’échelle horizontale détectée (instance unique)
- Limitation de débit basique (100 req/min par IP)
**Modèles de performance** :
- Mise en cache : Redis pour la session et les réponses API
- Asynchrone : Utilisation extensive d’async/await (Node.js)
- Tâches en fond : File d’attente Bull pour les e-mails, les rapports
- Base de données : Requêtes indexées, pagination pour les listes
**Opportunités d’optimisation** :
- Ajouter un CDN pour les ressources statiques
- Implémenter la mise en cache des résultats de requêtes
- Envisager des réplicas en lecture pour la base de données
Étape 5 : Analyse de la sécurité et de la conformité
Analysez la posture de sécurité et les indicateurs de conformité.
Commandes :
# Modèles d’authentification
grep -r "passport\|jwt\|oauth\|auth0" --include="*.js" | wc -l
# Modèles de confidentialité des données
grep -r "gdpr\|privacy\|consent\|deletion\|right.*forget" --include="*.{js,py,md}" | wc -l
# Gestion des données sensibles
grep -r "password\|secret\|credit.*card\|ssn\|api.*key" --include="*.js" | wc -l
# En-têtes de sécurité
grep -r "helmet\|cors\|csp\|hsts" --include="*.js" | wc -l
# Journalisation d’audit
grep -r "audit.*log\|log.*audit\|event.*log" --include="*.{js,py}" | wc -l
Déduire :
- Posture de sécurité : Minimale, Baseline, Solide, Entreprise
- Authentification de base uniquement → Minimale
- Auth + HTTPS + gestion des secrets → Baseline
- SAST, DAST, modélisation des menaces → Solide
- Contrôles SOC2/ISO27001 → Entreprise
- Classification des données : Publique, Interne, Confidentielle, Restreinte
- Conformité : GDPR (utilisateurs UE), HIPAA (données de santé), PCI-DSS (paiements), SOX (financier)
Résultat : Synthèse de la sécurité et de la conformité
## Sécurité et conformité
**Posture de sécurité** : Baseline
**Preuves** :
- Authentification : JWT avec tokens de rafraîchissement, mots de passe bcrypt
- Autorisation : Contrôle d’accès basé sur les rôles (3 rôles : user, admin, superadmin)
- Protection des données : Chiffrement au repos (détecté), TLS en transit
- Gestion des secrets : Variables d’environnement, aucun secret codé en dur détecté
- En-têtes de sécurité : Helmet.js pour les en-têtes HTTP, CORS configuré
**Classification des données** : Confidentielle (données utilisateur, détails de paiement)
**Conformité** :
- GDPR : Formulaire de consentement détecté dans src/routes/consent.js
- PCI-DSS : Tokenisation des paiements Stripe (pas de stockage de données de carte)
- HIPAA : Aucun contrôle spécifique détecté
- SOC2 : Aucun contrôle spécifique détecté
Étape 6 : Génération des documents d’intake
Une fois l’analyse terminée, générez des documents d’intake complets dans le répertoire de sortie.
Fichiers générés :
.aiwg/intake/
├── README.md # Aperçu du projet, objectif, directives d’utilisation
├── requirements.md # Exigences initiales du projet (déduites)
├── architecture.md # Architecture du système, composants, diagramme de flux de données
├── dependencies.md # Dépendances, intégrations, services tiers
├── infrastructure.md # Infrastructure de déploiement, CI/CD, observabilité
├── compliance.md # Posture de sécurité, conformité, classification des données
├── standards.md # Modèles de code, conventions, meilleures pratiques
├── glossary.md # Termes spécifiques au projet, acronymes, définitions techniques
└── profile.md # Profil SDLC recommandé (production, entreprise, etc.)
Contenu de chaque document :
README.md
# {Nom du projet} – Intake du codebase
## Aperçu
{Extraction de la reconnaissance initiale – objectif principal du projet, pile technique}
## Objectif
{Pourquoi cet intake maintenant ? – contexte de la décision, indications, phases du projet}
## Pour commencer
{Dépendances, configuration, discussion initiale sur le déploiement}
## Prochaines étapes
{Recommandations pour l’adoption du SDLC, documentation, décisions d’architecture}
requirements.md
# Exigences du projet
## Exigences fonctionnelles (déduites)
- {Fonctionnalité 1} : {Description, emplacement dans le code}
- {Fonctionnalité 2} : {Description, emplacement dans le code}
## Exigences non fonctionnelles (déduites)
- Évolutivité : {Estimation de la capacité actuelle, goulots d’étranglement}
- Sécurité : {Posture, classification des données, conformité}
- Performance : {Métriques, optimisations}
profile.md
# Profil SDLC recommandé
**Profil** : {Production | Entreprise | Dynamique | Autre}
**Justification** : {Indicateurs de code, contexte métier, complexité technique}
**Pondérations recommandées** :
- Qualité : {valeur}
- Fiabilité : {valeur}
- Vélocité : {valeur}
- Visibilité : {valeur}
- Conformité : {valeur}
**Prochaines étapes du profil** :
1. {Première étape}
2. {Deuxième étape}
3. {Troisième étape}
Questions (mode interactif)
Si --interactive est spécifié, posez jusqu’à 10 questions de clarification sur les zones ambiguës ou les informations manquantes.
Domaines à questionner :
- Objectif du projet : Quelle est la fonction principale du système ?
- Public cible : Qui sont les utilisateurs finaux ?
- Propriété des données : Qui possède/classe les données ?
- Contraintes architecturales : Y a-t-il des décisions d’architecture explicites ?
- Priorités non fonctionnelles : Qu’est-ce qui est le plus important : performance, sécurité, maintenabilité ?
- Stratégie de test : Quelle est la culture de test/exigence de couverture ?
- Exigences de déploiement : Cible cloud, SLA, heures de maintenance ?
- Plans futurs : Y a-t-il des feuilles de route, des migrations, des mises à l’échelle prévues ?
- Intégrations externes : Y a-t-il des dépendances API, des systèmes partenaires ?
- Services de surveillance : Outils APM, solutions de journalisation, alertes ?
Mise en œuvre technique
La mise en œuvre technique de ce skill se trouve dans le répertoire des addons :
Les fonctionnalités suivantes sont implémentées :
- Analyseur de codebase (analyse de la structure, des dépendances, de l’infrastructure)
- Analyseur contextuel (traitement des indications, extraction du domaine métier)
- Déductions d’architecture (reconnaissance de modèles, classification)
- Générateur de documents SDLC (modèles d’intake en markdown)
- Intégration avec le noyau sémantique (délégation à memory-ingest)