Valider la Définition de Prêt (DoR)

VérifiéPrudence

Valide un ou plusieurs éléments de travail contre la liste de contrôle DoR. Récupère la page wiki, évalue chaque critère et publie un commentaire interactif dans ADO/Jira.

Spar Skills Guide Bot
DeveloppementIntermédiaire
24/07/2026
Claude Code
#definition-of-ready#azure-devops#jira#agile#backlog-refinement

Recommandé pour

Synthèse automatique

Valide une ou plusieurs user stories contre la checklist Definition of Ready du projet, produit un scorecard et publie un commentaire interactif dans ADO ou Jira.

Points forts

  • Récupère automatiquement la page wiki DoR et évalue chaque critère du story pour générer un scorecard détaillé
  • Gère trois modes de commentaire (premier post, mise à jour après changements, réutilisation si rien n'a bougé) pour éviter les doublons
  • Traite plusieurs IDs en parallèle via des sous-agents et renvoie un tableau récapitulatif
  • Prend en charge un tag `mandatory` pour les critères bloquants qui échouent quel que soit le score global

Limites

  • Nécessite une configuration MCP ADO ou Atlassian fonctionnelle, un fichier `.ai/config.yaml` et une page wiki DoR accessible
  • La qualité de l'évaluation dépend fortement de la structure de la checklist wiki et du contenu textuel du story
  • Ne corrige pas le story : l'outil se limite à évaluer et à commenter, la remédiation reste manuelle
Quand l'utiliser

À utiliser au démarrage d'un sprint ou lors du raffinement pour vérifier objectivement qu'une story respecte la Definition of Ready avant de lancer le développement.

Quand l'éviter

À éviter si votre équipe n'a pas de checklist DoR formalisée sur un wiki ou si l'accès MCP à ADO/Jira n'est pas configuré dans l'environnement.

Analyse de sécurité

Prudence
Score qualité78/100

The skill is a legitimate Definition-of-Ready validator. It contains no shell execution, no destructive commands, no credential/token exfiltration, and no obfuscated payloads. Its risk is limited to powerful-but-purposeful capabilities: MCP network reads, local file writes, comment posting to ADO/Jira, and fan-out subagent dispatch. These warrant a caution rating because it mutates shared tracker state and runs autonomous subagents, but nothing indicates malicious or unsafe intent.

Points d'attention
  • •Writes to external systems: posts/edit ADO/Jira comments on real work items, which is a state-changing side effect on shared tracker data
  • •Spawns parallel subagents that re-invoke the same skill (/dx-dor <id>) — recursion is bounded by one ID per subagent, but it is autonomous multi-agent execution
  • •Creates and modifies local files (.ai/specs/<id>-<slug>/, .ai/cache/dor-checklist.md) without explicit user confirmation
  • •Performs network fetches of wiki/Confluence pages via MCP and converts HTML to markdown; depends on shared/external-content-safety.md for sanitization rather than enforcing it inline
Comment cette analyse est faite

Exemples

Single story DoR check
Check DoR for work item 4821 and post the scorecard comment.
Batch validation at sprint start
Validate readiness for 4821 4830 4837 4842 and give me a summary table of which stories are ready.
Re-check after refinement
Is story 4821 ready now? I updated the acceptance criteria and dependencies — re-validate and refresh the DoR comment.

name: dx-dor description: Validate Definition of Ready — fetch wiki checklist, evaluate story, post ADO comment. Use standalone at sprint start, in batch, or as part of /dx-req. when_to_use: "Use at sprint start to validate a story's Definition of Ready before development. Trigger on 'check DoR', 'is this story ready', 'validate readiness', 'dor check', or when given a story ID at the start of a sprint." argument-hint: "<Work Item ID(s) — space-separated for batch>" model: sonnet allowed-tools: ["read", "edit", "search", "write", "agent", "ado/", "atlassian/"]

Validate one or more work items against the project's Definition of Ready checklist. Fetches the DoR wiki page, evaluates each criterion against the story content, generates a scorecard, and posts an interactive ADO/Jira comment with checkboxes for BA collaboration. Supports three modes: first post (Mode A), update after changes (Mode B), and reuse when nothing changed (Mode C). Supports mandatory tag for hard-gate checks that block regardless of overall score.

Flow

digraph dx_dor {
    "Parse argument(s)" [shape=box];
    "Single or batch?" [shape=diamond];
    "Fetch story" [shape=box];
    "Fetch DoR wiki" [shape=box];
    "Existing [DoRAgent] comment?" [shape=diamond];
    "Read checkbox state + compare story" [shape=box];
    "Changes detected?" [shape=diamond];
    "Re-fetch story + re-validate" [shape=box];
    "Materialize comment → dor-report.md (Mode C)" [shape=box];
    "Parse wiki → build criteria" [shape=box];
    "Evaluate story against criteria" [shape=box];
    "Generate dor-report.md" [shape=box];
    "Post ADO comment" [shape=box];
    "Done" [shape=doublecircle];
    "Spawn parallel subagents" [shape=box];

    "Parse argument(s)" -> "Single or batch?";
    "Single or batch?" -> "Fetch story" [label="single"];
    "Single or batch?" -> "Spawn parallel subagents" [label="multiple IDs"];
    "Spawn parallel subagents" -> "Done";
    "Fetch story" -> "Fetch DoR wiki";
    "Fetch DoR wiki" -> "Existing [DoRAgent] comment?";
    "Existing [DoRAgent] comment?" -> "Read checkbox state + compare story" [label="yes"];
    "Existing [DoRAgent] comment?" -> "Parse wiki → build criteria" [label="no"];
    "Read checkbox state + compare story" -> "Changes detected?";
    "Changes detected?" -> "Re-fetch story + re-validate" [label="yes"];
    "Changes detected?" -> "Materialize comment → dor-report.md (Mode C)" [label="no"];
    "Re-fetch story + re-validate" -> "Generate dor-report.md";
    "Materialize comment → dor-report.md (Mode C)" -> "Done";
    "Parse wiki → build criteria" -> "Evaluate story against criteria";
    "Evaluate story against criteria" -> "Generate dor-report.md";
    "Generate dor-report.md" -> "Post ADO comment";
    "Post ADO comment" -> "Done";
}

Node Details

Parse argument(s)

  • Read shared config: shared/provider-config.md, shared/external-content-safety.md
  • Read .ai/config.yaml for provider, project, repo
  • Parse argument: split on whitespace to produce a list of IDs
  • If no argument provided, check for an active spec dir and extract the ID from its directory name

Single or batch?

  • If 1 ID: continue to "Fetch story"
  • If 2+ IDs: continue to "Spawn parallel subagents"

Spawn parallel subagents

  • For each ID, use the Agent tool to dispatch a subagent with prompt: Run /dx-dor <id>
  • Run all agents in parallel
  • Collect results and present a summary table

Fetch story

  • If .ai/specs/<id>-*/ exists, reuse it as $SPEC_DIR. Otherwise fetch title via MCP, slugify, create mkdir -p .ai/specs/<id>-<slug>/
  • Fetch work item via MCP (ADO: mcp__ado__wit_get_work_item, Jira: mcp__atlassian__jira_get_issue)
  • Fetch comments (ADO: mcp__ado__wit_list_work_item_comments, Jira: comments included in issue response)
  • If raw-story.md doesn't exist, convert HTML to markdown per shared/external-content-safety.md and write it. If it exists and is current, reuse.

Fetch DoR wiki

  • Read references/wiki-parsing.md for the full parsing and fallback chain logic
  • Cache first: check .ai/cache/dor-checklist.md (TTL 24h, override via dor.cache-ttl-seconds). If hit, skip the MCP call entirely — the checklist rarely changes and a tree-traversal wiki_get_page against a parent section pulls ~270kB of JSON (≈65–80k tokens) into the parent thread. This is the second-largest Phase 1 context cost (issue #136).
  • Cache miss: fetch the wiki page using the URL from config (scm.wiki-dor-url — preferred, no tree traversal) or Confluence (confluence.dor-page-title). If URL resolution fails, use wiki_search with the page title — never wiki_get_page against a parent section. If a tree fetch is genuinely needed, dispatch it to a subagent so the raw JSON never lands here.
  • Write the resolved body to .ai/cache/dor-checklist.md with metadata in .ai/cache/dor-checklist.meta.json

Existing [DoRAgent] comment?

  • Scan fetched comments for text containing [DoRAgent] Definition of Ready Check
  • If found: continue to "Read checkbox state"
  • If not found: continue to "Parse wiki -> build criteria"

Read checkbox state + compare story

Two change checks — either one triggers re-validation:

  1. Checkbox changes: Parse - [x] and - [ ] lines from the existing comment. Compare against the original post state to detect BA checkbox updates.
  2. Story content changes: Compare the fetched story (from "Fetch story" step) against $SPEC_DIR/raw-story.md (if it exists). Check title, description, acceptance criteria, and comment count. If ANY differ, the ticket was updated since the last DoR run.

Changes detected?

  • If any checkbox changed from [ ] to [x] since original post: yes → print: BA checked <N> items: <list>. Re-validating...
  • If story content changed (description, AC, or new comments): yes → print: Ticket updated since last DoR check (changed: <fields>). Re-validating...
  • If both unchanged: no → continue to "Materialize comment → dor-report.md (Mode C)"

Re-fetch story + re-validate

  • Re-fetch work item via MCP to get latest content (already fetched in "Fetch story" — reuse that data)
  • Update $SPEC_DIR/raw-story.md with fresh content
  • Re-run evaluation against wiki criteria

Materialize comment -> dor-report.md (Mode C)

  • Parse the existing ADO comment back into dor-report.md format
  • Write to $SPEC_DIR/dor-report.md
  • Print: DoR comment already posted to ADO #<id> — no changes — reusing.

Parse wiki -> build criteria

  • Parse the wiki content per references/wiki-parsing.md
  • Build structured list of sections with criteria and skip triggers

Evaluate story against criteria

  • For each section: check skip trigger against change type
  • For each criterion: evaluate against raw-story.md content
    • mandatory: Pass or Fail (HARD GATE — a Fail here overrides the final verdict)
    • required: Pass or Fail
    • recommended: Pass or Warn
    • human: Warn always (needs human judgment)
  • Extract structured BA data (component, dialog, design, scope) per references/wiki-parsing.md
  • Generate open questions per pragmatism rules (read rules/pragmatism.md)

Generate dor-report.md

  • Compute score from applicable required criteria
  • Apply scoring thresholds from wiki ## Scoring section
  • Mandatory gate: After computing the count-based verdict, check if any mandatory-tagged criterion has status Fail. If yes, override verdict to "Needs more detail — MANDATORY criteria not met: <comma-separated list of failed mandatory criteria>" regardless of the count-based score. This gate fires AFTER evaluation but BEFORE writing the report.
  • Write $SPEC_DIR/dor-report.md per output format in references/wiki-parsing.md

Post ADO comment

  • Read references/comment-format.md for Mode A/B posting logic
  • Mode A (first post): full checklist with interactive checkboxes
  • Mode B (update): short delta comment with resolved/remaining items

Done

  • Print verdict: DoR: <verdict> (<score>/<total>)

Examples

Single work item

/dx-dor 2416553

Fetches story #2416553, evaluates against DoR checklist, writes dor-report.md, posts ADO comment.

Batch validation at sprint start

/dx-dor 2416553 2416554 2416555

Spawns parallel subagents, each validating one item. Prints summary table at the end.

Re-run after BA updates (checkboxes or ticket content)

/dx-dor 2416553

Detects existing [DoRAgent] comment. Checks for BA checkbox changes AND ticket content changes (description, AC, new comments). If either changed → re-fetches story, re-validates, posts Mode B update. If neither changed → Mode C reuse.

Rules

  • Config-driven — never hardcode wiki URLs, project names, or org details. Read everything from .ai/config.yaml.
  • Idempotent — safe to re-run. Detects existing comments and adapts (Mode A/B/C).
  • Pragmatic questions — self-discover answers before asking. Target 2-5 open questions, not an interrogation.
  • Interactive checkboxes — ADO comments use - [ ] checkboxes so BAs can mark items resolved directly in ADO.
  • Always use [DoRAgent] text signature — never use HTML comments like <!-- ai:role:dor-agent --> for detection.

Platform Compatibility

This skill uses Agent() for batch mode and MCP tools for ADO/Jira, which work on both Claude Code and Copilot CLI.

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/validate-definition-of-ready-dor-mryiqgp4/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/validate-definition-of-ready-dor-mryiqgp4' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/validate-definition-of-ready-dor-mryiqgp4/download' --output '.skill-downloads/validate-definition-of-ready-dor-mryiqgp4/SKILL.md.part' && mv '.skill-downloads/validate-definition-of-ready-dor-mryiqgp4/SKILL.md.part' '.skill-downloads/validate-definition-of-ready-dor-mryiqgp4/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/validate-definition-of-ready-dor-mryiqgp4/SKILL.md' && test -s '.skill-downloads/validate-definition-of-ready-dor-mryiqgp4/SKILL.md' && mkdir -p '.claude/skills' && test ! -e '.claude/skills/dx-dor' && cp -R '.skill-downloads/validate-definition-of-ready-dor-mryiqgp4' '.claude/skills/dx-dor'

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/validate-definition-of-ready-dor-mryiqgp4'

openskills read 'validate-definition-of-ready-dor-mryiqgp4'

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/validate-definition-of-ready-dor-mryiqgp4/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