Rétrospective d'ingénierie

VérifiéSûr

Rétrospective d'ingénierie hebdomadaire analysant l'historique des commits, les modèles de travail et les métriques de qualité du code avec suivi des tendances.

Spar Skills Guide Bot
ProductiviteIntermédiaire
26/07/2026
Claude Code
#git-analytics#retrospective#engineering-metrics#code-quality#reporting

Recommandé pour

Synthèse automatique

Génère une rétrospective d'ingénierie hebdomadaire à partir de l'historique Git : volume de commits, sessions de travail, répartition horaire, types de commits, fichiers les plus modifiés et taille des PR.

Points forts

  • Collecte automatisée des données Git (commits, numstat, hotspots, numéros de PR) lancée en parallèle pour un rapport complet en une passe
  • Détection des sessions de travail avec seuil de 45 minutes et classification deep/medium/micro, plus calcul du LOC par heure active
  • Analyse des hotspots avec alertes de churn (5+ modifications) et vérification de la présence de tests correspondants
  • Mode `compare` qui confronte la fenêtre courante à une fenêtre précédente de même durée pour suivre les tendances

Limites

  • Le fuseau horaire est fixé à America/Los_Angeles pour les histogrammes et la détection de sessions, ce qui fausse l'analyse pour des équipes ailleurs
  • Ne regarde que les commits déjà poussés sur la branche par défaut d'origin : le travail local non poussé est ignoré
  • Le nombre de PR et le ratio de tests reposent sur des heuristiques fragiles (motif `#123` dans les messages, motifs de noms de fichiers de test)
Quand l'utiliser

À utiliser en fin de semaine ou avant une réunion d'équipe pour obtenir rapidement des métriques objectives sur la vélocité et les zones de friction du dépôt.

Quand l'éviter

Ne pas s'en servir pour évaluer individuellement des développeurs ou pour des dépôts sans historique Git exploitable, car les métriques de volume ne mesurent pas la qualité du travail.

Analyse de sécurité

Sûr
Score qualité78/100

The skill is a read-only git analytics routine: it shells out only to `git log`/`git remote show`, filters with grep/awk/sort/uniq, and writes a local JSON snapshot under `.context/retros`. There is no curl|sh, no credential access, no deletion, no obfuscated payload, and no attempt to disable safety controls. The only meaningful execution surface is routine bash usage against a local repo, which is proportionate to the stated purpose.

Points d'attention
  • •Bash blocks are limited to read-only `git log` / `git remote show` queries plus `mkdir -p .context/retros` — no destructive or network-exfiltrating commands
  • •Writes JSON snapshots to `.context/retros/` inside the repo, which is low-risk but does persist commit metadata (author timestamps, commit subjects) to disk — worth noting for repos with strict data-handling rules
  • •No allowed-tools declaration, yet the instructions assume `bash`, `glob`, `view`, and `create`; the mismatch could cause an agent to reach for tools the manifest does not advertise
Comment cette analyse est faite

Exemples

Default weekly retro
/retro
Compare two weeks
/retro compare 14d
Monthly hotspot review
Run /retro 30d and tell me which files have the most churn and whether their test files are being updated too.

name: retro description: | Weekly engineering retrospective. Analyzes commit history, work patterns, and code quality metrics with persistent history and trend tracking. Use when asked for a retro, retrospective, weekly review, shipping velocity, or engineering metrics. Trigger with /retro.

Generates a comprehensive engineering retrospective analyzing commit history, work patterns, and code quality metrics.

Arguments

  • /retro — default: last 7 days
  • /retro 24h — last 24 hours
  • /retro 14d — last 14 days
  • /retro 30d — last 30 days
  • /retro compare — compare current vs prior same-length window
  • /retro compare 14d — compare with explicit window

Instructions

Parse the argument for time window. Default to 7 days. Validate format: a number followed by d, h, or w, or the keyword compare with an optional window. If the format is invalid, show usage and stop.

Auto-detect default branch:

DEFAULT_BRANCH=$(git remote show origin 2>/dev/null | grep 'HEAD branch' | awk '{print $NF}')
DEFAULT_BRANCH=${DEFAULT_BRANCH:-main}

Use origin/$DEFAULT_BRANCH for all git queries.

Step 1: Gather Raw Data

Run all of the following via bash, in parallel:

# Commits with timestamps
git log origin/$DEFAULT_BRANCH --since="<window>" --format="%H|%ai|%s" --shortstat
# Per-commit test vs production LOC
git log origin/$DEFAULT_BRANCH --since="<window>" --format="COMMIT:%H" --numstat
# Timestamps for session detection (Pacific time)
TZ=America/Los_Angeles git log origin/$DEFAULT_BRANCH --since="<window>" --format="%at|%ai|%s" | sort -n
# Hotspot files
git log origin/$DEFAULT_BRANCH --since="<window>" --format="" --name-only | grep -v '^$' | sort | uniq -c | sort -rn
# PR numbers from commit messages
git log origin/$DEFAULT_BRANCH --since="<window>" --format="%s" | grep -oE '#[0-9]+' | sort -un

Step 2: Compute Metrics

Build a summary table with the following columns:

| Metric | Value | |---|---| | Commits | — | | PRs merged | — | | Insertions | — | | Deletions | — | | Net LOC | — | | Test LOC | — | | Test ratio | — | | Version range | — | | Active days | — | | Detected sessions | — | | Avg LOC/session-hour | — |

Compute each metric from the raw data gathered in Step 1. Test LOC is determined by counting insertions in files matching common test patterns (*_test.*, *.test.*, *_spec.*, *.spec.*, test_*, tests/, __tests__/, etc.). Test ratio = test LOC / total insertions.

Step 3: Commit Time Distribution

Build an hourly histogram of commit times in Pacific time. Render as a bar chart using Unicode block characters. Call out:

  • Peak hours — the 2-3 hours with the most commits
  • Dead zones — any 4+ hour gap with zero commits
  • Bimodal patterns — two distinct activity peaks (e.g., morning + evening)
  • Late-night clusters — commits between midnight and 4am

Step 4: Work Session Detection

Group commits into sessions using a 45-minute gap threshold — any gap of 45+ minutes between consecutive commits starts a new session.

Classify each session:

  • Deep — 50+ minutes
  • Medium — 20–50 minutes
  • Micro — under 20 minutes

Calculate and report:

  • Total active time (sum of session durations)
  • Average session length
  • LOC per hour (net LOC / total active hours)

Step 5: Commit Type Breakdown

Categorize commits by conventional commit prefix: feat, fix, refactor, test, chore, docs, and other for anything that doesn't match.

Render a percentage bar chart. Flag a warning if fix ratio exceeds 50%.

Step 6: Hotspot Analysis

List the top 10 most-changed files by number of commits touching them.

Flag:

  • Churn — files with 5+ changes in the window
  • Test vs production ratio — whether hot files have corresponding test files that are also active

Step 7: PR Size Distribution

Classify PRs by total LOC changed (insertions + deletions):

| Size | LOC Range | |---|---| | Small | < 100 | | Medium | 100–500 | | Large | 500–1500 | | XL | 1500+ |

Flag any XL PRs with their file counts and summaries.

Step 8: Focus Score + Ship of the Week

Focus Score = percentage of commits in the single most-changed top-level directory. Higher is more focused.

Ship of the Week = the PR (or largest single commit) with the highest net LOC. Include its title and a one-line summary.

Step 9: Week-over-Week Trends

Only include this section if the time window is 14 days or longer.

Break the window into weekly buckets and show trends for:

  • Commits per week
  • LOC per week
  • Test ratio per week
  • Fix ratio per week
  • Sessions per week

Step 10: Streak Tracking

TZ=America/Los_Angeles git log origin/$DEFAULT_BRANCH --format="%ad" --date=format:"%Y-%m-%d" | sort -u

Count consecutive days with commits, walking backward from today. Report the current streak length.

Step 11: Load History & Compare

Use glob to search for: .context/retros/*.json

  • If found: use view to read the most recent file. Calculate deltas between current and previous metrics for the trends section.
  • If first run: skip comparison and note: "First retro — run again next week for trends."

Step 12: Save Retro History

mkdir -p .context/retros

Use the create tool to save a JSON snapshot to .context/retros/${today}-${seq}.json where ${today} is the current date in YYYY-MM-DD format and ${seq} is an incrementing number if multiple retros run on the same day.

Schema:

{
  "date": "2026-03-12",
  "window": "7d",
  "metrics": {
    "commits": 47,
    "prs_merged": 12,
    "insertions": 3200,
    "deletions": 800,
    "net_loc": 2400,
    "test_loc": 1300,
    "test_ratio": 0.41,
    "active_days": 6,
    "sessions": 14,
    "deep_sessions": 5,
    "avg_session_minutes": 42,
    "loc_per_session_hour": 350,
    "feat_pct": 0.40,
    "fix_pct": 0.30,
    "peak_hour": 22
  },
  "version_range": ["1.0.0", "1.1.0"],
  "streak_days": 47,
  "tweetable": "Week of Mar 8: 47 commits, 3.2k LOC, 41% tests, 12 PRs, peak: 10pm"
}

Step 13: Narrative Output

Structure the final output as follows:

  1. Tweetable summary — one-line headline as the very first line
  2. Summary Table — the metrics table from Step 2
  3. Trends vs Last Retro — deltas from Step 11 (if history exists)
  4. Time & Session Patterns — narrative interpretation of Steps 3–4
  5. Shipping Velocity — commit type mix, PR size discipline, fix chains
  6. Code Quality Signals — test ratio assessment, hotspot warnings, XL PR flags
  7. Focus & Highlights — focus score, ship of the week
  8. Top 3 Wins — best accomplishments from the window, anchored in specific commits/PRs
  9. 3 Things to Improve — specific, actionable, anchored in the data
  10. 3 Habits for Next Week — small, practical, each takes less than 5 minutes to adopt
  11. Week-over-Week — trend tables (if window ≥ 14d)

Compare Mode

When the user invokes /retro compare (with or without an explicit window):

  1. Compute metrics for the current window (e.g., last 7 days)
  2. Compute metrics for the prior window of the same length (e.g., 7–14 days ago)
  3. Render a side-by-side table with deltas and directional arrows (↑/↓/→)
  4. Write a narrative on improvements and regressions
  5. Only save the current-window snapshot to .context/retros/

Tone

Encouraging but candid. Be specific and concrete — skip generic praise. Reference actual commits, PRs, and files. Target 2500–3500 words. Use markdown tables and code blocks for data, prose for narrative sections.

Rules

  • ALL output goes to the conversation, not to files — the only file written is the .context/retros/ JSON snapshot
  • Use origin/$DEFAULT_BRANCH for all git queries
  • Display all times in Pacific time
  • If zero commits are found in the window, say so clearly and suggest trying a different window
  • Round LOC/hour to the nearest 50

Du fichier au premier essai

Le téléchargement contient exactement le contenu affiché sur cette fiche. Cette copie peut différer de la dernière version du dépôt source.

Consulter la source et ses fichiers annexes

Ce téléchargement contient uniquement SKILL.md. Les scripts, références, modèles et dépendances éventuels ne sont pas inclus. Récupérez les fichiers nécessaires depuis la source en conservant leur arborescence avant de poursuivre.

1. Télécharger le fichier

Télécharger SKILL.md

Depuis la racine d’un projet de test, enregistrez le fichier sous .skill-downloads/engineering-retrospective-ms1aw4uz/SKILL.md, ou utilisez la commande suivante. Ce dossier sert à examiner la skill avant son installation.

Commande pour macOS/Linux ou WSL : un shell POSIX et curl sont nécessaires. Sous Windows sans WSL, utilisez le bouton de téléchargement et créez le dossier manuellement.

mkdir -p '.skill-downloads/engineering-retrospective-ms1aw4uz' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/engineering-retrospective-ms1aw4uz/download' --output '.skill-downloads/engineering-retrospective-ms1aw4uz/SKILL.md.part' && mv '.skill-downloads/engineering-retrospective-ms1aw4uz/SKILL.md.part' '.skill-downloads/engineering-retrospective-ms1aw4uz/SKILL.md'

2. Vérifier les prérequis

Lisez SKILL.md avant de l’utiliser. Si le fichier cite des scripts ou services externes, examinez-les et préparez les accès nécessaires dans votre environnement de test.

Aucune section de prérequis reconnue dans ce fichier. Cela ne signifie pas qu’il est autonome : les bibliothèques, outils et accès peuvent être cités ailleurs dans le contenu ou dans le dépôt source.

Les plateformes de la fiche sont des indications du catalogue. Les chemins ci-dessous suivent la documentation des outils ; ils ne prouvent pas que cette skill y a été exécutée. Aucune version minimale de ces outils n’est attestée pour cette fiche.

3. Charger la skill

Après vérification, copiez le dossier complet dans le projet avec l’une des commandes ci-dessous, puis ouvrez une nouvelle session de l’outil. La commande s’arrête si un dossier du même nom existe déjà : comparez les fichiers avant de le remplacer.

Claude Code
test -f '.skill-downloads/engineering-retrospective-ms1aw4uz/SKILL.md' && test -s '.skill-downloads/engineering-retrospective-ms1aw4uz/SKILL.md' && mkdir -p '.claude/skills' && test ! -e '.claude/skills/retro' && cp -R '.skill-downloads/engineering-retrospective-ms1aw4uz' '.claude/skills/retro'

OpenSkills

OpenSkills doit déjà être installé. La procédure locale install/read est contrôlée avec OpenSkills 1.5.0, qui exige Node.js ≥ 20.6.0. Aucun slug du catalogue n’est résolu automatiquement.

Installation officielle d’OpenSkills
openskills install './.skill-downloads/engineering-retrospective-ms1aw4uz'

openskills read 'engineering-retrospective-ms1aw4uz'

La lecture doit afficher le contenu du fichier installé et son dossier de base. Elle ne lance ni la skill ni ses dépendances.

Pour un agent qui lit AGENTS.md, synchronisez ensuite l’index. Cette commande modifie AGENTS.md : relisez le diff avant de l’utiliser.

openskills sync

Mode manuel ou autre outil : joignez SKILL.md à une conversation, ou ouvrez-le dans un agent capable de lire les fichiers. Ajoutez les ressources annexes nécessaires. Il n’existe pas de dossier universel reconnu par tous les outils.

4. Faire un premier essai

Utilisez une entrée courte et fictive : un endpoint d’API, un petit document ou un brief d’interface. Dans une nouvelle conversation, joignez le fichier ou donnez son chemin à l’agent, puis adaptez cette demande :

Lis .skill-downloads/engineering-retrospective-ms1aw4uz/SKILL.md et applique ses instructions à cet exemple : [décrire une entrée de test]. Indique les fichiers, dépendances ou accès qui manquent. Produis le résultat demandé par la skill sans inventer de données ni exécuter de script non examiné.

Résultat attendu : une sortie correspondant aux instructions de la skill, ou une liste précise des prérequis manquants. Une simple confirmation de lecture ne valide pas le premier usage. Si une ressource externe est indisponible, ce parcours reste à tester.

Skills similaires