Synthèse automatique
Vérifie qu'un travail implémenté respecte un fichier spec.yml exécutable en contrôlant la couverture des critères d'acceptation et les preuves de tests rouge/vert.
Points forts
- Produit un tableau de couverture critère par critère avec statut, preuve et niveau de risque
- Distingue explicitement les statuts covered, ambiguous, uncovered, blocked et waived au lieu de considérer l'intention comme suffisante
- Contrôle aussi les hypothèses requises, les questions ouvertes et les critères de confidentialité/sécurité
- Interdit le déploiement en cas d'échec et exige une tâche de suivi ou une dérogation documentée
Limites
- Dépend de scripts propres au dépôt (spec_validate.py, spec_verify.py, sessions.py) qui doivent exister et être configurés
- Ne remplace pas l'exécution des tests : il confirme la cohérence des preuves, pas leur validité intrinsèque
- La validation des preuves Playwright suppose un déploiement sur l'environnement dev et un état Vercel Ready, ce qui est spécifique à ce dépôt
À utiliser avant de marquer une fonctionnalité comme terminée ou de déployer, lorsqu'un spec.yml exécutable sert de référence contractuelle.
À ne pas utiliser comme unique contrôle qualité sur un projet sans spec.yml ni scripts de vérification associés, ou pour valider du code sans critères d'acceptation formalisés.
Analyse de sécurité
SûrThe skill is a read-only conformance/verification workflow. It only reads spec.yml, product docs, and runs local python validation scripts, then emits a Markdown report. There are no destructive commands, no curl|sh piping, no base64 payloads, no secret/token exfiltration, and it explicitly refuses to mark work complete or deploy on failure. The only mild concern is unvetted execution of repo-local scripts, which is normal for a repo-internal QA skill.
- •Runs repository-local helper scripts (scripts/sessions.py, spec_validate.py, spec_verify.py) via bash without inspecting their contents; benign in intent (read-only validation) but trusts repo scripts implicitly
- •References a specific deployment target (app.dev.openmates.org) and dev deployment state as a gate condition; informational only, no credentials or tokens handled
Exemples
/verify-spec docs/specs/checkout-retry/spec.yml --phase greenVerify docs/specs/user-export/spec.yml against the implementation and tell me which acceptance criteria lack green test evidence before I deploy.There's no active session — do a document-only review of docs/specs/billing-webhook/spec.yml and report coverage gaps for each acceptance criterion.name: verify-spec description: Check implemented work against executable spec.yml before completion or deploy by validating acceptance criteria coverage and red/green test evidence user-invocable: true argument-hint: "docs/specs/<slug>/spec.yml [--phase red|green|complete]"
Instructions
You are performing a conformance check for spec-driven work. This is not a
replacement for tests; it confirms that tests and implementation evidence match
the executable spec.yml.
Step 1: Read Inputs
Read:
- The provided
docs/specs/<slug>/spec.yml - The
implementation_planandtaskssections inside that spec docs/contributing/guides/spec-driven-development.md- Current session status and related test tracking:
python3 scripts/sessions.py status --json python3 scripts/sessions.py check-tests --session <SESSION_ID>
If there is no active session, ask for the session ID or perform a document-only review.
Step 2: Build The Coverage Table
First run:
python3 scripts/spec_validate.py docs/specs/<slug>/spec.yml
python3 scripts/spec_verify.py docs/specs/<slug>/spec.yml --phase complete
For every scenario and acceptance criterion, record:
- Implemented: yes/no/partial/unknown
- Coverage: covered/ambiguous/uncovered/blocked/waived based on
coverage_status, linked tests, andverification_ids - Evidence: test file, command, manual verification, code reference, or gap
- Risk: none/low/medium/high
Step 3: Validate Required Evidence
Pass only when:
- Every completed acceptance criterion has green evidence.
- Every required acceptance criterion is covered, waived, or blocked by an accepted user/external dependency; ambiguous and uncovered criteria fail.
- Every required assumption whose
required_beforeisimplementationis confirmed, corrected and applied, waived, or externally blocked. - required assumptions with unchecked, checking, or contradicted status fail the implementation gate unless the user accepts a waiver or external blocker.
- Every required red phase has evidence before implementation. Red evidence may be failed as expected, passed unexpectedly with a reason, missing-test with a reason, skipped with a reason, or not applicable.
- Every required green/final check has passing, user-confirmed, waived, or accepted-blocker evidence.
- Privacy/security criteria have concrete code or test evidence.
- Changed source files have related tests or an explicit skip reason.
- Open questions are resolved or listed as accepted residual risk.
Failed required checks must not be treated as a summary-only issue. The report must identify the affected acceptance criteria and confirm that follow-up tasks exist or that the user explicitly accepted a waiver/blocker. failed required checks keep the spec active until the linked follow-up work is done or the user accepts a waiver/blocker.
Playwright green evidence is only valid after the implementation has been
deployed to dev, Vercel is Ready, and the spec has run against
app.dev.openmates.org.
Step 4: Output Report
Use this format:
## Spec Verification
Spec: docs/specs/<slug>/spec.yml
Status: pass | fail | partial
| ID | Status | Evidence | Risk |
| --- | --- | --- | --- |
| S-1 | pass | `frontend/...spec.ts` | none |
| AC-1 | pass | `python3 scripts/tests.py run ...` | none |
Gaps:
- <gap or none>
Deploy note:
- Spec: docs/specs/<slug>/spec.yml
- Tests: <commands/results>
- Residual risk: <none or concise note>
Step 5: Stop On Failure
If status is fail, do not deploy. Fix the gap, update the spec if product
intent changed, or ask the user to accept a documented risk.
Rules
- Do not mark criteria complete based on intent alone.
- Do not weaken or remove acceptance criteria to make verification pass.
- Do not mark ambiguous coverage as complete; normalize vague criteria into concrete checks first.
- Prefer Playwright/pytest/vitest via repo-approved test commands over manual browser checks.
- Manual verification is allowed only when automation is impractical and the reason is documented.
- Do not mark a full spec verified while required green evidence is missing.
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/spec-verification-mrzxuqlp/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/spec-verification-mrzxuqlp' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/spec-verification-mrzxuqlp/download' --output '.skill-downloads/spec-verification-mrzxuqlp/SKILL.md.part' && mv '.skill-downloads/spec-verification-mrzxuqlp/SKILL.md.part' '.skill-downloads/spec-verification-mrzxuqlp/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/spec-verification-mrzxuqlp/SKILL.md' && test -s '.skill-downloads/spec-verification-mrzxuqlp/SKILL.md' && mkdir -p '.claude/skills' && test ! -e '.claude/skills/verify-spec' && cp -R '.skill-downloads/spec-verification-mrzxuqlp' '.claude/skills/verify-spec'Cursor
test -f '.skill-downloads/spec-verification-mrzxuqlp/SKILL.md' && test -s '.skill-downloads/spec-verification-mrzxuqlp/SKILL.md' && mkdir -p '.cursor/skills' && test ! -e '.cursor/skills/verify-spec' && cp -R '.skill-downloads/spec-verification-mrzxuqlp' '.cursor/skills/verify-spec'Codex
test -f '.skill-downloads/spec-verification-mrzxuqlp/SKILL.md' && test -s '.skill-downloads/spec-verification-mrzxuqlp/SKILL.md' && mkdir -p '.agents/skills' && test ! -e '.agents/skills/verify-spec' && cp -R '.skill-downloads/spec-verification-mrzxuqlp' '.agents/skills/verify-spec'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/spec-verification-mrzxuqlp'openskills read 'spec-verification-mrzxuqlp'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/spec-verification-mrzxuqlp/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.
Comparaison de performances ClickHouse
Testing
Évaluez les résultats de tests de performance ClickHouse, analysez les régressions de PR, comparez avec l'historique et vérifiez la fiabilité des mesures.
Analyse des rapports de performance CI
Testing
Analyse les rapports de comparaison de performance CI pour une PR ClickHouse. Recoupe l'historique master pour distinguer les vraies régressions des tests instables.
Méthode Santa
Testing
Vérification adversarial multi-agents avec deux réviseurs indépendants. La sortie est vérifiée deux fois et corrigée itérativement jusqu'à ce que les deux acceptent avant publication.