Intégration et Configuration de dart_skills_lint

Utilisez cette skill pour vérifier l'état du repository, mettre à jour les références épinglées, gérer les configurations centralisées, implémenter des suites de tests de validation efficaces et produire des commandes clean pull request pour dart_skills_lint.

Vérification du Repository en Pré-Vol

Avant d'initier toute modification ou d'exécuter les mises à jour de dépendances, assurez-vous que le repository est dans un état propre et sûr :

1. Exécutez git status pour confirmer que le repository n'a aucun travail en cours.
2. Si c'est propre, consultez la branche de suivi primaire (par ex. main ou master).
3. Mise à jour en avance rapide à partir du remote appartenant à l'organisation faisant autorité.
4. Si les hooks post-checkout signalent des mises à jour du moteur, exécutez les utilitaires de synchronisation nécessaires (comme gclient sync) pour garantir la cohérence avant de continuer.

Workflow de Gestion des Dépendances

Lors de la mise à jour de dart_skills_lint au sein d'un workspace ou d'un projet standalone :

1. Localisez le pubspec.yaml cible définissant la dépendance.
2. Mettez à jour la référence de commit Git épinglée directement dans le champ ref.
3. Synchronisez le lockfile nativement en utilisant le gestionnaire de paquets de l'environnement.

Exemple : Dépendance Git Épinglée

  dart_skills_lint:
    git:
      url: https://github.com/flutter/skills
      path: tool/dart_skills_lint
      ref: e4497873950727ee781fa411c1a2f624b1ec50c6

Schéma de Configuration Centralisée

Configurez les règles et les chemins cibles globalement via dart_skills_lint.yaml. Définissez toujours les chemins relatifs au contexte d'exécution racine du repository. Assurez-vous que les règles au niveau du répertoire sont correctement orientées dans une carte rules imbriquée.

Implémentation du Schéma Standard

dart_skills_lint:
  rules:
    check-relative-paths: error
    check-absolute-paths: error
    check-trailing-whitespace: error
  directories:
    - path: ".agents/skills"

Patterns d'Implémentation des Tests de Validation

Pour centraliser la gestion des règles, chargez dynamiquement Configuration via ConfigParser.loadConfig et fournissez-la à validateSkills.

Si les suites de tests s'exécutent dans des environnements simples avec des racines d'exécution stables, omettez entièrement le paramètre skillDirPaths pour hériter nativement des chemins cibles définis dans la configuration YAML.

Pattern d'Isolation Absolue : Si les harnais de tests manipulent les répertoires de travail d'exécution runtime (comme les frameworks CI exécutant des tests dans des sous-dossiers de paquets), garantissez la résilience des chemins en résolvant les fichiers de configuration de manière absolue en utilisant des contextes de répertoires dynamiques (par ex. repoRoot.path). Injectez explicitement un ciblage absolu skillDirPaths ; les règles globales définies sous la carte rules: s'appliquent inconditionnellement indépendamment de l'utilisation explicite du chemin cible.

Lors de la mise à jour d'un bloc de validation existant, auditez explicitement tous les commentaires TODO ou de suivi adjacents. Si le commentaire décrit un refactoring du chargement de configuration ou fait référence à des problèmes résolus par cette mise à jour, supprimez entièrement le bloc de commentaire.

Workflow de Validation Principale

import 'package:path/path.dart' as path;
import 'package:dart_skills_lint/dart_skills_lint.dart';

const String _configFileName = 'dart_skills_lint.yaml';

test('Validate Repository Skills', () async {
  // Use dynamic absolute resolution references to guarantee CI stability
  final Configuration config = await ConfigParser.loadConfig(
    path: path.join(repoRoot.path, 'path', 'to', _configFileName),
  );
  final bool isValid = await validateSkills(
    skillDirPaths: [skillsDirectory], // Explicit absolute targeting
    config: config,
  );
  expect(isValid, isTrue);
});

Élimination de la Surcharge Dupliquée dans les Blocs Secondaires

Les blocs de tests secondaires appliquant des règles personnalisées spécialisées sans charger la configuration partagée doivent fournir les chemins cibles explicitement. Pour prévenir la surcharge d'exécution dupliquée, mappez explicitement toutes les règles intégrées enregistrées par défaut à AnalysisSeverity.disabled.

test('Custom Rule Validation', () async {
  final bool isValid = await validateSkills(
    skillDirPaths: ['path/to/skills'],
    customRules: [MyCustomRule()],
    resolvedRules: {
      'check-absolute-paths': AnalysisSeverity.disabled,
      'check-relative-paths': AnalysisSeverity.disabled,
      'check-trailing-whitespace': AnalysisSeverity.disabled,
      'description-too-long': AnalysisSeverity.disabled,
      'disallowed-field': AnalysisSeverity.disabled,
      'invalid-skill-name': AnalysisSeverity.disabled,
      'valid-yaml-metadata': AnalysisSeverity.disabled,
    },
  );
  expect(isValid, isTrue);
});

Sortie Finale Attendue : Commande de Création de Pull Request

Concluez les tâches en mettant en scène le travail vérifié sur une branche locale descriptive (suffixée par la date au format YYYY-MM-DD), en validant les modifications avec un message de commit concis et standard, et en produisant une commande gh pr create entièrement exécutable.

Découverte et Remplissage du Template de Pull Request

Pour assurer la conformité de la mise en forme, consultez toujours le template natif de pull request du repository cible avant de générer le corps de la soumission :

1. Localiser le Template : Recherchez les fichiers de template dans .github/, .github/PULL_REQUEST_TEMPLATE/, ou la racine du projet. Les noms de fichiers courants incluent PULL_REQUEST_TEMPLATE.md ou pull_request_template.md.
2. Extraire la Structure : Lisez le fichier découvert pour identifier les en-têtes markdown requis, les placeholders de description, les règles de citation d'issues et les checklists.
3. Remplir le Contenu : Remplacez les placeholders par un contexte clair résumant les mises à jour de dépendances, les configurations créées et les blocs de règles optimisés. Cochez toutes les cases de vérification applicables ([x]).
4. Fallback : Si aucun template natif n'existe, construisez un corps de soumission clean contenant un bref résumé des modifications, les liens d'issues pertinents et les résultats d'analyse statique/tests.

Structure de la Commande de Sortie

gh pr create \
  --title "Update dart_skills_lint dependency to <hash> and centralize config" \
  --body "<populated repository template content>"

Conseils pour le Repository Flutter (flutter/flutter)

Lors de l'opération directement dans la base de code Flutter principale :

• Résolution de Paquets : Exécutez bin/flutter pub get à la racine du repository au lieu de dart pub get pour éviter les erreurs de version SDK incompatible.
• Intégrité des Checksums : La mise à jour des dépendances brise nativement les hashes de checksum pubspec autogénérés. Recalculez toujours et mettez à jour les hashes obsolètes en exécutant bin/flutter update-packages --update-hashes.
• Orchestration des Tests : Exécutez les tests unitaires du repository à partir du contexte racine : bin/flutter test dev/tools/test/validate_skills_test.dart.
• Vérification : Assurez-vous de zéro avertissement d'analyse statique en utilisant dart analyze --fatal-infos et formatez tout le code source proprement avec dart format.