Universal Skill Creator
1. Recadrage Fondamental et Invariants Non-Négociables
- Modèle Mental : Une compétence de classe mondiale est un système d'exploitation procédural à la demande, PAS un prompt non structuré. Elle associe la propriété intellectuelle du praticien à des portes de code déterministes (Architecture Hybride à Trois Zones) qui adhèrent strictement à
references/agentskills_spec.md. - Avis sur l'Environnement : Python 3 et les outils de découverte d'espace de travail standard sont préinstallés. N'essayez PAS d'installer des gestionnaires de paquets sauf si une importation explicite échoue.
- Invariant Strict 1 (Porte Zéro-Odeur) : Ne livrez jamais une compétence qui échoue à
python3 scripts/audit_skill.py <path>. Toutes les odeurs de structure doivent être auditées et résolues. - Invariant Strict 2 (Obligation de Forgeage de Script) : Chaque fois qu'une compétence candidate effectue des validations, des vérifications de schéma ou des comparaisons AST, vous DEVEZ créer l'utilitaire compagnon exécutable dans
scripts/validate.py(0 tokens de contexte pour le code du script). - Invariant Strict 3 (Survie à la Compaction) : Les invariants, les avis de paquets et la Table de Routage des Tâches DOIVENT se trouver dans les 1 000 premiers tokens de
SKILL.mdpour éviter le cisaillement de compaction (references/compaction_resilience.md). - Invariant Strict 4 (Standard de Production) : Chaque compétence doit inclure un dialecte standard du domaine, une Table Anti-Rationalisation et des cas de test d'évaluation vérifiables.
- Invariant Strict 5 (Porte Comportementale, Pas Seulement Structurelle) : Une compétence qui réussit l'audit et la sécurité mais ne bat pas la baseline sans compétence, ne résiste pas à la pression, ou ne route pas correctement en mode stub, N'EST PAS livrée. Voir
references/baseline_grading.md,references/pressure_scenarios.md,references/stub_router_mode.mdetreferences/render_qa.md. - Invariant Strict 6 (Structure d'Exemple Uniquement) : Les exemples livrés montrent uniquement la structure, le déclencheur, le flux de travail, la table de décision, le script de validation, les évaluations. Ne COPIEZ PAS les règles de domaine d'un exemple dans une nouvelle compétence. Construisez chaque nouvelle compétence à partir des SOP, transcriptions et recherches de domaine de l'utilisateur.
2. Table de Routage des Tâches
| Intention / Type d'Entrée de l'Utilisateur | Flux de Création Recommandé | Référence à la Demande Associée |
|---|---|---|
| Compétence Commerciale B2B (pour vente / livraison client) | Exécuter le Pipeline Complet en 6 Phases (Phases 0 à 5) | references/competitor_teardown_protocol.md |
| Notes brutes / SOP / Transcription de développeur | Exécuter le Pipeline Complet de Création en 6 Phases | references/domain_knowledge_ingestion.md |
| Compétence nécessitant des API externes ou des serveurs MCP | Exécuter la Découverte d'Outils de Phase 1 + Câblage MCP | references/mcp_tool_patterns.md |
| Audit ou correction d'une compétence existante | Exécuter l'Audit & le Correctif des 26 Odeurs (Zéro Token) | references/smell_taxonomy_26.md |
| Création interactive par assistant multi-tours | Appliquer le Protocole de Triage d'Ambiguïté OMSC | references/question_triage_omsc.md |
| Compétence sensible à la version (CLI, API, guide évolutif) | Utiliser le Mode Stub / Routeur, pointeur de 40 à 60 lignes uniquement | references/stub_router_mode.md |
| Toute compétence, à chaque étape de décision | Exécuter les Points de Contrôle QA, max. 2 questions par point, enregistrer chaque point | references/qa_checkpoints.md |
| Entrée aux formats .docx, .pdf, .ppt ou similaires | Utiliser d'abord la lecture native du harnais (Claude Code / Claude) ; l'extracteur est une solution de repli optionnelle, nécessaire uniquement avant le script de lexique texte | scripts/extract_text.py |
| Prouver qu'une compétence est réellement utile | Exécuter l'Évaluation sous Pression + Noter la Baseline + QA de Rendu | references/pressure_scenarios.md, references/baseline_grading.md, references/render_qa.md |
3. Phase 0 : Intelligence de Marché Approfondie & Démantèlement Concurrentiel
Avant de rédiger les instructions, exécutez une reconnaissance concurrentielle en utilisant agents/niche_researcher.md :
- Étape 0.1 (Démantèlement Concurrentiel) : Recherchez les compétences, prompts ou instructions personnalisées publiques existantes dans ce créneau.
- Auditez les offres concurrentes selon la taxonomie des 26 Odeurs (
references/competitor_teardown_protocol.md). - Identifiez leurs défauts structurels (par exemple, banalité IA générique, Buffet d'Options, scripts de validation manquants).
- Définissez l'antidote qui corrige les défauts structurels des concurrents.
- Auditez les offres concurrentes selon la taxonomie des 26 Odeurs (
- Étape 0.2 (Ingestion de la Littérature & du Dialecte du Domaine) :
- Ingérez les livres, livres blancs, transcriptions de podcasts et SOP d'entreprise pertinents, dans l'un de ces formats : .txt, .md, .docx, .pdf, notes et transcriptions.
- Règle de format, priorité au harnais, PAS une règle stricte : Claude Code et Claude lisent .md, .pdf, .docx, .ppt, etc., nativement, donc utilisez la lecture native du harnais en premier. Ne forcez pas l'extraction lorsque le harnais a déjà lu le fichier.
- L'extracteur de paquet dans scripts/extract_text.py est une solution de repli optionnelle uniquement, pour les harnais ou scripts qui ont besoin de texte brut. Sa seule utilisation obligatoire est le script de lexique, qui ne lit que le texte. Par conséquent, si vous exécutez le lexique sur un .docx ou .pdf, extrayez d'abord en .txt :
python3 scripts/extract_text.py path/to/source.docx --output evals/source.txt python3 scripts/extract_text.py path/to/source.pdf --output evals/source.txt- Les PDFs d'images scannées sans couche de texte : l'extracteur émet un avertissement et ne renvoie aucun texte. N'inventez pas de texte pour eux ; utilisez la OCR en dehors de ce paquet et enregistrez cette étape, ou laissez Claude lire le fichier nativement s'il le peut.
- Suivez
references/domain_knowledge_ingestion.mdpour extraire :- Acronymes industriels faisant autorité, métriques et dialecte standard (par exemple, MEDDPICC, CAC payback, hook dwell-time).
- Termes candidats pour le lexique via
python3 scripts/build_domain_lexicon.py <sources> --output evals/lexicon.json. - Seuils algorithmiques et formules mesurables.
- Listes de haute densité des modes d'échec non évidents (« pièges »).
4. Phase 1 : Découverte de l'Environnement & des Outils (Porte de Zone 1)
Copiez et exécutez cette étape de découverte avant de rédiger toute documentation :
- Étape 1.1 (Sonder l'Environnement & les Outils) : Exécutez le script de découverte fourni :
(Sous Windows PowerShell, utilisezpython3 scripts/discover_env.pypython3 scripts/discover_env.py)- Inspectez la sortie pour détecter le système d'exploitation, les binaires CLI disponibles (
git,docker,python, etc.) et les serveurs MCP actifs. - Si la compétence candidate implique un service externe (par exemple, Figma, GitHub, Postgres), vérifiez si un outil MCP ou CLI correspondant existe dans l'environnement.
- Inspectez la sortie pour détecter le système d'exploitation, les binaires CLI disponibles (
5. Phase 2 : Découverte Silencieuse de l'Espace de Travail & Triage OMSC
- Étape 2.1 (Lecture Silencieuse du Contexte) : Inspectez les fichiers de configuration actifs du dépôt (
package.json,pyproject.toml,Cargo.toml,.env.example, historique git).- Règle Stricte : Ne posez jamais de question à l'utilisateur sur le langage, le framework ou les outils qui peuvent être découverts en lisant les fichiers dans l'espace de travail.
- Étape 2.2 (Points de Contrôle QA, Obligatoires à Chaque Étape) :
Suivez
references/qa_checkpoints.md. Le triage de la Phase 2 seul ne suffit pas. À chaque point de contrôle, présentez un résumé de décision de 5 lignes, posez au plus 2 questions avec une valeur par défaut (Recommandée) et enregistrez-le :python3 scripts/record_qa.py evals/qa-checkpoints.json --checkpoint teardown-domain --summary "créneau, antidote, principaux pièges" --question "Le périmètre du créneau est-il correct ? (Recommandé : oui)" --confirmed- Point de Contrôle 1, après la Phase 0 : teardown-domain, créneau, concurrents, lacunes, forces, antidote, principaux pièges.
- Point de Contrôle 2, après l'architecture, avant la rédaction : architecture, structure en 6 niveaux, table de routage, liste de scripts, liste de références, ce qu'elle NE fera PAS.
- Point de Contrôle 3, après le projet de flux de travail, avant les portes : projet-flux-de-travail, étapes dans l'ordre, tables de décision, entrées anti-rationalisation, exemple d'entrée/sortie.
- Point de Contrôle 4, après les portes, avant l'empaquetage : portes, note d'audit, sécurité, excuses de pression fermées, delta de baseline, QA de rendu.
- Point de Contrôle 5, avant la livraison, après le déclencheur et le bundle : livraison, résultats du déclencheur, contenu du bundle, statut du gardien, statut stub/routeur si applicable.
- Rayon d'impact élevé, commercial ou architecture mutuellement exclusive : attendez la réponse de l'utilisateur à ce point de contrôle avant de continuer. Rayon d'impact faible : présenter le résumé et continuer avec la valeur par défaut recommandée est autorisé, mais le résumé et les réponses supposées doivent toujours être enregistrés. Un point de contrôle sans enregistrement n'a pas eu lieu.
- Étape 2.3 (Le Filtre d'Ambiguïté OMSC) :
- Vérifiez si l'Objectif, la Métrique, le Périmètre ou les Contraintes contiennent des inconnues bloquantes (
references/decision_matrices_and_escalation.md). - Si Rayon d'Impact Faible / Flux Standard : Continuez immédiatement en utilisant les valeurs par défaut du domaine. Posez 0 questions.
- Si Rayon d'Impact Élevé / Branche UX Mutuellement Exclusive : Faites une pause et posez au plus 1 à 3 questions concises :
- Attachez
(Recommandé)au choix par défaut le plus sûr. - Fournissez 2 à 3 options lettrées avec des compromis d'une ligne.
- Attachez
- Vérifiez si l'Objectif, la Métrique, le Périmètre ou les Contraintes contiennent des inconnues bloquantes (
6. Phase 3 : Synthèse Hybride à 3 Zones
Créez la structure complète du dossier de la compétence : <nom-compétence>/ contenant SKILL.md, scripts/, references/ et assets/.
- Étape 3.1 (Rédiger SKILL.md via une Architecture à 6 Niveaux) :
Adoptez le rôle agents/architect.md pour synthétiser la spécification centrale en utilisant
assets/master_template.md:- Octet 0 : Commence immédiatement par
---. Zéro chevrons dans le préambule. - Niveau 1 (Tokens 1 à 500) : Modèle mental du domaine & Invariants Non-Négociables.
- Niveau 2 (Tokens 500 à 1 000) : Table de Routage des Tâches (élimine les odeurs TOB/MDT).
- Niveau 3 (Tokens 1 000 à 1 500) : Découverte Silencieuse & Triage d'Ambiguïté OMSC.
- Niveau 4 (Tokens 1 500 à 3 000) : Étapes numérotées avec listes de contrôle
- [ ]copiables. - Niveau 5 (Tokens 3 000 à 4 200) : Pièges du Domaine à Haute Densité & Table Anti-Rationalisation.
- Niveau 6 (Tokens 4 200 à 4 800) : Ce Que Cette Compétence NE Fait PAS (élimine l'odeur NG).
- Limite Totale du Corps : Gardez sous 450 lignes (< 5 000 tokens).
- Octet 0 : Commence immédiatement par
- Étape 3.2 (Synthétiser les Scripts Déterministes Compagnons & Modèles Secrets) :
Adoptez le rôle agents/script_smith.md :
- Pour la validation : créez
scripts/validate.pyen utilisantassets/script_templates/validator_template.py. - Pour les mutations par lots/destructrices : créez
scripts/validate_plan.py. - Si
requires_secrets:est déclaré dansSKILL.md: créez.env.exampleà la racine de la compétence avec des URL de tableau de bord et des valeurs fictives. - Assurez-vous que les scripts émettent du JSON compact vers stdout et sortent avec un code 0 en cas de succès / 1 en cas d'échec.
- Pour la validation : créez
- Étape 3.3 (Déléguer les Documents Approfondis à des Références Plates) :
Si les manuels du domaine, les schémas ou les guides secondaires dépassent 50 lignes, placez-les dans
references/<sujet>.md.- Invariant : Les références doivent être plates (exactement 1 niveau de profondeur depuis
SKILL.md).
- Invariant : Les références doivent être plates (exactement 1 niveau de profondeur depuis
7. Phase 4 : Audit Structural des 26 Odeurs (Zéro Token) & Évaluations
- Étape 4.1 (Exécuter le Linter Statique Automatisé) :
Exécutez le linter structurel sur le dossier de la compétence nouvellement générée :
python3 scripts/audit_skill.py path/to/generated-skill - Étape 4.2 (Exécuter l'Analyse de Sécurité Déterministe) :
Exécutez le scanner de sécurité AST pour vérifier l'absence d'exécution de code à distance, d'injection de commandes shell ou de fuites d'identifiants :
python3 scripts/security_scan.py path/to/generated-skill - Étape 4.3 (Corriger Toutes les Violations & Odeurs) :
Si l'audit signale des violations, adoptez le rôle agents/smell_auditor.md :
- Échappatoire de Rationalisation (RL) : Ajoutez une Table Anti-Rationalisation explicite réfutant les excuses du modèle.
- Buffet d'Options (TOB) : Remplacez les listes d'outils par un seul outil par défaut par scénario.
- Corps Long (LSB) : Déplacez les longs extraits de code vers
references/ouassets/. - Réexécutez
audit_skill.pyjusqu'à ce que le statut soit RÉUSSI avec une Note de A ou A+.
- Étape 4.4 (Exécuter les Évaluations de Référence Empiriques) :
Exécutez les cas de test pour établir des taux de réussite de tâches vérifiables :
python3 scripts/run_evals.py path/to/generated-skill- Pour les révisions, adoptez le rôle agents/comparator.md pour effectuer une comparaison en double aveugle par rapport à la baseline.
- Étape 4.5 (Scénarios de Pression, Obligatoire) :
Générez des scénarios de pression combinés, puis exécutez chacun SANS la compétence ET AVEC la compétence, en enregistrant les excuses textuelles (
references/pressure_scenarios.md) :python3 scripts/generate_pressure_scenarios.py path/to/generated-skill evals/pressure-scenarios.json- La compétence générée doit contenir une table Pensée | Réalité avec au moins les 3 excuses de baseline les plus courantes. Des exécutions identiques en baseline et avec compétence signifient que la compétence n'a rien changé : ne la livrez pas.
- Étape 4.6 (Notation Avec-Compétence vs Baseline, Obligatoire) :
Lancez les exécutions avec-compétence et baseline dans le même tour, notez avec agents/grader.md, puis validez le contrat du correcteur et la porte de livraison (
references/baseline_grading.md) :python3 scripts/grade_baseline.py --with evals/grading-with.json --baseline evals/grading-baseline.json- Livrez uniquement si le taux_de_réussite avec-compétence >= 80 %, delta > 0 et aucune régression, sauf si une dérogation humaine est enregistrée dans feedback.json avec une raison.
- Étape 4.7 (QA de Rendu, Obligatoire pour les Sorties) :
Exécutez les portes de contenu et de fichiers sur tout ce que la compétence produit, avec une inspection visuelle par un humain lorsque la sortie est visuelle (
references/render_qa.md) :python3 scripts/render_qa.py path/to/generated-skill- Ce script ne prétend jamais à une réussite visuelle. Une réussite visuelle doit être effectuée et enregistrée par un humain.
8. Phase 5 : Vérification du Déclencheur & Empaquetage
- Étape 5.1 (Tester la Précision & le Rappel du Déclencheur) :
Testez la description YAML avec des prompts positifs et négatifs représentatifs :
python3 scripts/test_skill_trigger.py path/to/generated-skill - Étape 5.2 (Optimisation de la Description, Séparation Entraînement/Test) :
Divisez les requêtes de déclenchement 60 % entraînement / 40 % test, exécutez le test de déclenchement sur chaque division séparément et choisissez la meilleure description par le score TEST, pas le score d'entraînement. Négatifs proches uniquement ; un mauvais négatif est "Écrire une fonction fibonacci" pour une compétence PDF, un bon négatif est une requête longue et désordonnée pour une tâche voisine :
python3 scripts/eval_description_split.py path/to/generated-skill
9. Phase 6 : Empaquetage de la Compétence
- Étape 6.1 (Préparer le Dossier de la Compétence) :
Compilez la structure de dossiers finale :
<nom-compétence>/ ├── SKILL.md ├── .env.example # (optionnel, uniquement si requiere des secrets) ├── scripts/ │ ├── validate.py │ ├── validate_plan.py # (optionnel, pour les mutations par lots) │ ├── build_domain_lexicon.py │ ├── discover_env.py │ ├── audit_skill.py │ ├── security_scan.py │ ├── run_evals.py │ ├── generate_pressure_scenarios.py │ ├── grade_baseline.py │ ├── render_qa.py │ ├── test_skill_trigger.py │ ├── eval_description_split.py │ ├── extract_text.py │ └── record_qa.py ├── references/ │ └── (fichiers .md plats, exactement 1 niveau de profondeur) └── evals/ ├── qa-checkpoints.json ├── pressure-scenarios.json └── (autres fichiers de résultats d'évaluation) - Étape 6.2 (Finaliser le Changement & Livrer) :
Une fois que tous les points de contrôle de la Phase 5 sont passés et que la porte de livraison est ouverte, fournissez le résumé final à l'utilisateur. Incluez toujours un lien vers la spécification :
references/agentskills_spec.md.