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)
À 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.
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ûrThe 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.
- •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
Exemples
/retro/retro compare 14dRun /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
viewto 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:
- Tweetable summary — one-line headline as the very first line
- Summary Table — the metrics table from Step 2
- Trends vs Last Retro — deltas from Step 11 (if history exists)
- Time & Session Patterns — narrative interpretation of Steps 3–4
- Shipping Velocity — commit type mix, PR size discipline, fix chains
- Code Quality Signals — test ratio assessment, hotspot warnings, XL PR flags
- Focus & Highlights — focus score, ship of the week
- Top 3 Wins — best accomplishments from the window, anchored in specific commits/PRs
- 3 Things to Improve — specific, actionable, anchored in the data
- 3 Habits for Next Week — small, practical, each takes less than 5 minutes to adopt
- Week-over-Week — trend tables (if window ≥ 14d)
Compare Mode
When the user invokes /retro compare (with or without an explicit window):
- Compute metrics for the current window (e.g., last 7 days)
- Compute metrics for the prior window of the same length (e.g., 7–14 days ago)
- Render a side-by-side table with deltas and directional arrows (↑/↓/→)
- Write a narrative on improvements and regressions
- 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_BRANCHfor 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 annexesCe 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.mdDepuis 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’OpenSkillsopenskills 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 syncMode 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.
Lecteur PDF
Productivite
Lit et extrait le texte de fichiers PDF (rapports, contrats, tableurs). Gère les fichiers locaux, les URL et les pièces jointes WhatsApp. Utilisez-le dès qu'un contenu PDF est nécessaire, même sans demande explicite.
Workflows de messagerie Discord
Productivite
Utilisez l'outil message pour envoyer, modifier et modérer des messages Discord avec des composants interactifs.
Aperçu interactif des verdicts
Productivite
Générer un aperçu HTML interactif des verdicts (garder/supprimer) pour la revue par le mainteneur, puis traiter le JSON de retour.