Validate Definition of Ready (DoR)

VerifiedCaution

Validate one or more work items against the DoR checklist. Fetches the wiki page, evaluates each criterion, and posts an interactive ADO/Jira comment with checkboxes.

Sby Skills Guide Bot
DevelopmentIntermediate
7/24/2026
Claude Code
#definition-of-ready#azure-devops#jira#agile#backlog-refinement

Recommended for

Automated summary

Validates one or more user stories against the project's Definition of Ready checklist, produces a scorecard, and posts an interactive comment in ADO or Jira.

Strengths

  • Automatically fetches the DoR wiki page and evaluates each criterion against the story to build a detailed scorecard
  • Handles three comment modes (first post, update after changes, reuse when nothing changed) to avoid duplicate comments
  • Processes multiple IDs in parallel through subagents and returns a summary table
  • Supports a `mandatory` tag for hard-gate criteria that block regardless of the overall score

Limitations

  • Requires a working ADO or Atlassian MCP setup, an `.ai/config.yaml` file, and a reachable DoR wiki page
  • Evaluation quality depends heavily on how the wiki checklist is structured and on the story's textual content
  • Does not fix the story: it only evaluates and comments, so remediation stays manual
When to use it

Use it at sprint start or during backlog refinement to objectively confirm a story meets the Definition of Ready before development begins.

When not to use it

Avoid it if your team has no formalized DoR checklist on a wiki or if MCP access to ADO/Jira is not configured in the environment.

Security analysis

Caution
Quality score78/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.

Findings
  • •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
How this analysis is made

Examples

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.

From the file to a first result

The download contains exactly the content displayed on this page. This copy may differ from the latest version in the source repository.

View the source and supporting files

This download contains SKILL.md only. Any scripts, references, templates and dependencies are not included. Get the required files from the source, preserving their directory structure, before continuing.

1. Download the file

Download SKILL.md

From the root of a test project, save the file as .skill-downloads/validate-definition-of-ready-dor-mryiqgp4/SKILL.md, or use the command below. This folder is for inspecting the skill before installation.

Command for macOS/Linux or WSL: requires a POSIX shell and curl. On Windows without WSL, use the download button and create the folder manually.

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. Check prerequisites

Read SKILL.md before using it. If it references scripts or external services, inspect them and prepare the required access in your test environment.

No recognized prerequisites section in this file. This does not mean it is self-contained: libraries, tools and access requirements may be mentioned elsewhere in the content or source repository.

The platforms on this page are catalog indications. The paths below follow tool documentation; they do not prove this skill has been run in those tools. No minimum tool version is confirmed for this listing.

3. Load the skill

After inspection, copy the complete folder into your project using one of the commands below, then open a new tool session. The command stops if a folder with the same name already exists: compare the files before replacing it.

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 must already be installed. The local install/read procedure is checked with OpenSkills 1.5.0, which requires Node.js ≥ 20.6.0. Catalog slugs are not resolved automatically.

Official OpenSkills installation
openskills install './.skill-downloads/validate-definition-of-ready-dor-mryiqgp4'

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

Reading should display the installed file content and its base directory. It does not run the skill or install its dependencies.

For an agent that reads AGENTS.md, then sync the index. This command changes AGENTS.md: review the diff before using it.

openskills sync

Manual method or another tool: attach SKILL.md to a conversation, or open it in an agent that can read files. Include any required supporting resources. No universal folder is recognized by every tool.

4. Try a first task

Use a short, synthetic input: an API endpoint, a small document or an interface brief. In a new conversation, attach the file or give the agent its path, then adapt this request:

Read .skill-downloads/validate-definition-of-ready-dor-mryiqgp4/SKILL.md and apply its instructions to this example: [describe a test input]. Identify any missing files, dependencies or access. Produce the result requested by the skill without inventing data or running unreviewed scripts.

Expected result: output matching the skill instructions, or a precise list of missing prerequisites. A read confirmation alone does not validate a first use. If an external resource is unavailable, that path remains untested.

Related skills