copilot-instructions-blueprint-generator

Par github · awesome-copilot

Générateur de plans directeurs agnostique aux technologies pour créer des fichiers `copilot-instructions.md` complets qui guident GitHub Copilot afin qu'il produise du code conforme aux standards du projet, aux patterns d'architecture et aux versions exactes des technologies, en analysant les patterns existants de la base de code et en évitant toute supposition.

npx skills add https://github.com/github/awesome-copilot --skill copilot-instructions-blueprint-generator

Générateur de Blueprint d'Instructions Copilot

Variables de Configuration

${PROJECT_TYPE="Auto-detect|.NET|Java|JavaScript|TypeScript|React|Angular|Python|Multiple|Other"} <!-- Technologie primaire --> ${ARCHITECTURE_STYLE="Layered|Microservices|Monolithic|Domain-Driven|Event-Driven|Serverless|Mixed"} <!-- Approche architecturale --> ${CODE_QUALITY_FOCUS="Maintainability|Performance|Security|Accessibility|Testability|All"} <!-- Priorités de qualité --> ${DOCUMENTATION_LEVEL="Minimal|Standard|Comprehensive"} <!-- Exigences de documentation --> ${TESTING_REQUIREMENTS="Unit|Integration|E2E|TDD|BDD|All"} <!-- Approche de test --> ${VERSIONING="Semantic|CalVer|Custom"} <!-- Approche de versioning -->

Prompt Généré

"Générez un fichier copilot-instructions.md exhaustif qui guidera GitHub Copilot pour produire du code conforme aux normes, à l'architecture et aux versions technologiques de notre projet. Les instructions doivent être strictement basées sur les modèles de code réels de notre codebase et éviter toute hypothèse. Suivez cette approche :

1. Structure des instructions fondamentales

# Instructions GitHub Copilot

## Directives Prioritaires

Lors de la génération de code pour ce référentiel :

1. **Compatibilité des versions** : Détectez toujours et respectez les versions exactes des langages, frameworks et bibliothèques utilisés dans ce projet
2. **Fichiers de contexte** : Priorisez les modèles et normes définis dans le répertoire .github/copilot
3. **Modèles de codebase** : Quand les fichiers de contexte ne donnent pas de guidance spécifique, analysez la codebase pour les modèles établis
4. **Cohérence architecturale** : Maintenez notre style architectural ${ARCHITECTURE_STYLE} et les limites établies
5. **Qualité du code** : Priorisez ${CODE_QUALITY_FOCUS == "All" ? "la maintenabilité, performance, sécurité, accessibilité et testabilité" : CODE_QUALITY_FOCUS} dans tout code généré

## Détection de version technologique

Avant de générer du code, analysez la codebase pour identifier :

1. **Versions de langage** : Détectez les versions exactes des langages de programmation utilisés
   - Examinez les fichiers de projet, fichiers de configuration et gestionnaires de paquets
   - Cherchez les indicateurs de version spécifiques au langage (p. ex., <LangVersion> dans les projets .NET)
   - N'utilisez jamais de fonctionnalités du langage au-delà de la version détectée

2. **Versions de framework** : Identifiez les versions exactes de tous les frameworks
   - Vérifiez package.json, .csproj, pom.xml, requirements.txt, etc.
   - Respectez les contraintes de version lors de la génération de code
   - Ne suggérez jamais de fonctionnalités non disponibles dans les versions de framework détectées

3. **Versions de bibliothèque** : Notez les versions exactes des bibliothèques et dépendances clés
   - Générez du code compatible avec ces versions spécifiques
   - N'utilisez jamais les APIs ou fonctionnalités non disponibles dans les versions détectées

## Fichiers de contexte

Priorisez les fichiers suivants du répertoire .github/copilot (s'ils existent) :

- **architecture.md** : Directives d'architecture système
- **tech-stack.md** : Versions technologiques et détails des frameworks
- **coding-standards.md** : Normes de style et de formatage du code
- **folder-structure.md** : Directives d'organisation du projet
- **exemplars.md** : Modèles de code exemplaires à suivre

## Instructions d'analyse de codebase

Quand les fichiers de contexte ne donnent pas de guidance spécifique :

1. Identifiez les fichiers similaires à celui en cours de modification ou de création
2. Analysez les modèles pour :
   - Conventions de nommage
   - Organisation du code
   - Gestion des erreurs
   - Approches de logging
   - Style de documentation
   - Modèles de test

3. Suivez les modèles les plus cohérents trouvés dans la codebase
4. Quand des modèles conflictuels existent, priorisez les modèles des fichiers plus récents ou avec une couverture de test plus élevée
5. N'introduisez jamais de modèles non trouvés dans la codebase existante

## Normes de qualité du code

${CODE_QUALITY_FOCUS.includes("Maintainability") || CODE_QUALITY_FOCUS == "All" ? `### Maintenabilité
- Écrivez du code qui se documente lui-même avec un nommage clair
- Suivez les conventions de nommage et d'organisation évidentes dans la codebase
- Suivez les modèles établis pour la cohérence
- Gardez les fonctions concentrées sur des responsabilités uniques
- Limitez la complexité et la longueur des fonctions pour correspondre aux modèles existants` : ""}

${CODE_QUALITY_FOCUS.includes("Performance") || CODE_QUALITY_FOCUS == "All" ? `### Performance
- Suivez les modèles existants pour la gestion de la mémoire et des ressources
- Correspondez aux modèles existants pour gérer les opérations coûteuses en calcul
- Suivez les modèles établis pour les opérations asynchrones
- Appliquez la mise en cache de manière cohérente avec les modèles existants
- Optimisez selon les modèles évidents dans la codebase` : ""}

${CODE_QUALITY_FOCUS.includes("Security") || CODE_QUALITY_FOCUS == "All" ? `### Sécurité
- Suivez les modèles existants pour la validation des entrées
- Appliquez les mêmes techniques de sanitisation utilisées dans la codebase
- Utilisez les requêtes paramétrées correspondant aux modèles existants
- Suivez les modèles d'authentification et d'autorisation établis
- Gérez les données sensibles selon les modèles existants` : ""}

${CODE_QUALITY_FOCUS.includes("Accessibility") || CODE_QUALITY_FOCUS == "All" ? `### Accessibilité
- Suivez les modèles d'accessibilité existants dans la codebase
- Correspondez à l'utilisation des attributs ARIA avec les composants existants
- Maintenez le support de navigation au clavier cohérent avec le code existant
- Suivez les modèles établis pour la couleur et le contraste
- Appliquez les modèles d'alternatives de texte cohérents avec la codebase` : ""}

${CODE_QUALITY_FOCUS.includes("Testability") || CODE_QUALITY_FOCUS == "All" ? `### Testabilité
- Suivez les modèles établis pour un code testable
- Correspondez aux approches d'injection de dépendances utilisées dans la codebase
- Appliquez les mêmes modèles pour gérer les dépendances
- Suivez les modèles établis de mocking et de test doubles
- Correspondez au style de test utilisé dans les tests existants` : ""}

## Exigences de documentation

${DOCUMENTATION_LEVEL == "Minimal" ? 
`- Correspondez au niveau et au style des commentaires trouvés dans le code existant
- Documentez selon les modèles observés dans la codebase
- Suivez les modèles existants pour documenter les comportements non évidents
- Utilisez le même format pour les descriptions de paramètres que le code existant` : ""}

${DOCUMENTATION_LEVEL == "Standard" ? 
`- Suivez le format exact de documentation trouvé dans la codebase
- Correspondez au style et à la complétude XML/JSDoc des commentaires existants
- Documentez les paramètres, retours et exceptions dans le même style
- Suivez les modèles existants pour les exemples d'utilisation
- Correspondez au style de documentation au niveau de la classe` : ""}

${DOCUMENTATION_LEVEL == "Comprehensive" ? 
`- Suivez les modèles de documentation les plus détaillés trouvés dans la codebase
- Correspondez au style et à la complétude du code le mieux documenté
- Documentez exactement comme le font les fichiers les plus minutieusement documentés
- Suivez les modèles existants pour la liaison de documentation
- Correspondez au niveau de détail dans les explications des décisions de conception` : ""}

## Approche de test

${TESTING_REQUIREMENTS.includes("Unit") || TESTING_REQUIREMENTS == "All" ? 
`### Test unitaire
- Correspondez à la structure et au style exact des tests unitaires existants
- Suivez les mêmes conventions de nommage pour les classes et méthodes de test
- Utilisez les mêmes modèles d'assertion trouvés dans les tests existants
- Appliquez la même approche de mocking utilisée dans la codebase
- Suivez les modèles existants pour l'isolation des tests` : ""}

${TESTING_REQUIREMENTS.includes("Integration") || TESTING_REQUIREMENTS == "All" ? 
`### Test d'intégration
- Suivez les mêmes modèles de test d'intégration trouvés dans la codebase
- Correspondez aux modèles existants pour la configuration et le nettoyage des données de test
- Utilisez la même approche pour tester les interactions de composants
- Suivez les modèles existants pour vérifier le comportement du système` : ""}

${TESTING_REQUIREMENTS.includes("E2E") || TESTING_REQUIREMENTS == "All" ? 
`### Test de bout en bout
- Correspondez à la structure et aux modèles de test E2E existants
- Suivez les modèles établis pour les tests d'interface utilisateur
- Appliquez la même approche pour vérifier les parcours utilisateur` : ""}

${TESTING_REQUIREMENTS.includes("TDD") || TESTING_REQUIREMENTS == "All" ? 
`### Développement guidé par les tests
- Suivez les modèles TDD évidents dans la codebase
- Correspondez à la progression des cas de test vue dans le code existant
- Appliquez les mêmes modèles de refactorisation après les tests qui passent` : ""}

${TESTING_REQUIREMENTS.includes("BDD") || TESTING_REQUIREMENTS == "All" ? 
`### Développement guidé par le comportement
- Correspondez à la structure Given-When-Then existante dans les tests
- Suivez les mêmes modèles pour les descriptions de comportement
- Appliquez le même niveau de focus métier dans les cas de test` : ""}

## Directives spécifiques à la technologie

${PROJECT_TYPE == ".NET" || PROJECT_TYPE == "Auto-detect" || PROJECT_TYPE == "Multiple" ? `### Directives .NET
- Détectez et adhérez strictement à la version .NET spécifique utilisée
- Utilisez seulement les fonctionnalités du langage C# compatibles avec la version détectée
- Suivez exactement les modèles d'utilisation LINQ tels qu'ils apparaissent dans la codebase
- Correspondez aux modèles d'utilisation async/await du code existant
- Appliquez la même approche d'injection de dépendances utilisée dans la codebase
- Utilisez les mêmes types de collections et modèles trouvés dans le code existant` : ""}

${PROJECT_TYPE == "Java" || PROJECT_TYPE == "Auto-detect" || PROJECT_TYPE == "Multiple" ? `### Directives Java
- Détectez et adhérez à la version Java spécifique utilisée
- Suivez exactement les mêmes modèles de conception trouvés dans la codebase
- Correspondez aux modèles de gestion d'exceptions du code existant
- Utilisez les mêmes types de collections et approches trouvés dans la codebase
- Appliquez les modèles d'injection de dépendances évidents dans le code existant` : ""}

${PROJECT_TYPE == "JavaScript" || PROJECT_TYPE == "TypeScript" || PROJECT_TYPE == "Auto-detect" || PROJECT_TYPE == "Multiple" ? `### Directives JavaScript/TypeScript
- Détectez et adhérez à la version ECMAScript/TypeScript spécifique utilisée
- Suivez les mêmes modèles d'import/export de modules trouvés dans la codebase
- Correspondez aux définitions de type TypeScript avec les modèles existants
- Utilisez les mêmes modèles async (promesses, async/await) que le code existant
- Suivez les modèles de gestion d'erreurs provenant de fichiers similaires` : ""}

${PROJECT_TYPE == "React" || PROJECT_TYPE == "Auto-detect" || PROJECT_TYPE == "Multiple" ? `### Directives React
- Détectez et adhérez à la version React spécifique utilisée
- Correspondez aux modèles de structure de composants des composants existants
- Suivez les mêmes modèles de hooks et de cycle de vie trouvés dans la codebase
- Appliquez la même approche de gestion d'état utilisée dans les composants existants
- Correspondez aux modèles de typage et de validation des props du code existant` : ""}

${PROJECT_TYPE == "Angular" || PROJECT_TYPE == "Auto-detect" || PROJECT_TYPE == "Multiple" ? `### Directives Angular
- Détectez et adhérez à la version Angular spécifique utilisée
- Suivez les mêmes modèles de composants et de modules trouvés dans la codebase
- Correspondez à l'utilisation exacte des décorateurs telle que vue dans le code existant
- Appliquez les mêmes modèles RxJS trouvés dans la codebase
- Suivez les modèles existants pour la communication entre composants` : ""}

${PROJECT_TYPE == "Python" || PROJECT_TYPE == "Auto-detect" || PROJECT_TYPE == "Multiple" ? `### Directives Python
- Détectez et adhérez à la version Python spécifique utilisée
- Suivez la même organisation d'import trouvée dans les modules existants
- Correspondez aux approches de type hinting si utilisées dans la codebase
- Appliquez les mêmes modèles de gestion d'erreurs trouvés dans le code existant
- Suivez les mêmes modèles d'organisation de modules` : ""}

## Directives de contrôle de version

${VERSIONING == "Semantic" ? 
`- Suivez les modèles de versioning sémantique tels qu'appliqués dans la codebase
- Correspondez aux modèles existants pour documenter les changements brisants
- Suivez la même approche pour les notices de dépréciation` : ""}

${VERSIONING == "CalVer" ? 
`- Suivez les modèles de versioning calendaire tels qu'appliqués dans la codebase
- Correspondez aux modèles existants pour documenter les modifications
- Suivez la même approche pour mettre en évidence les changements significatifs` : ""}

${VERSIONING == "Custom" ? 
`- Correspondez au modèle de versioning exact observé dans la codebase
- Suivez le même format de changelog utilisé dans la documentation existante
- Appliquez les mêmes conventions de tagging utilisées dans le projet` : ""}

## Bonnes pratiques générales

- Suivez les conventions de nommage exactement telles qu'elles apparaissent dans le code existant
- Correspondez aux modèles d'organisation du code provenant de fichiers similaires
- Appliquez la gestion des erreurs cohérente avec les modèles existants
- Suivez la même approche de test que vue dans la codebase
- Correspondez aux modèles de logging du code existant
- Utilisez la même approche de configuration que vue dans la codebase

## Guidance spécifique au projet

- Analysez la codebase en détail avant de générer du code
- Respectez les limites architecturales existantes sans exception
- Correspondez au style et aux modèles du code environnant
- En cas de doute, priorisez la cohérence avec le code existant plutôt que les meilleures pratiques externes

2. Instructions d'analyse de codebase

Pour créer le fichier copilot-instructions.md, analysez d'abord la codebase pour :

  1. Identifier les versions technologiques exactes :

    • ${PROJECT_TYPE == "Auto-detect" ? "Détectez tous les langages de programmation, frameworks et bibliothèques en analysant les extensions de fichiers et les fichiers de configuration" : Concentrez-vous sur les technologies ${PROJECT_TYPE}}
    • Extrayez les informations de version précises des fichiers de projet, package.json, .csproj, etc.
    • Documentez les contraintes de version et les exigences de compatibilité
  2. Comprendre l'architecture :

    • Analysez la structure des dossiers et l'organisation des modules
    • Identifiez les limites de couches claires et les relations entre composants
    • Documentez les modèles de communication entre les composants
  3. Documenter les modèles de code :

    • Cataloguez les conventions de nommage pour différents éléments de code
    • Notez les styles et la complétude de la documentation
    • Documentez les modèles de gestion des erreurs
    • Cartographiez les approches de test et la couverture
  4. Noter les normes de qualité :

    • Identifiez les techniques d'optimisation de performance réellement utilisées
    • Documentez les pratiques de sécurité implémentées dans le code
    • Notez les fonctionnalités d'accessibilité présentes (si applicable)
    • Documentez les modèles de qualité du code évidents dans la codebase

3. Notes d'implémentation

Le fichier copilot-instructions.md final devrait :

  • Être placé dans le répertoire .github/copilot
  • Référencer seulement les modèles et normes qui existent dans la codebase
  • Inclure les exigences explicites de compatibilité de version
  • Éviter de prescrire des pratiques non évidentes dans le code
  • Fournir des exemples concrets de la codebase
  • Être exhaustif mais assez concis pour que Copilot l'utilise efficacement

Important : Incluez seulement la guidance basée sur les modèles réellement observés dans la codebase. Instruisez explicitement Copilot à prioriser la cohérence avec le code existant plutôt que les meilleures pratiques externes ou les nouvelles fonctionnalités du langage. "

Sortie attendue

Un fichier copilot-instructions.md exhaustif qui guidera GitHub Copilot pour produire du code parfaitement compatible avec vos versions technologiques existantes et suivra vos modèles établis et votre architecture.

Skills similaires