Validation QA d'une PR

VérifiéPrudence

Exécute une validation QA complète sur une pull request : démarre l'environnement local, teste les critères d'acceptation et publie optionnellement le rapport sur la PR.

Spar Skills Guide Bot
TestingIntermédiaire
22/07/2026
Claude Code
#qa#pull-request#acceptance-testing#github-cli#local-environment

Recommandé pour

Synthèse automatique

Lance une validation QA sur une pull request : démarre l'environnement local, teste les critères d'acceptation et produit un rapport, avec publication optionnelle en commentaire sur la PR.

Points forts

  • Enchaîne de bout en bout : résolution de la PR, démarrage de l'environnement via BOOT_CMD, puis test de chaque critère d'acceptation
  • Déduit la PR depuis la branche courante quand aucun numéro ou URL n'est fourni
  • Fonctionne en mode autonome en affichant le rapport complet en Markdown dans la réponse, sans écrire sur GitHub
  • La publication du commentaire est proposée et dédupliquée grâce au marqueur <!-- ai-pipeline:qa-report -->

Limites

  • Dépend d'un bloc « Project Config » dans le SKILL.md de l'orchestrateur (REPO, TEMP_ROOT, BOOT_CMD, LOCAL_URL) : sans lui, rien ne démarre
  • Suppose un environnement local démarrable et une CLI gh authentifiée avec accès au dépôt
  • Ne couvre que la validation des critères d'acceptation listés : aucune analyse statique ni revue de code approfondie n'est décrite
Quand l'utiliser

Utilisez-le quand une PR est prête et que vous voulez vérifier concrètement, sur un environnement local démarré, que chaque critère d'acceptation passe.

Quand l'éviter

Évitez-le si le projet n'a pas d'environnement local démarrable ou si le bloc de configuration de l'orchestrateur est absent.

Analyse de sécurité

Prudence
Score qualité77/100

There is no destructive, obfuscated, or exfiltration behavior: no `curl | sh`, no `rm -rf`, no reading of secrets or tokens, no base64 payloads, and no attempt to disable safety controls. The risk is moderate and conventional for a dev workflow — it shells out to grep and `gh`, boots a local environment via a repo-provided boot command, and can write to a GitHub PR, but the PR write is explicitly confirmed by the user. The main real concern is trust in the project config file that supplies `BOOT_CMD`, which is executed without inspection.

Points d'attention
  • •Executes a shell command (`BOOT_CMD`) pulled verbatim from a repo-local orchestrator config file (`.claude/skills/orchestrator/SKILL.md`) with no validation, so an untrusted/modified config can inject arbitrary commands into the agent's shell context.
  • •Uses `gh` CLI against the GitHub API (read PR metadata, and write/update PR comments) — network plus external-service write capability, though posting is gated behind an explicit yes/no confirmation.
  • •No `allowed-tools` declared, so the skill implicitly relies on the host agent's full Bash/network permissions rather than a scoped tool set.
  • •Delegates core execution to an unspecified `qa-engineer` sub-agent whose behavior is not contained in this file, so the audited surface is incomplete.
Comment cette analyse est faite

Exemples

QA a specific PR
/qa 142
QA the current branch's PR
/qa — validate the acceptance criteria for the PR on my current branch and show me the report without posting it to GitHub
QA from a PR URL
/qa https://github.com/acme/webapp/pull/378 and tell me which criteria fail

name: qa description: Run QA validation on a pull request — boots the local environment, tests acceptance criteria, and optionally posts the report as a PR comment. Standalone entry point for the qa-engineer agent. argument-hint: <PR-number-or-URL>

QA

Standalone QA run for any PR. Boots the local environment, validates every acceptance criterion, and produces a test report. Posting to GitHub is your choice — you are prompted at the end.

Step 1 — Load config

Read project config from the orchestrator's ## Project Config block:

ORCHESTRATOR=".claude/skills/orchestrator/SKILL.md"
REPO=$(grep '^REPO=' "$ORCHESTRATOR" | cut -d= -f2)
TEMP_ROOT=$(grep '^TEMP_ROOT=' "$ORCHESTRATOR" | cut -d= -f2)
BOOT_CMD=$(grep '^BOOT_CMD=' "$ORCHESTRATOR" | cut -d= -f2-)
LOCAL_URL=$(grep '^LOCAL_URL=' "$ORCHESTRATOR" | cut -d= -f2)

Step 2 — Resolve the PR

Use $ARGUMENTS as the PR number or URL. If empty, resolve from the current branch:

gh pr list --head "$(git branch --show-current)" --json number,url -q '.[0] | "\(.number) \(.url)"'

If no PR is found, tell the user and stop.

Get the base branch:

gh pr view <PR_NUMBER> --json baseRefName -q .baseRefName

Step 3 — Invoke the qa-engineer agent

Invoke the qa-engineer sub-agent with:

  • PR number and PR URL
  • Base branch from Step 2
  • Runtime values: TEMP_ROOT={TEMP_ROOT}, REPO={REPO}, E2E_BOOT={BOOT_CMD}, E2E_URL={LOCAL_URL}

STANDALONE MODE — two differences from the normal pipeline run:

  1. Skip Step 6 (posting the PR comment). Instead, output the full QA report as formatted Markdown in your response, in a section titled ## QA Report. Use the same format the pipeline would post (including the <!-- ai-pipeline:qa-report --> marker).
  2. Skip the StructuredOutput JSON return. Output a short human-readable summary instead: overall result, pass/fail per criterion, and any blockers.

All other steps run normally — the environment is booted ({BOOT_CMD}), acceptance criteria are tested, and the full validation is performed.

Step 4 — Offer to post

After the agent responds, display its ## QA Report and ask:

Post this QA report to PR #<PR_NUMBER>? Reply yes to post, no to finish here.

If yes — post with dedup: check for an existing <!-- ai-pipeline:qa-report --> comment, update it with PATCH if found, otherwise create a new comment.

If no — confirm the QA run is complete and finish.

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/qa-pr-validation-mrwak8qd/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/qa-pr-validation-mrwak8qd' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/qa-pr-validation-mrwak8qd/download' --output '.skill-downloads/qa-pr-validation-mrwak8qd/SKILL.md.part' && mv '.skill-downloads/qa-pr-validation-mrwak8qd/SKILL.md.part' '.skill-downloads/qa-pr-validation-mrwak8qd/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/qa-pr-validation-mrwak8qd/SKILL.md' && test -s '.skill-downloads/qa-pr-validation-mrwak8qd/SKILL.md' && mkdir -p '.claude/skills' && test ! -e '.claude/skills/qa' && cp -R '.skill-downloads/qa-pr-validation-mrwak8qd' '.claude/skills/qa'

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/qa-pr-validation-mrwak8qd'

openskills read 'qa-pr-validation-mrwak8qd'

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/qa-pr-validation-mrwak8qd/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