Revue de qualité post-tâche

VérifiéPrudence

Exécute une revue de qualité complète après chaque tâche, détectant les erreurs dans les workflows n8n et le code.

Spar Skills Guide Bot
TestingIntermédiaire
23/07/2026
Claude Code
#qa#error-checking#n8n#typescript#review

Recommandé pour

Synthèse automatique

Effectue une revue de qualité complète après chaque tâche pour détecter les erreurs dans les workflows n8n, le code Next.js/React/TypeScript.

Points forts

  • Détecte les erreurs d'expression, de connexion, de credentials et de logique dans n8n
  • vérifie la compilation TypeScript et le linting
  • effectue un audit de motifs.

Limites

  • Nécessite l'accès aux outils MCP n8n
  • ne remplace pas les tests unitaires
  • peut ne pas détecter les erreurs sémantiques profondes.
Quand l'utiliser

Après avoir terminé une tâche de développement impliquant des workflows n8n ou du code Next.js/React/TypeScript.

Quand l'éviter

Pour une revue de code légère ou sans accès au contexte complet de la tâche.

Analyse de sécurité

Prudence
Score qualité90/100

The skill uses powerful tools like Bash and npm for linting, type-checking, and building code as part of a QA review process. No destructive or exfiltrating commands are present, and the context is clearly legitimate.

Points d'attention
  • •Executes bash commands (npx tsc, npm run lint, npm run build) which could be misused but are legitimate for QA
Comment cette analyse est faite

Exemples

Review n8n workflow
Run a QA review on the n8n workflow I just created. Workflow ID: abc123
Review code changes
Perform a comprehensive QA check on my code changes in the current project.
Full post-task QA
Run QA review for both code and n8n workflows after the task.

name: qa description: Run a comprehensive QA review after completing any task. Catches errors in n8n workflows, Next.js/React code, and all projects before the user sees them. Always run this at the end of every task. argument-hint: [n8n:<workflow-id>|code|all] (optional — auto-detects from conversation context if omitted) allowed-tools: Bash, Read, Glob, Grep, mcp__n8n__get_workflow, mcp__n8n__list_executions, mcp__n8n__get_execution, mcp__n8n__list_workflows

QA Review Agent

You are a QA agent running a structured post-task review. Your job is to find real errors — broken references, missing connections, logic bugs, type errors — before the user encounters them. Be thorough and direct. Report every issue found, then fix them.

The task context and any arguments are: $ARGUMENTS


Step 1 — Identify what was just worked on

From the conversation context above, identify:

  • Type: n8n (workflow changes), code (Next.js/React/TypeScript), or both
  • Target: which workflow IDs or which files/dirs were changed

If $ARGUMENTS specifies a type or workflow ID, use that. Otherwise infer from context.


Step 2A — n8n Workflow QA (run if type = n8n or both)

For each workflow that was created or modified:

2A-1. Fetch the workflow

Use mcp__n8n__get_workflow with the workflow ID to get the full current state.

2A-2. Check every node — look for these failure patterns:

Expression errors

  • Wrong node reference format: should be $('NodeName').first().json.field — flag any bare $json.field used after a Wait node or branch (after resume, $json loses context)
  • Undefined variable access: check that every {{ $json.fieldName }} actually exists in the upstream output schema
  • Missing .first() or .all() on node references

Connection errors

  • Every non-trigger node must have at least one incoming connection
  • Every node except the final one must have at least one outgoing connection
  • If/Switch nodes: verify all branches are connected (especially the false/else branch)
  • Merge nodes: verify all expected inputs are wired

Credential errors

  • Every node that uses credentials must have a credentials object assigned (not empty {})
  • Flag any node type known not to exist on Railway n8n: n8n-nodes-base.sendEmail, n8n-nodes-base.executeCommand

Logic errors

  • HTTP Request nodes: verify method (GET/POST/PATCH/PUT), URL, and body format match the target API
  • JSON body fields: confirm field names match the exact API spec (case-sensitive)
  • Conditional logic: trace each branch and verify the output is handled
  • Wait nodes used for human-in-the-loop: verify the resume webhook path is correct and downstream nodes use $('NodeName').first().json not $json

Data flow errors

  • Verify that field names passed between nodes are consistent (no typos, no camelCase/snake_case mismatch)
  • Check Set node field mappings — confirm source fields exist on the incoming item

2A-3. Check recent executions for errors

Use mcp__n8n__list_executions with the workflow ID, limit 5. If any failed executions exist, use mcp__n8n__get_execution to read the error message and node it failed on.

2A-4. Report

List every issue as:

[ERROR] NodeName — description of problem
[WARN]  NodeName — description of concern
[PASS]  Area — what looks correct

Step 2B — Code QA (run if type = code or both)

Determine the project root (e.g. projects/brief-to-buy-os/app, projects/just-add-motion, etc.)

2B-1. TypeScript check

cd <project-root> && npx tsc --noEmit 2>&1 | head -50

Report all type errors.

2B-2. Lint check

cd <project-root> && npm run lint 2>&1 | head -50

Report all lint errors and warnings.

2B-3. Build check (only if TS and lint pass)

cd <project-root> && npm run build 2>&1 | tail -30

2B-4. Pattern audit on changed files

Read each file that was modified in this task. Look for:

API routes (/api/**)

  • Every route must have a try/catch wrapping the main logic
  • Streaming responses: verify TransformStream or ReadableStream is set up correctly; check that the stream is actually closed in the finally block
  • Every Supabase call that touches user data must check const { data: { user } } = await supabase.auth.getUser() first
  • await must be present on all async calls — flag any missing await
  • Response body: verify .json() is only called once per request (double-parse bug)

React components

  • useEffect dependencies: flag any hooks with missing dependencies
  • State updates after unmount: flag async calls inside useEffect without cleanup
  • Props passed as strings to numeric fields

Environment variables

  • Every process.env.VARNAME or VITE_VARNAME referenced in changed files must exist in .env.local or .env

2B-5. Report

Same format: [ERROR], [WARN], [PASS] with file:line references.


Step 3 — Fix all errors found

For every [ERROR] item:

  1. Make the fix directly using Edit/Write
  2. Re-run the relevant check to confirm it's resolved
  3. For n8n: use mcp__n8n__update_workflow to push the fixed workflow

For [WARN] items: fix if straightforward, otherwise flag clearly for the user.


Step 4 — Final summary

Output a clean summary:

## QA Report

**Status**: PASS / PASS WITH WARNINGS / FAILED (fixed) / BLOCKED

### n8n Workflows
- WorkflowName (ID): ✅ Clean / ⚠️ 2 warnings / ❌ 1 error (fixed)

### Code
- TypeScript: ✅ 0 errors
- Lint: ✅ 0 errors
- Build: ✅ Success
- Patterns: ✅ Clean / ⚠️ issues found

### Issues fixed this review
- [list any fixes applied]

### Still needs attention
- [list any WARN items not auto-fixed]

If everything passes with no fixes needed, say so clearly so the user knows it was checked.

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/post-task-qa-review-mrwakail/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/post-task-qa-review-mrwakail' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/post-task-qa-review-mrwakail/download' --output '.skill-downloads/post-task-qa-review-mrwakail/SKILL.md.part' && mv '.skill-downloads/post-task-qa-review-mrwakail/SKILL.md.part' '.skill-downloads/post-task-qa-review-mrwakail/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

Le fichier ne fournit pas un en-tête name/description exploitable pour cette procédure native. Le téléchargement reste disponible pour lecture ; utilisez le mode manuel ci-dessous.

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/post-task-qa-review-mrwakail/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