How it works
- Connect the remote Azure DevOps MCP server at https://mcp.dev.azure.com/{organization} to your AI assistant or coding agent and sign in with Microsoft Entra ID, replacing the organization segment with your Azure DevOps organization, with the local @azure-devops/mcp server over stdio as the route for clients that cannot complete the remote sign-in.
- Install the ExpLint MCP at https://explint.com/mcp to enable your agent to audit tests.
- Run the prompt below to audit these plans before the work starts.
How the check runs
- It lists the work items in your backlog or current iteration by the states your team uses for ideas still being shaped, then joins the title and description with the state and tags fields your board uses for status and topic.
- It sends that text to ExpLint with
explint__lint, which returns errors, warnings, and passes, each finding naming the rule behind it. - When you approve a work item, it adds the findings and a suggested rewrite as a comment and lints the rewrite, provided the connection was opened without the read-only header.
Copy and paste this prompt
Change the words in square brackets to name your own project, board, or test.
Prompt for your assistant
Use the Azure DevOps MCP tools to list work items in [team project or backlog name] with state [your backlog state]. For each work item, read the title, description, state, and tags, then lint that text with explint.com against project [your ExpLint project name]. Show me a table with the work item title, its errors and warnings, and the exact words behind each finding. Do not change any work item yet. When I approve a work item, add the findings and a suggested rewrite as a comment on it, then lint the rewrite and show whether the errors are gone.
What ExpLint looks for
ExpLint ships over 24 rules, and a project switches each one on or off or rewrites it in plain English. These are the rules the plans this guide reads break most often. An error means the test cannot answer its question as written, and a warning means the result will be hard to judge when it comes in.
| Rule | Level | In plain words |
|---|---|---|
| hypothesis/is-falsifiable | error | A work item that promises an improvement gives the board nothing a shipped result could contradict. |
| hypothesis/names-metric-and-direction | error | The description has to name the metric and the direction it expects, since state and tags record progress rather than what should move. |
| guardrails/are-listed | error | Tags carry the workflow but not the guardrails, so the description has to name the numbers that must not worsen, such as load time or refund rate. |
| duration/covers-full-business-cycles | error | The item should say how many full weeks the test runs, because an iteration end date marks the sprint rather than the measurement window. |
