Synthèse automatique
Automatise le cycle de vie d'une pull request GitHub : création ou réutilisation du PR, demande de revue Copilot, surveillance des checks GitHub Actions puis synthèse des échecs CI et des commentaires Copilot.
Points forts
- Enchaîne résolution de l'état du PR, création si absent, demande de revue Copilot et surveillance des checks sans intervention manuelle
- La demande de revue Copilot est idempotente et tolère les variantes de login du bot grâce à un match insensible à la casse
- Le polling est borné (30 itérations de 30 s, soit 15 min) avec sortie anticipée et narration en une ligne plutôt qu'en gros blobs JSON
- Regroupe les constats par fichier, puis par fichier d'instructions .github/instructions et skill canonique, avec des prochaines étapes concrètes
Limites
- Dépend entièrement de gh et de GitHub : inutilisable sur GitLab, Bitbucket ou un dépôt sans CLI authentifiée
- Le budget de 15 minutes peut expirer avant la fin de checks lents ou de la revue Copilot, l'analyse se fait alors partiellement
- Ne corrige rien : le skill se contente de rapporter les échecs CI et les commentaires, la remédiation reste à la charge de l'utilisateur
À utiliser quand une branche vient d'être poussée et que vous voulez ouvrir le PR, déclencher Copilot et obtenir un résumé exploitable des checks CI en une seule commande.
À éviter sur un dépôt hébergé ailleurs que sur GitHub, ou lorsque vous cherchez à corriger automatiquement les échecs plutôt qu'à en obtenir un rapport.
Analyse de sécurité
PrudenceThe skill is legitimate and contains no destructive, exfiltration, or obfuscated behavior. It does, however, execute GitHub CLI and git commands, mutate PR state, and poll network resources, so it fits the caution category rather than safe.
- •Uses bash/git/gh commands and GitHub network access, including PR creation and reviewer mutation via `gh pr create` / `gh pr edit --add-reviewer`.
- •No `allowed-tools` declaration despite instructing command execution, reducing permission transparency.
- •Reads CI logs and PR comments, which may contain sensitive repository information if surfaced carelessly.
Exemples
/pr — open a pull request for the current branch and watch CI and Copilot until they're done.The PR for this branch is already open; poll the GitHub Actions checks and the Copilot review and tell me what's failing.I just pushed. Can you check the CI results and the Copilot comments on the PR and group the problems by file?name: pr description: DraftForge PR lifecycle workflow. Use when the user runs /pr, opens or pushes a pull request, or asks to monitor CI checks and Copilot review on a branch. Creates the PR (or reuses an existing one), polls GitHub Actions and Copilot up to ~15 min, then analyses CI failures and Copilot comments and reports findings grouped by file and skill.
/pr — PR lifecycle workflow
Purpose
Drive a PR from "branch pushed" to "actionable review summary" without the user babysitting it. The skill:
- Resolves PR state (open existing or create new).
- Requests Copilot as a reviewer if missing.
- Polls GitHub Actions checks and the Copilot review (up to 15 min).
- Pulls CI failure logs and Copilot inline comments.
- Categorises findings by file → matched
.github/instructions/*.instructions.md→ canonical skill, then surfaces them to the user with concrete next steps.
When to trigger
- User types
/pr. - User says "open a PR" / "create a PR" / "spin up a PR" on the current branch.
- User says "watch CI" / "monitor checks" / "wait for Copilot" on a branch with an open PR.
- A push has just happened and the user is asking what's next.
Do not trigger automatically just because a branch has uncommitted work — confirm first.
Workflow
Phase 1 — Resolve state
branch=$(git branch --show-current)
pr_json=$(gh pr view --json number,state,headRefName,baseRefName,url,reviewRequests,reviews 2>/dev/null || echo "")
- If
pr_jsonis empty → no PR yet → go to Phase 2 (create). - If PR exists and is
OPEN→ go to Phase 3 (request Copilot if absent, then monitor). - If PR is
MERGED/CLOSED→ report and stop; ask whether to open a new one.
Before creating, verify the branch is pushed (git rev-parse --abbrev-ref --symbolic-full-name @{upstream} succeeds) and is ahead of main.
Phase 2 — Create the PR (if missing)
Pre-fill title/body from commits when the branch has 1–3 commits; otherwise prompt the user once for a title. Always use a HEREDOC body with ## Summary and ## Test plan sections, per repo convention. Full patterns and the exact gh pr create invocation: references/creating-the-pr.md.
Phase 3 — Request Copilot reviewer (idempotent)
PR=$(gh pr view --json number -q .number)
# Skip if Copilot is already in reviewRequests OR has already reviewed
need_copilot=$(gh pr view $PR --json reviewRequests,reviews \
--jq '(.reviewRequests + .reviews) | any(.login // .author.login | tostring | test("copilot"; "i")) | not')
if [ "$need_copilot" = "true" ]; then
gh pr edit $PR --add-reviewer @copilot
fi
The exact bot login varies (copilot-pull-request-reviewer[bot] / Copilot). The case-insensitive test("copilot"; "i") match is intentional — don't hardcode an exact login.
Phase 4 — Monitor checks and Copilot review
Poll every 30 s, max 30 iterations = 15 min. Break early when both are done. Full polling pattern, jq queries, and "is Copilot done?" heuristics: references/monitoring-ci-and-copilot.md.
While polling, narrate progress in single-line updates ("iter 4/30: 3 checks running, copilot pending"). Do NOT print large JSON blobs to the user — those go to logs.
If the 15 min budget exhausts:
- If checks are still running: report which jobs and proceed to analysis with what completed.
- If Copilot is still pending: report and analyse CI-only; tell the user they can re-run
/prlater to pick up the Copilot review.
Phase 5 — Analyse and report
Two analyses run in parallel; one merged report:
- CI failures —
gh run view <id> --log-failedfor each failed run, extract the error lines (look forFAIL,Error,Traceback,assert, lines ending with:[0-9]+:for compiler errors). Cap at 10 lines per failed step. - Copilot inline comments —
gh api repos/{owner}/{repo}/pulls/{N}/comments→ for each comment, match thepathagainst every.github/instructions/*.instructions.mdapplyToglob and tag it with the matched skill(s).
Output format and severity heuristics: references/analyzing-results.md.
What this skill does NOT do
- Does not push for the user (assumes branch is already pushed; tells the user to push if not).
- Does not fix the issues Copilot raises — only surfaces them with the canonical-skill pointer so the user / next skill invocation can act.
- Does not enable automatic Copilot review at the repo level — that's a one-time UI step (Settings → Rules → Rulesets).
- Does not stream raw
gh run view --log-failedoutput into the chat — extracts just the error lines.
References
- creating-the-pr.md —
gh pr createpatterns, title/body autofill, push-check - monitoring-ci-and-copilot.md — polling loop, jq queries, "done" heuristics
- analyzing-results.md — CI log extraction, Copilot-comment → skill matching, output format
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/pr-lifecycle-workflow-mrwak8yx/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/pr-lifecycle-workflow-mrwak8yx' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/pr-lifecycle-workflow-mrwak8yx/download' --output '.skill-downloads/pr-lifecycle-workflow-mrwak8yx/SKILL.md.part' && mv '.skill-downloads/pr-lifecycle-workflow-mrwak8yx/SKILL.md.part' '.skill-downloads/pr-lifecycle-workflow-mrwak8yx/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/pr-lifecycle-workflow-mrwak8yx/SKILL.md' && test -s '.skill-downloads/pr-lifecycle-workflow-mrwak8yx/SKILL.md' && mkdir -p '.claude/skills' && test ! -e '.claude/skills/pr' && cp -R '.skill-downloads/pr-lifecycle-workflow-mrwak8yx' '.claude/skills/pr'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/pr-lifecycle-workflow-mrwak8yx'openskills read 'pr-lifecycle-workflow-mrwak8yx'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/pr-lifecycle-workflow-mrwak8yx/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.
Configurer un canal de discussion avec SecretRefs
DevOps
Configurez des canaux de discussion avec des commandes non interactives, les secrets étant uniquement des SecretRefs. Couvre les étapes de collecte, modification, réparation et vérification.
Enquêter sur les échecs CI de ClickHouse
DevOps
Investigue un échec CI de ClickHouse de bout en bout à partir d'une URL de PR ou de rapport S3. Récupère les tests échoués, classe flaky vs vraie régression, et cherche des issues/fixes existants.
Revue de PR Ansible
DevOps
Examine une PR Ansible selon le processus standardisé du projet, incluant la validation des changelogs, la couverture de tests et le suivi des commentaires.