Efficacité GitHub Codespaces

Utilise cette compétence comme point d'entrée léger pour les travaux d'efficacité GitHub Codespaces. Inspecte le repo, identifie les gaspillages, et charge uniquement les références nécessaires.

Si .devcontainer/ n'existe pas encore, charge references/codespaces.md et définis une baseline avant de procéder aux étapes ci-dessous.

Utilise cette compétence quand

• L'utilisateur veut accélérer le démarrage de Codespaces ou réduire les coûts de Codespaces.
• Le repo a une configuration .devcontainer/ ou des questions explicites de configuration Codespaces.
• L'utilisateur demande de l'optimisation de devcontainer, du dimensionnement de machine, une stratégie de prebuild, ou des conseils sur idle-timeout.
• L'utilisateur configure Codespaces pour la première fois ou a besoin d'aide pour créer un .devcontainer/ de zéro.

Charge uniquement ce dont tu as besoin

• references/codespaces.md — devcontainer, dimensionnement de machine, prebuild, conseils sur idle-timeout, et rapports.
• references/review-rubric.md — charge uniquement pour les passes de review.

Workflow principal

1. Mesure d'abord

find .devcontainer -maxdepth 2 -type f
gh codespace list
repo=$(gh repo view --json nameWithOwner --jq .nameWithOwner)
gh api "/repos/$repo/codespaces/machines"

Si l'authentification gh échoue ou que l'utilisateur n'a pas le scope d'admin repo, procède avec une analyse statique des fichiers .devcontainer/ ; marque les recommandations de type de machine et de prebuild comme non vérifiées.

Cherche : image devcontainer >2 GB ou plus de 10 features, type de machine plus grand que les données d'utilisation ne le justifient, devcontainer-lock.json manquant (recommande l'ajout — de nombreux repos précèdent le support des fichiers lock), prebuilds à portée trop large, et idle timeout décalé par rapport aux patterns d'utilisation.

2. Applique des garde-fous

Vérifie chaque correctif proposé par rapport à ces règles avant de le recommander :

1. Ne supprime pas les outils que l'équipe utilise tous les jours — écarte tout correctif qui retire des outils ou extensions de développement requis.
2. Ne suppose pas que plus petit est toujours mieux — équilibre le coût de la machine contre l'expérience développeur et le débit.
3. Ne transforme pas le devcontainer en image de production — écarte tout correctif qui ajoute des dépendances de production uniquement sauf si l'équipe l'exige explicitement.
4. Les changements incrémentaux sont préférés — une baseline greenfield convient uniquement quand aucun .devcontainer/ n'existe ; signale (ne supprime pas) les changements qui restructurent une configuration existante.
5. Les changements de repo restent séparés des paramètres org — divise tout correctif qui mélange des fichiers éditables par le repo avec des paramètres Codespaces au niveau org ou utilisateur en deux recommandations distinctes.

3. Sélectionne les 3 meilleurs correctifs

Parmi les six candidats ci-dessous, garde uniquement ceux soutenus par des preuves d'audit de l'étape 1 et passant tous les garde-fous de l'étape 2. Classe les survivants par économies mensuelles estimées (USD). Sélectionne tous les candidats qui remplissent les deux critères, jusqu'à un maximum de 3.

1. Réduis devcontainer — supprime les features, paquets, ou extensions non nécessaires au travail de développement quotidien ; vise une image <2 GB et moins de 10 features
2. Dimensionne correctement le type de machine — adapte aux patterns d'utilisation observés ; si les données ne sont pas disponibles, énonce les hypothèses explicitement
3. Limite l'étendue des prebuilds — active pour la branche par défaut, les branches release/* actives dans les 14 derniers jours, et les branches avec plus de 5 Codespaces par semaine ; désactive pour tous les autres
4. Affine l'idle timeout — 30 min par défaut ; 15 min si la plupart des sessions se terminent avant 30 min ; 60 min si la plupart des sessions s'exécutent plus longtemps
5. Supprime les extensions inutilisées ou les règles de port-forwarding
6. Réduis la taille de l'image devcontainer et améliore le cache des couches

4. Valide

• Démarre un Codespace de test pour confirmer que les changements devcontainer se construisent et démarrent correctement.
• Valide le dimensionnement de la machine par rapport à l'utilisation observée quand la télémétrie est disponible ; sinon marque comme non vérifié.
• Traite les échecs de construction ou de démarrage inattendus comme de vrais bugs même quand la configuration semble correcte.

Résultat obligatoire

Sources de gaspillage : [principaux drivers de coût ou de temps de démarrage]

Correctifs proposés : [top 3 changements soutenus par des preuves d'audit et passant les garde-fous]

Validation : [prouvé en direct / statique uniquement / risque restant]

Impact :

• Temps de démarrage : [attendu] / [mesuré si disponible]
• Coût mensuel : [attendu] / [mesuré si disponible]
• Utilisation des ressources : [attendu] / [mesuré si disponible]

Références

• references/codespaces.md
• references/review-rubric.md — charge quand tu reviews le travail d'efficacité complété