
de keystore221
Exécute les vérifications pré-expédition et (si configuré) effectue ou conseille la fusion, le déploiement et la vérification canary ; sinon, produit un plan consultatif pour révision humaine.
Fournit un flux de clôture de livraison qui audite la préparation pré-expédition, détecte la configuration CI/CD, et exécute soit le flux de fusion/déploiement/canary lorsque le projet est adapté, soit génère des commandes consultatives détaillées dans le cas contraire. La compétence inclut des ancres de conformité explicites, des étapes de liste de contrôle et une gestion des exceptions pour la protection des branches et les échecs canary.
Utilisez cette compétence lors de la préparation d'une version après que la revue de code et l'assurance qualité (QA) sont terminées (ou partiellement terminées). Elle doit être invoquée comme dernière étape automatisée avant la mise en production, particulièrement lorsque les projets exposent des commandes de test/déploiement et que l'agent a la permission de les exécuter. Dans d'autres projets, elle fonctionne en mode consultatif et fournit les commandes exactes à exécuter manuellement.
Conçu pour les agents ayant un accès shell/CI (agents compatibles tmux/CLI ou automatisation côté serveur). Fonctionne mieux là où l'agent peut exécuter les commandes de test et de déploiement détectées ou générer une sortie consultative pour les opérateurs humains.
ks-ship est une compétence de clôture de livraison provenant du framework KeyStore qui exécute des vérifications pré-expédition, détecte la configuration CI/CD, exécute ou conseille des flux de fusion/déploiement/canary, et produit un rapport d'expédition structuré. Elle n'a pas de scripts intégrés — toute la logique est en bash inline dans le SKILL.md. Les préoccupations de sécurité incluent l'utilisation d'eval sur les commandes détectées (test_cmd, deploy_cmd), ce qui introduit un risque d'injection de shell, et l'écriture de télémétrie dans le répertoire local .keystone/. La compétence est bien structurée avec des modes clairs (conseil vs adapté au projet), une gestion des exceptions et un contrat de décision, mais repose sur un CLI 'keystone' personnalisé que la plupart des projets n'auront pas.
Compétence bien architecturée avec une séparation claire des modes et des ancres de conformité. L'utilisation d'eval sur les commandes détectées est la principale préoccupation de sécurité (-12 pour le risque d'injection de shell). La dépendance au CLI keystone limite l'utilité globale. La télémétrie est locale uniquement, donc déduction mineure (-5). Pas de curl|bash, pas d'identifiants codés en dur, pas de commandes destructrices sans garde-fous. Le git merge --abort en cas de conflit est une bonne mesure de sécurité.