Compétences incident-response-smart-fix
📦

incident-response-smart-fix

Sûr

Résoudre les incidents avec une orchestration IA multi-agents

Les incidents de production nécessitent une investigation coordonnée à travers plusieurs systèmes et domaines. Ce workflow orchestre des agents IA spécialisés via un pipeline éprouvé en cinq phases pour diagnostiquer les causes racines, implémenter des correctifs et prévenir la récurrence.

Prend en charge: Claude Codex Code(CC)
🥉 74 Bronze
1

Télécharger le ZIP du skill

2

Importer dans Claude

Allez dans Paramètres → Capacités → Skills → Importer un skill

3

Activez et commencez à utiliser

Tester

Utilisation de "incident-response-smart-fix". Utilisateurs confrontés à des erreurs de timeout sur la page de paiement avec 500+ erreurs par heure

Résultat attendu:

Cause racine identifiée : Index de base de données manquant sur la colonne user_id causant des temps de requête de 5 secondes. Correctif implémenté : Ajout d'un index réduisant le temps de requête à 50ms, ajout d'un cache Redis pour les profils utilisateurs. Tests : 24 tests unitaires, 8 tests d'intégration, tous passants. Monitoring : Alertes configurées pour la latence p95 des requêtes et le taux de succès du cache. Déploiement : Rollout canary à 5% du trafic avec critères d'abandon définis.

Utilisation de "incident-response-smart-fix". TypeError Cannot read property map of undefined affectant les utilisateurs Safari iOS 14

Résultat attendu:

Cause racine identifiée : L'API retourne null au lieu d'un tableau vide quand il n'y a pas de résultats. Correctif implémenté : Ajout de vérifications null et de guards de typage dans le frontend, mise à jour du backend pour retourner un tableau vide selon le contrat API. Tests : Suite de tests cross-browsers passante incluant Safari iOS 14. Prévention : Vérifications strictes de null TypeScript activées, spéc OpenAPI mise à jour pour documenter le type de retour tableau.

Audit de sécurité

Sûr
v1 • 2/25/2026

Static analyzer detected 62 patterns but all are FALSE POSITIVES. The skill consists entirely of Markdown documentation files (.md) describing incident response workflows. Patterns flagged as 'external commands' are bash code blocks in documentation, not executable code. 'Windows SAM database' and 'weak crypto' references appear in example output templates, not actual implementations. No executable code, network calls, or file system operations present.

2
Fichiers analysés
871
Lignes analysées
0
résultats
1
Total des audits
Aucun problème de sécurité trouvé
Audité par: claude

Score de qualité

38
Architecture
100
Maintenabilité
87
Contenu
50
Communauté
100
Sécurité
91
Conformité aux spécifications

Ce que vous pouvez construire

Investigation et correction d'erreurs de production

À utiliser lorsque des erreurs de production impactent les utilisateurs et nécessitent un diagnostic et une résolution rapides. Le workflow analyse les signatures d'erreurs, identifie la cause racine via git bisect et l'analyse de code, implémente un correctif avec tests, et vérifie l'absence de régressions avant déploiement.

Dégradation de performance cross-systèmes

À utiliser lorsque les problèmes de performance s'étendent sur plusieurs services ou couches (base de données, application, cache). Le workflow coordonne les optimiseurs de base de données, les ingénieurs performance et les spécialistes DevOps pour identifier les goulots d'étranglement et implémenter des optimisations avec monitoring.

Remédiation de vulnérabilités de sécurité

À utiliser lorsque des scans de sécurité identifient des vulnérabilités nécessitant des modifications de code. Le workflow route vers des spécialistes sécurité pour l'implémentation du correctif, ajoute des tests de sécurité, effectue une validation par tests de pénétration et documente les améliorations de sécurité.

Essayez ces prompts

Correction rapide de bug avec tests basiques 
Analysez cette erreur et implémentez un correctif : [coller le message d'erreur]. Exécutez des tests basiques pour vérifier que le correctif fonctionne. Concentrez-vous sur la résolution du problème immédiat avec des changements minimaux.
Réponse aux incidents standard avec vérification complète 
Investiguez cet incident de production : [décrire les symptômes]. Suivez le workflow en quatre phases : (1) analyser les traces d'erreurs et logs, (2) identifier la cause racine avec git bisect et l'analyse de code, (3) implémenter un correctif avec des tests complets, (4) exécuter une suite de tests de régression et une validation de performance. Inclure un plan de rollback.
Incident haute sévérité avec mesures de prévention 
Répondez à cet incident critique : [décrire l'impact]. Exécutez le workflow complet en cinq phases incluant la prévention à long terme. Ajoutez des règles d'analyse statique, des améliorations du système de typage, des alertes de monitoring et créez un postmortem. Configurez un déploiement canary avec des métriques de succès et des critères d'abandon.
Coordination multi-domaines pour problèmes complexes 
Orchestrez la résolution de ce problème cross-systèmes : [décrire les systèmes impliqués]. Coordonnez les agents en séquence : [lister les agents]. Passez un contexte explicite entre les phases incluant le travail terminé, les découvertes clés et les tâches restantes. Vérifiez les points d'intégration et le comportement de bout en bout.

Bonnes pratiques

  • Toujours identifier la cause racine avant d'implémenter des correctifs - utiliser git bisect et les données d'observabilité pour comprendre le mécanisme de défaillance, pas seulement les symptômes
  • Implémenter des mesures de prévention pour les incidents haute sévérité - ajouter des règles d'analyse statique, des améliorations de typage et du monitoring pour détecter les problèmes similaires tôt
  • Documenter les plans de rollback et les métriques de succès avant déploiement - définir des critères d'abandon clairs et monitorer les métriques clés pendant le rollout canary

Éviter

  • Corriger les symptômes sans comprendre la cause racine - cela conduit à des problèmes récurrents et à de la dette technique
  • Sauter les phases de vérification pour la rapidité - des tests inadéquats causent des régressions et étendent le temps moyen de résolution
  • Implémenter des correctifs sans mesures de prévention - le même motif de vulnérabilité réapparaîtra dans d'autres emplacements du code

Foire aux questions

Comment choisir le niveau de vérification approprié ?
Utilisez minimal pour les changements à faible risque comme la documentation ou les corrections cosmétiques. Utilisez standard pour la plupart des bugs de production. Utilisez comprehensive pour les problèmes de sécurité, problèmes de performance ou incidents à fort impact affectant les revenus ou de nombreux utilisateurs.
Que faire si le problème s'étend sur plusieurs domaines technologiques ?
Utilisez le pattern de coordination multi-domaines. Séquencez les agents spécialistes (par exemple : database-optimizer puis performance-engineer puis devops-troubleshooter) avec un passage de contexte explicite entre chaque phase en utilisant le template de passage de contexte.
Comment gérer les problèmes dans des langages sans agent spécialiste ?
Routez vers les agents general debugger et code-reviewer pour analyse. Pour l'implémentation, utilisez des agents disponibles avec des paradigmes similaires ou implémentez manuellement en suivant la conception de correctif fournie par la phase de review.
Ce workflow peut-il gérer les incidents nécessitant une action immédiate ?
Oui, utilisez le niveau de vérification minimal et la stratégie de déploiement immédiat pour les hotfixes. Concentrez-vous d'abord sur une atténuation rapide, puis suivez avec une analyse complète et des mesures de prévention une fois que l'impact immédiat est résolu.
Quelles données d'observabilité dois-je fournir ?
Idéalement, fournissez des traces d'erreurs depuis Sentry ou similaire, des logs pertinents avec des IDs de corrélation, des traces distribuées depuis OpenTelemetry ou Jaeger, et des métriques APM montrant les tendances de latence et de taux d'erreur. Plus de données permet une identification plus rapide et précise de la cause racine.
Comment savoir quand l'incident est entièrement résolu ?
Un incident est résolu lorsque : tous les tests passent avec zéro régression, les benchmarks de performance sont dans les seuils acceptables, le monitoring montre que les taux d'erreur sont revenus à la ligne de base, le plan de rollback est documenté et les mesures de prévention sont en place pour détecter des problèmes similaires.

Détails du développeur

Auteur

sickn33

Licence

MIT

Dépôt

https://github.com/sickn33/antigravity-awesome-skills/tree/main/skills/incident-response-smart-fix

Réf

main

Structure de fichiers

📁 resources/

📄 implementation-playbook.md

📄 SKILL.md