CommunityRédaction et éditiongithub.com

Arzaroth/skills

Remplir le post-mortem technique d'un ticket - rédiger l'intégralité de la cause racine et du correctif dans un seul champ du tracker, puis pointer les autres champs d'analyse vers celui-ci (« voir notes de dev »). Le tracker, les champs, la langue et les titres proviennent de la configuration. Invoquer pour un ticket donné ou pour le correctif en cours. Déclencheurs : « analyse des causes », « analyse technique », « root cause », « cause racine », « solution apportée », « /analyse-causes ».

Qu'est-ce que skills ?

Cette compétence pour agent IA automatise la rédaction et le remplissage du post-mortem technique d'un ticket dans un système de suivi. Elle centralise toute l'analyse (cause racine et correctif) dans un seul champ et redirige les autres champs d'analyse vers celui-ci avec un texte pointeur configurable, évitant ainsi la duplication d'informations. L'agent lit la configuration depuis `~/.config/skills/analyse-causes/config.md` qui définit le tracker, le format des champs, la langue de rédaction, les titres des sections, et les textes de pointage. La compétence peut être invoquée pour un ticket spécifique passé en argument ou pour le correctif en cours dans la session (diff, branche, MR). Le workflow inclut : identification du ticket, traçage de la cause racine dans le code, listage des modifications du correctif, rédaction complète en markdown, puis écriture dans les champs du tracker. Les déclencheurs supportés sont « analyse des causes », « analyse technique », « root cause », « cause racine », « solution apportée » et « /analyse-causes ».

Compatible avec~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/Arzaroth/skills/tree/HEAD/skills/analyse-causes

Installed? Explore more Rédaction et édition skills: steipete/notion, langchain-ai/langchain, bytedance/podcast-generation · View all 6 →

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

Documentation

Post-mortem technique d'un ticket (un champ + pointeurs)

L'utilisateur met tout dans un seul champ et pointe les autres champs d'analyse vers celui-ci, pour ne rien dire deux fois. Reproduire ce workflow.

Configuration

Lire ~/.config/skills/analyse-causes/config.md avant toute chose. Il définit le tracker et ses outils, le motif de clé de projet et de ticket, le format des champs, la langue et les titres du rapport, le champ de rédaction, les champs déviés avec leur texte pointeur, et les champs de lien MR. S'il est manquant, dire à l'utilisateur de copier config.example.md (à côté de ce fichier) vers ~/.config/skills/analyse-causes/config.md, de le remplir, puis s'arrêter.

Cible : le ticket passé en argument, sinon le correctif en cours dans la session (diff / branche / MR).

Ce qu'il faut produire

Un rapport complet, dans la langue configurée, en markdown, avec deux sections sous les titres configurés :

  1. Cause racine - le POURQUOI technique. NE PAS reformuler la situation initiale (symptôme / description du ticket). Revenir à l'origine réelle : choix de conception, constante / fichier:ligne, hypothèse erronée. Jamais le symptôme visible.
  2. Correctif - ce qui a changé et pourquoi cela supprime la cause racine. Factuel : mécanisme choisi, fichiers/constantes touchés, comportement résultant. Pas de lien MR ici : il va dans les champs de lien MR configurés.

Règles : concis, courtes puces, termes exacts (constantes, fonctions, fichier:ligne), vérifiés sur le code réel. Pas de tiret cadratin (U+2014) – utiliser trait d'union, virgule, ou reformuler.

Procédure

  1. Identifier le ticket : argument = clé correspondant au motif configuré ; sinon le correctif en cours (diff / branche / MR de la session).
  2. Lire le ticket via l'outil configuré si nécessaire, mais ne pas copier sa description.
  3. Tracer la cause racine dans le code et lister les modifications du correctif (git diff / MR).
  4. Rédiger le rapport complet.
  5. Afficher le rapport, puis écrire les champs dans le format configuré :
    • champ de rédaction <- le rapport complet
    • chaque champ dévié <- un document d'un paragraphe avec le texte pointeur configuré Si aucun ticket n'est ciblé (correctif en session sans clé), seulement afficher le rapport et proposer de remplir les champs.

Individual skills in this repo

This repo contains 4 individual skills — each has its own dedicated page.

Arzaroth/skills

Work one round of review comments on a pull/merge request: fetch every unresolved thread, verify each finding against the current code, fix what is still valid, reply with a justification to what is not, then commit, push and answer every thread. Use when a PR has review comments to deal with - from an AI reviewer (CodeRabbit and friends) or a human - and when asked to 'address the review', 'fix the review comments', 'respond to CodeRabbit', or 'handle the PR feedback'. The babysit-pr skill calls this for each of its rounds.

Arzaroth/skills

Open a pull/merge request and stay with it until it merges: trigger the reviewers, watch for their verdict, work each round of findings, push, re-trigger, and merge when it is clean. Handles AI reviewers (CodeRabbit) and human maintainers, on GitHub (gh) and GitLab (glab). Use when asked to 'open a PR and babysit it', 'ship this and see it through', 'get this PR merged', 'watch the PR until it lands', or '/babysit-pr'. Also the review-and-merge half of ship-feature-pipeline.

Arzaroth/skills

Check whether the repo's own docs still describe the code after recent changes, and update the ones that went stale. Scopes itself to the last merged branch, the last commit, this session's work, or a full sweep. Use when asked to 'update the docs', 'check the docs', 'are the docs still accurate', 'docs sweep', 'refresh the documentation', or '/docs-update'. Every line it writes goes through the unslop skill. Run it before cutting a release or merging a feature, so docs ship with the change instead of trailing it.

Arzaroth/skills

Cut a release on GitHub: update the changelog, bump the version (preferring the repo's own release task or script over a manual edit), tag, push, then watch the release workflow until the GitHub Release exists. Use when asked to 'cut a release', 'release version X', 'ship a new version', 'bump the version and tag', 'publish a release', or '/gh-release'. For repos where a tag push triggers a GitHub Actions workflow that creates the release.

Skills associés