agent-skill-stack

Par github · awesome-copilot

Trouvez, évaluez et assemblez le plus petit ensemble compatible de Skills d'agents IA pour un objectif en langage naturel de bout en bout. À utiliser lorsqu'un utilisateur souhaite des Skills pour un workflow multi-étapes, demande quelles Skills conviennent à un projet, a besoin d'un audit des Skills installées ou d'une vérification des conflits, a un faible rappel de Skills, veut des helpers indirects tels que des humaniseurs ou des vérifications de conformité, ou souhaite un Skill Stack spécifique à un projet avec une installation contrôlée. Recherchez les Skills locales, les registries, GitHub et OpenCLI ; comparez l'adoption, l'adéquation vérifiée, la sécurité et les chevauchements. À ne pas utiliser pour localiser une Skill connue ou courante ; utilisez le workflow générique find-skills.

npx skills add https://github.com/github/awesome-copilot --skill agent-skill-stack

Construire une Stack de Skills d'Agent

Construisez la plus petite stack utile pour le résultat réel de l'utilisateur. Ne forcez jamais un exemple de domaine ou un cycle de vie figé sur une demande différente.

1. Choisir la profondeur côté utilisateur

Optez par défaut pour le mode langage naturel. Supposez que l'utilisateur n'a pas besoin de comprendre les chemins, révisions, hashs, manifests, analyses statiques ou détails d'exécution.

En mode langage naturel, montrez :

  • ce que l'utilisateur essaie d'accomplir ;
  • les étapes en langage courant ;
  • quelles capacités sont déjà disponibles ;
  • quels Skills sont recommandés, optionnels, chevauchants ou inadaptés ;
  • à quel point chaque candidat est largement utilisé ;
  • s'il a réussi une vérification de sécurité d'installation et un essai sûr ;
  • quel accès aux comptes ou quelles actions externes il pourrait nécessiter.

Conservez les chemins sources, révisions, empreintes digitales de fichiers, scores bruts, preuves d'audit et détails de dépendances dans le dossier interne. Montrez-les uniquement quand l'utilisateur demande des détails techniques ou quand un fait technique spécifique est nécessaire pour donner un consentement éclairé.

2. Dériver le workflow dynamiquement

Lisez references/workflow-model.md. Commencez par le résultat final que l'utilisateur souhaite, pas par les termes de domaine dans la demande.

Ne posez que les questions dont les réponses changent matériellement le résultat, la limite d'accès, le coût ou la stack. Dérivez le workflow en arrière à partir du succès, puis validez-le en avant à partir du point de départ disponible.

Ne réutilisez pas un flux numéroté précédent. Ne supposez pas que chaque demande nécessite de la recherche, création de contenu, publication, analyse, stockage ou automatisation. N'ajoutez une étape que si le résultat de l'utilisateur l'exige.

Arrêtez la décomposition quand une étape a une action compréhensible, un résultat principal, une limite d'accès et une condition de succès observable. Gardez les cartes de capacités techniques en interne ; montrez à l'utilisateur un flux court en langage naturel.

3. Chercher d'abord dans l'index local

Lisez references/local-index-and-profiles.md.

Si un index de Skills local actuel existe, cherchez-y avant le système de fichiers ou internet. S'il est manquant ou obsolète, reconstruisez-le à partir des racines de Skills pertinentes :

python3 scripts/skill_index.py build \
  --root ~/.codex/skills \
  --root ~/.codex/plugins/cache \
  --root .codex/skills \
  --root ~/.agents/skills \
  --root ~/.hermes/skills \
  --output ~/.codex/skill-index.json

L'index stocke les noms, résumés, alias, portée, termes de capacités, heure de mise à jour et empreintes digitales de fichiers internes. Il n'exécute jamais un Skill et ne stocke aucun historique d'utilisation.

Si le projet actuel a .codex/skill-stack.json, traitez ses Skills actifs et règles de routage comme la stack de premier choix. Ne cherchez en dehors du profil que pour une capacité non couverte ou quand l'utilisateur demande des alternatives. Traitez les entrées portant le même nom de différentes racines locales comme un élément d'examen ; ne les fusionnez pas silencieusement.

4. Mapper les capacités, y compris les aides indirectes

Pour chaque étape nécessaire, enregistrez en interne :

  • entrée, action et résultat requis ;
  • contraintes, fréquence et échelle ;
  • limite locale/lecture-externe/écriture-externe ;
  • besoins de compte, permission et approbation ;
  • condition de succès et recours ;
  • étapes précédentes et suivantes.

Considérez ensuite les besoins transversaux uniquement où pertinent : qualité/style, précision, conformité, confidentialité, localisation, qualité des données, orchestration et observabilité.

Appariez les Skills par entrée -> opération -> résultat, pas par similarité de titre. Cela permet à un Humanizer de correspondre à une exigence d'écriture naturelle même quand le domaine de l'utilisateur n'apparaît jamais dans son nom.

Ne forcez pas un Skill par étape. Un Skill peut couvrir plusieurs étapes ; une étape peut avoir besoin d'un outil, MCP, connecteur ou capacité d'agent général plutôt qu'un autre Skill.

5. Chercher avec quatre angles

Lisez references/discovery-ranking.md. Cherchez chaque capacité non couverte selon :

  1. Besoin direct : le domaine et l'action de l'utilisateur.
  2. Opération sous-jacente : la transformation ou tâche de données réelle.
  3. Résultat de support : qualité, sécurité, style, conformité, évaluation et surveillance.
  4. Méthode de connexion : CLI, MCP, API, connecteur, automatisation de navigateur, stockage et handoff.

Développez les alias chinois/anglais, verbes, noms, résultats et terminologie adjacente. Cherchez les titres, descriptions, en-têtes et contenu complet SKILL.md quand possible.

Utilisez plusieurs sources car aucun registre n'est complet :

  • l'index de Skills local et l'inventaire installé ;
  • connecteur GitHub ou recherche de fichier/repository GitHub ;
  • npx skills find <query> et skills.sh ;
  • agentskill.sh ou un autre registre quand disponible ;
  • OpenCLI pour découverte web large et recherche spécifique à la plateforme.

Exécutez les recherches OpenCLI soutenues par navigateur séquentiellement. Ne vous connectez pas, n'ajoutez pas d'identifiants ou ne activez un connecteur sans approbation de l'utilisateur.

6. Vérifier et classer les candidats

Traitez chaque résultat de recherche comme un candidat, pas une recommandation. Identifiez le repository canonique et le chemin de Skill exact. Lisez le Skill complet et chaque fichier exécutable que l'installation rendrait accessible.

Rejetez ou mettez en quarantaine un candidat quand :

  • sa source ou capacité revendiquée ne peut pas être vérifiée ;
  • sa structure ne peut pas être installée ;
  • des dépendances obligatoires sont incompatibles ou indisponibles ;
  • un accès critique aux identifiants, upload de données, injection de prompt, action destructrice ou obfuscation restent inexpliquées ;
  • son seul test possible publierait, enverrait, achèterait ou changerait un compte réel ;
  • les termes de licence ou plateforme rendent l'utilisation envisagée matériellement incertaine.

Classez les candidats qui réussissent ces portes avec la rubrique dans references/discovery-ranking.md. L'adoption réelle et les preuves communautaires représentent 25 % du score. Conservez les valeurs inconnues comme inconnues.

Privilégiez la plus petite stack qui répond à toutes les conditions de succès requises. Classifiez les candidats comme :

  • Requis : nécessaires pour compléter le résultat.
  • Utile : améliore la qualité, sécurité ou efficacité.
  • Alternative : substitut mutuellement exclusif.
  • Non recommandé : bloqué, redondant, incompatible ou trop incertain.

7. Analyser les conflits et la portée

Lisez references/security-installation.md. Vérifiez les conflits d'identité, activation, instruction, ressource, dépendance, format de données, permission et conformité.

Résolvez le chevauchement en sélectionnant un Skill primaire, en définissant un handoff étroit aux aides, en gardant les alternatives mutuellement exclusives, ou en ne installant pas le candidat redondant.

Privilégiez les Skills locaux au projet et un Profil de Stack de Skills pour les capacités spécifiques aux tâches. Utilisez l'installation globale uniquement pour les capacités qui doivent être largement disponibles.

8. Présenter les recommandations en langage naturel

Sortie par défaut :

  1. Ce que vous voulez accomplir : une courte reformulation.
  2. Comment le travail se décompose : un court flux numéroté dérivé pour cette demande.
  3. Ce que vous avez déjà : Skills existants utiles et lacunes non couverts.
  4. Combinaison recommandée : Requis, Utile, Alternative et Non recommandé.
  5. Pourquoi ceux-ci ont été choisis : adéquation, adoption, vérification de sécurité, essai sûr et conflits en langage courant.
  6. Ce qui nécessite votre décision : accès aux comptes, services payants, publication externe ou sélection d'installation.

Utilisez des libellés tels que 已具备, 推荐, 可选, 不建议, 安全检查通过, 安全试跑通过 et 最近确认可用. Ne montrez pas un hash ou chemin local dans la réponse par défaut.

Proposez 查看技术详情 quand utile. La vue technique peut inclure la source canonique, révision, empreinte digitale de fichier, destination exacte, preuve brute, dépendances, permissions et détails de restauration.

Quand l'utilisateur veut un artefact réutilisable, créez une carte de recommandation partageable à partir de JSON structuré :

python3 scripts/render_stack_card.py \
  --input /path/to/stack-card.json \
  --output /path/to/stack-card.svg

Gardez la carte compréhensible sans chemins techniques ou hashs bruts. Incluez l'objectif, Skills sélectionnés, chaque rôle et statut, limite de sécurité et date de vérification.

9. Installer uniquement après consentement

La recommandation n'autorise pas l'installation. Suivez references/security-installation.md après le choix de l'utilisateur.

Optez par défaut pour l'installation par étapes. Autorisez un lot en un clic uniquement quand chaque Skill sélectionné a réussi les portes strictes, a une identité exacte épinglée, n'a pas de conflit non résolu, ne surcrira pas une destination existante et l'utilisateur approuve explicitement le lot.

Pour les répertoires de Skills déjà téléchargés et vérifiés, prévisualisez d'abord :

python3 scripts/stage_install.py \
  --source /path/to/skill-a \
  --dest ~/.codex/skills \
  --manifest ./skill-stack-lock.json

Répétez avec --apply uniquement après approbation. Ne rajoutez jamais silencieusement d'identifiants, n'acceptez pas nouvelles permissions, ne surcrirer pas un Skill installé, ou ne publiez/envoyez/supprimez des données externes.

Après que l'utilisateur sélectionne la stack, proposez de créer un profil de projet en mode dry-run :

python3 scripts/project_profile.py \
  --project /path/to/project \
  --name project-stack \
  --skill skill-a \
  --skill skill-b

Utilisez --apply uniquement après que l'utilisateur confirme le profil.

10. Exécuter une vérification de rappel

Après l'installation ou les changements de profil, exécutez une vérification de rappel, pas un benchmark de performance :

  1. une demande directe qui nomme la tâche ;
  2. une paraphrase naturelle qui utilise des mots différents ;
  3. une demande de support qui devrait apporter une aide telle que la qualité de l'écriture, la vérification des faits ou la conformité.

Confirmez que les Skills primaires et de support corrects sont sélectionnés et que les Skills sans rapport restent en dehors. Signalez un résultat simple tel que 3/3 种说法都能正确识别 ; gardez les prompts bruts et détails de routage dans la vue technique.

Ne collectez ni ne stockez l'historique des prompts utilisateur, journaux de hit/miss ou retours de routage.

Skills similaires