Synthèse automatique
Passe en revue la qualité des docs et des articles de blog (style, exactitude, bonnes pratiques Pulumi) sur les fichiers ouverts, les changements non commités, la branche courante ou une PR donnée, en affichant le résultat dans la conversation.
Points forts
- Détecte automatiquement le périmètre à réviser : fichiers ouverts dans l'IDE, changements non commités, puis diff de la branche vs master, avec repli si --fork-point échoue.
- Route chaque fichier vers un domaine via domain-routing, puis applique les critères du domaine et les critères partagés avant de rendre le résultat selon output-format.
- Intègre Vale sur content/docs et content/blog en normalisant les catégories via un script de filtrage, et continue la revue sans échouer si Vale n'est pas installé.
- N'écrit jamais sur GitHub : la sortie reste dans la conversation, et les PR sont lues uniquement via gh pr view / gh pr diff.
- Prévoit une télémétrie des résultats (scripts de scraping et digest hebdomadaire) pour ajuster les règles au fil du temps.
Limites
- Dépend de fichiers de référence et de scripts propres au dépôt (.claude/commands/docs-review/) : domain-routing, shared-criteria, output-format et vale-findings-filter.py doivent exister.
- La détection de périmètre s'appuie sur le contexte Claude Code (rappels de fichiers ouverts, bloc gitStatus) et sur les outils git, gh et Vale disponibles localement.
- Les bonnes pratiques vérifiées sont celles de Pulumi : le skill est peu transposable à un autre produit sans adapter les références.
À utiliser juste avant de commiter des modifications de documentation ou de blog, ou pour obtenir un avis de qualité rapide sur une PR Pulumi.
À éviter pour réviser du code applicatif, publier automatiquement des commentaires sur GitHub, ou dans un dépôt dépourvu des références et scripts du skill.
Analyse de sécurité
PrudenceThe skill executes read-only developer tools (git, gh, vale, python) to review local and PR docs. No destructive or exfiltrating behavior is present, and it explicitly avoids posting to GitHub, but shell/network tool use warrants a caution rating.
- •Uses shell commands (`gh pr view/diff`, `git diff`, `vale`, `python3`) without declaring allowed-tools, so execution depends on agent permissions.
- •Reads PR data from GitHub via `gh`, but only performs read-only operations and explicitly states it never posts to GitHub.
- •Writes temporary files to /tmp for Vale output, which is low risk but still involves filesystem writes.
Exemples
/docs-review/docs-review 4821I just finished editing a couple of docs pages on this branch — run docs-review on the branch changes before I commit.name: docs-review description: Review docs and blog post quality before committing (style, accuracy, Pulumi best practices). Use when you've made content changes locally and want a quality pass on open files, the current branch, or a specific PR — outputs to the conversation, never posts to GitHub. user-invocable: true
Docs Review (interactive)
Output goes into the conversation. This skill never posts to GitHub.
Usage
/docs-review [PR_NUMBER]
If PR_NUMBER is provided, review the PR via gh pr view / gh pr diff. If omitted, auto-detect scope from the current IDE/terminal context.
Scope detection (when no PR number is provided)
Walk these steps in order; stop at the first that yields a scope.
-
Open files in the IDE. Check the conversation context for system reminders that list open files. If any are present, treat those files as the scope.
-
Uncommitted changes. Check the gitStatus block (or run
git status) for modified (M) and untracked (??) files. Usegit diffand read the affected files. -
Branch changes vs. master:
git diff $(git merge-base --fork-point master HEAD)...HEADIf
--fork-pointfails (no reflog), fall back togit diff $(git merge-base master HEAD)...HEAD. Review every changed file in the branch.
Performing the review
Route each file to a domain via docs-review:references:domain-routing, then apply that domain's criteria plus docs-review:references:shared-criteria. Render the output per docs-review:references:output-format.
For files under content/docs/ or content/blog/, also run Vale and surface its findings under ⚠️ Low-confidence per the Style-findings render contract in docs-review:references:output-format (the **line N:** _category_ — <message> bullet form, grouped under a #### Style findings H4). Pipe through the categorize filter so the JSON has a deterministic category field — never surface the raw rule name:
vale --no-exit --output=JSON <files> > /tmp/vale-raw.json
python3 .claude/commands/docs-review/scripts/vale-findings-filter.py \
--in /tmp/vale-raw.json --out /tmp/vale-findings.json
# Render bullets from /tmp/vale-findings.json: use .category, not .rule.
Omit --pr in interactive mode (no diff to intersect; the filter accepts all findings, categorizes, caps). If vale --version fails or vale is not on PATH, skip the Vale step with a one-line note (e.g., "Skipping Vale: not installed. Install via mise install to enable style nits.") and continue the review without Vale findings — don't hard-fail.
For PR-number invocations:
gh pr view {{arg}} --json title,body,files,additions,deletions,labels
gh pr diff {{arg}}
Format for terminal display. Include the scope in the summary, and offer to broaden if useful.
Outcome telemetry (quarterly review)
Every closed PR's pinned review encodes what happened to its findings (✅ Resolved = fixed, concede: = conceded, 🛡️ Disputed … model held = disputed, still-🚨-at-merge = ignored). scripts/scrape-review-outcomes.py derives per-finding outcomes from that structure; the weekly digest (scripts/weekly-digest/digest.py) aggregates the trailing week automatically. Quarterly, run the long-window tuning report:
uv run .claude/commands/docs-review/scripts/scrape-review-outcomes.py \
--closed-since <quarter-start> --stats
What to do with the numbers: verdict categories with high concede or ignored-at-merge rates are candidates for demoting from the always-🚨 carve-out list (or pruning entirely — edit docs-review:references:output-format §Bucket rules in a PR); recurring prose findings with high fix rates are candidates for promotion into Vale rules so they're caught pre-review. High unconfirmed_at_merge counts mean reviews are routinely stale at merge — evidence for auto-refreshing on trivial deltas. Telemetry informs the tuning; humans make the edits.
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/interactive-docs-review-ms47vqf4/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/interactive-docs-review-ms47vqf4' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/interactive-docs-review-ms47vqf4/download' --output '.skill-downloads/interactive-docs-review-ms47vqf4/SKILL.md.part' && mv '.skill-downloads/interactive-docs-review-ms47vqf4/SKILL.md.part' '.skill-downloads/interactive-docs-review-ms47vqf4/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/interactive-docs-review-ms47vqf4/SKILL.md' && test -s '.skill-downloads/interactive-docs-review-ms47vqf4/SKILL.md' && mkdir -p '.claude/skills' && test ! -e '.claude/skills/docs-review' && cp -R '.skill-downloads/interactive-docs-review-ms47vqf4' '.claude/skills/docs-review'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/interactive-docs-review-ms47vqf4'openskills read 'interactive-docs-review-ms47vqf4'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/interactive-docs-review-ms47vqf4/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.
Rédaction de docs Supabase
Documentation
Rédigez, éditez et révisez le contenu de la documentation Supabase : guides, tutoriels, références et partiels. Suivez les guides de style et les règles de validation MDX/TOML.
Créer un enregistrement de décision d'architecture
Documentation
Créer un nouveau ADR avec numérotation séquentielle, l'enregistrer dans le graphe AgentDB et le lier aux ADR associés.
Mise à jour de plan avec recherche approfondie
Documentation
Met à jour un document de plan en lançant des sous-agents en parallèle pour analyser un sujet sur tous les passes du compilateur, puis consolide les résultats.