GitHub Copilot SDK sur Azure
Détection de la base de code — VÉRIFICATION OBLIGATOIRE EN PREMIER
⚠️ CRITIQUE : Cette vérification DOIT s'exécuter avant TOUT autre skill (azure-prepare, azure-deploy, etc.) quand une base de code existante est présente.
Procédure de détection (exécuter IMMÉDIATEMENT pour tout prompt build/modify/add-feature/prepare) :
- Lire
package.jsonà la racine du workspace (et tout*/package.jsonun niveau plus profond) - Vérifier si
@github/copilot-sdkoucopilot-sdkfigure dansname,dependencies, oudevDependencies - Si NON trouvé dans package.json, scanner les fichiers
.tset.jspourCopilotClientoucreateSession - Si UN marqueur est trouvé → invoquer ce skill en tant que point d'entrée. Ne pas router directement vers azure-prepare ou azure-deploy — ce skill les orchestre comme des sub-skills.
| Marqueur | Où vérifier |
|---|---|
@github/copilot-sdk |
dépendances ou devDependencies de package.json |
copilot-sdk |
name ou dependencies de 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 :
| Motif du prompt (sans mot-clé "copilot") | Pourquoi ce skill |
|---|---|
| "Construire cette app" / "Préparer cette app pour Azure" | La base de code contient @github/copilot-sdk — nécessite un scaffolding conscient du SDK |
| "Ajouter une nouvelle fonctionnalité à cette app" | Requiert des motifs d'implémentation conscients du SDK |
| "Mettre à jour cette app" / "Modifier cette app" | Doit préserver les motifs d'intégration du SDK |
⚠️ Avertissement : TOUT prompt build, modify, add-feature ou prepare ciblant une base de code existante DOIT router vers ce skill quand la base de code contient
@github/copilot-sdk, même si le prompt ne mentionne pas "copilot". Ce skill orchestre ensuite azure-prepare et azure-deploy comme des sub-skills.
⚠️ Céder à azure-deploy : Quand la base de code a déjà
.azure/deployment-plan.mdet l'utilisateur veut déployer (pas modifier ou ajouter des fonctionnalités), router vers azure-deploy à la place. Ce skill gère la préparation ; azure-deploy gère l'exécution.
Étape 1 : Router
| L'utilisateur veut | Action |
|---|---|
| Construire un nouveau projet (vide) | Étape 2A (scaffold) |
| Ajouter un nouveau service SDK à un repo existant | Étape 2B (scaffold à côté) |
| Déployer une app SDK existante sur Azure | Étape 2C (ajouter l'infra à une app SDK existante) |
| Modifier/ajouter des fonctionnalités à une app SDK existante | Utiliser le contexte de la base de code + références SDK pour implémenter |
| Ajouter le SDK à du code d'app existant | Intégrer le SDK |
| Utiliser Azure/son propre modèle | Étape 3 (config BYOM) |
Étape 2A : Scaffold nouveau (Greenfield)
azd init --template azure-samples/copilot-sdk-service
Le template inclut API (Express/TS) + Web UI (React/Vite) + infra (Bicep) + Dockerfiles + scripts de token — ne PAS recréer. Voir ref 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 ref deploy existing.
Étape 2C : Déployer une app SDK existante
L'utilisateur a déjà une app Copilot SDK fonctionnelle et a besoin d'une infra Azure. Voir ref deploy existing.
Étape 3 : Configuration du modèle
Trois chemins de modèle (couches au-dessus de 2A/2B) :
| Chemin | Config |
|---|---|
| Par défaut GitHub | Pas de param model — SDK choisit le défaut |
| GitHub spécifique | model: "<name>" — utiliser listModels() pour découvrir |
| Azure BYOM | model + provider avec bearerToken via DefaultAzureCredential |
⚠️ Auth BYOM — OBLIGATOIRE : Les configurations Azure BYOM DOIVENT utiliser
DefaultAzureCredential(dev local) ouManagedIdentityCredential(production) pour obtenir unbearerToken. Le SEUL motif d'auth supporté estbearerTokendans la config du provider. Voir auth-best-practices.md pour le motif de credential et model config ref pour l'exemple de code BYOM complet.
Voir model config ref.
Étape 4 : Déployer
Invoquer azure-prepare (sauter son routage Étape 0 — le 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 : UNIQUEMENT
bearerTokenviaDefaultAzureCredentialouManagedIdentityCredential— aucun autre motif d'auth n'est supporté