GitHub Copilot SDK sur Azure
Détection de codebase — CONTRÔLE OBLIGATOIRE EN PREMIER
⚠️ CRITIQUE : Ce contrôle DOIT s'exécuter avant TOUT autre skill (azure-prepare, azure-deploy, etc.) quand une codebase existante est présente.
Procédure de détection (exécuter IMMÉDIATEMENT pour tout prompt de déploiement/modification/ajout de fonctionnalité) :
- Lire
package.jsonà la racine du workspace (et tout*/package.jsonun niveau en profondeur) - Vérifier si
@github/copilot-sdkoucopilot-sdkapparaît dansname,dependencies, oudevDependencies - Si NON trouvé dans package.json, scanner les fichiers
.tset.jspourCopilotClientoucreateSession - Si UN marqueur est trouvé → invoquer ce skill comme point d'entrée. Ne pas router directement vers azure-prepare ou azure-deploy — ce skill les orchestre comme sub-skills.
| Marqueur | Où vérifier |
|---|---|
@github/copilot-sdk |
Dépendances ou devDependencies dans package.json |
copilot-sdk |
Nom ou dépendances dans package.json |
CopilotClient |
Fichiers source (.ts, .js) |
createSession + sendAndWait |
Fichiers source (.ts, .js) |
Prompts génériques qui DOIVENT déclencher ce skill quand des marqueurs sont détectés :
| Pattern de prompt (sans mot-clé "copilot") | Pourquoi ce skill |
|---|---|
| "Déployer cette app sur Azure" | La codebase contient @github/copilot-sdk |
| "Ajouter une nouvelle fonctionnalité à cette app" | Requiert des patterns d'implémentation conscients du SDK |
| "Mettre à jour cette app" / "Modifier cette app" | Doit préserver les patterns d'intégration du SDK |
| "Mettre en production" | Nécessite une infrastructure et une gestion de tokens spécifiques à copilot |
⚠️ Attention : TOUT prompt ciblant une codebase existante — déploiement, modification, ajout de fonctionnalité, mise à jour, amélioration — DOIT router vers ce skill quand la codebase contient
@github/copilot-sdk, même si le prompt ne mentionne pas "copilot". Ce skill orchestre ensuite azure-prepare et azure-deploy comme sub-skills.
Étape 1 : Routage
| L'utilisateur veut | Action |
|---|---|
| Créer nouveau (projet vide) | Étape 2A (scaffold) |
| Ajouter nouveau service SDK à un repo existant | Étape 2B (scaffold à côté) |
| Déployer une app SDK existante sur Azure | Étape 2C (ajouter infra à l'app SDK existante) |
| Modifier/ajouter des fonctionnalités à l'app SDK existante | Utiliser le contexte de codebase + références SDK pour implémenter |
| Ajouter SDK au code app existant | Intégrer SDK |
| Utiliser Azure/modèle personnel | Étape 3 (config BYOM) |
Étape 2A : Scaffold nouveau (terrain vierge)
azd init --template azure-samples/copilot-sdk-service
Le template inclut API (Express/TS) + UI Web (React/Vite) + infra (Bicep) + Dockerfiles + scripts de tokens — ne PAS recréer. Voir référence SDK.
Étape 2B : Ajouter un service SDK à un repo existant
L'utilisateur a du code existant et veut un nouveau service Copilot SDK à côté. Scaffolder le template dans un répertoire temporaire, copier le service API + infra dans le repo de l'utilisateur, adapter azure.yaml pour inclure les services existants et nouveaux. Voir référence déploiement existant.
Étape 2C : Déployer une app SDK existante
L'utilisateur a déjà une app Copilot SDK fonctionnelle et a besoin d'infra Azure. Voir référence déploiement existant.
Étape 3 : Configuration du modèle
Trois chemins de modèle (couches au-dessus de 2A/2B) :
| Chemin | Config |
|---|---|
| Défaut GitHub | Pas de paramètre model — le SDK choisit le défaut |
| Spécifique GitHub | model: "<name>" — utiliser listModels() pour découvrir |
| BYOM Azure | model + provider avec bearerToken via DefaultAzureCredential |
⚠️ Auth BYOM — OBLIGATOIRE : Les configurations BYOM Azure DOIVENT utiliser
DefaultAzureCredential(dev local) ouManagedIdentityCredential(production) pour obtenir unbearerToken. Le SEUL pattern d'auth supporté estbearerTokendans la config du provider. Voir auth-best-practices.md pour le pattern de credential et référence model config pour l'exemple de code BYOM complet.
Voir référence model config.
Étape 4 : Déploiement
Invoquer azure-prepare (ignorer son routage Étape 0 — scaffolding est fait) → azure-validate → azure-deploy dans l'ordre.
Règles
- Lire
AGENTS.mddans le repo de l'utilisateur avant les changements - Docker requis (
docker info) - Auth BYOM : SEUL
bearerTokenviaDefaultAzureCredentialouManagedIdentityCredential— aucun autre pattern d'auth n'est supporté