Requirement Analyst

The Requirement Analyst plugin acts as a thinking partner for product owners, BAs, and engineers. Instead of judging whether a backlog item is “ready,” it surrounds the item with the context a senior analyst would bring to a refinement session — relevant domain knowledge, how comparable products solve the same problem, the user journeys that touch this change, the personas affected, and the usability and adoption questions worth answering before any code is written.

It works with GitHub Issues, Azure DevOps Work Items, or plain text input.

What You Get Back

Each run produces a structured elaboration posted directly on the backlog item. The goal is to expand your thinking, not to gate the work:

Fit with existing requirements — if the repository contains other requirement documents (PRDs, specs, RFCs, ADRs, feature briefs, user stories), the plugin reads them and reasons about how the new ask fits the existing product context: overlaps, dependencies, contradictions, and gaps. This is a product-level analysis, not a code-level one.
Domain perspective — concepts, terminology, regulations, and patterns from the relevant industry or problem space.
Competitive & market context — how established products, open-source alternatives, or competitors typically approach this problem, and what users have come to expect.
User journeys — the end-to-end flows the change participates in, including upstream triggers and downstream consequences.
Persona impact — who is affected, how their goals differ, and where friction is most likely to appear.
Usability considerations — accessibility, discoverability, error states, empty states, edge cases, and “what happens when…” questions.
Adoption considerations — onboarding, migration, change management, documentation needs, and signals that would tell you the feature is actually being used.
Open questions & gaps — assumptions worth validating and acceptance criteria worth tightening, framed as prompts for the team rather than blockers.

A lightweight readiness signal (GROOMED, NEEDS CLARIFICATION, or NEEDS DECOMPOSITION) is also applied as a label, but it’s a hint for triage — the real value is in the elaboration itself.

How It Works

flowchart TD
    A[Fetch backlog item] --> B[Index project docs]
    B --> C[Classify requirement]
    C --> D[Phase 1: 4 analysts in parallel]
    D --> E[Phase 2: Gap & risk analysis]
    E --> F[Compile elaboration & post insights]

Fetch item — pulls the issue/work-item from GitHub (gh) or Azure DevOps (REST API).
Index project context — scans READMEs, manifests, and any requirement documents in the repo (PRDs, specs, RFCs, ADRs, feature briefs, user stories under /docs, /specs, /requirements, etc.) to build a ~500-word project summary and a map of existing requirements. The new item is then reasoned about against that map — how it complements, extends, conflicts with, or duplicates what is already specified — at the product/requirements level, not the code level.
Classify — determines type (story / task / bug / spike), domain, and complexity to tune the depth of analysis.
Phase 1 (parallel) — four analysts contribute different lenses simultaneously:
- Intent — surfaces the underlying user need and the “why” behind the ask.
- Domain — brings in relevant domain knowledge, industry conventions, and how competitors or comparable products handle the same problem.
- Journey — maps the user workflow around this requirement, including usability touchpoints and friction risks.
- Persona — identifies affected user personas and adoption considerations specific to each.
Phase 2 — a Gap & Risk analyst reviews Phase 1 output to surface missing acceptance criteria, edge cases, and risks as discussion prompts.
Compile & post — findings are formatted and posted as ordered comments on the issue, ready for the team to react to in the next refinement.

For unsupported platforms, the output is written to requirement-elaboration-report.md.

Inputs

Input	Source	Required	Description
Repository URL	Agent rule	Yes	The repository containing the backlog item — provided by the Xianix Agent rule, not typed in the prompt
Issue / Work-item number	Prompt	Yes	The backlog item to analyze (e.g. `42`)

The platform (GitHub, Azure DevOps, etc.) is auto-detected from git remote — you don’t need to specify it.

Sample Prompt

/requirement-analysis 42

Environment Variables

The Xianix Agent reads these from its secrets store and injects them at runtime via the rule’s with-envs block (see the rule examples below). For local CLI use, export them in your shell.

Variable	Platform	Required	Purpose
`GITHUB-TOKEN`	GitHub	Yes	Authenticate `gh` CLI for reading issues and posting comments
`AZURE-DEVOPS-TOKEN`	Azure DevOps	Yes	PAT for REST API calls (read work items, post comments)

Quick Start

# Point Claude Code at the plugin
claude --plugin-dir /path/to/xianix-plugins-official/plugins/req-analyst

# Then in the chat
/requirement-analysis 42

Or trigger it automatically via the Xianix Agent by adding a rule — see the examples below and the Rules Configuration guide.

Rule Examples

Add one (or both) of the execution blocks below to your rules.json so the Xianix Agent automatically grooms backlog items when a webhook fires.

When does the agent trigger?

The Requirement Analyst uses a different “ask the agent” mechanism on each platform:

GitHub — tag-driven. Add the ai-dlc/issue/analyze label to an issue (or open the issue with that label already on it).
Azure DevOps — assignment-driven. Assign the work item to xianix-agent <xianix-agent@99x.io> and set its state to To Do. No tag is needed.

Scenario	What it covers
GitHub — tag newly applied	A human (or another rule) adds `ai-dlc/issue/analyze` to an existing issue
GitHub — issue opened with tag	The issue is created with the label included from the start
Azure DevOps — assigned to agent in `To Do`	The work item’s assignee is changed to `xianix-agent <xianix-agent@99x.io>` while the state is `To Do`

Platform	Scenario	Webhook event	Filter rule
GitHub	Tag newly applied	`issues`	`action==labeled` and `label.name=='ai-dlc/issue/analyze'`
GitHub	Issue opened with tag	`issues`	`action==opened` and `ai-dlc/issue/analyze` is in `issue.labels`
Azure DevOps	Assigned to xianix-agent in `To Do`	`workitem.updated`	`resource.fields."System.AssignedTo".newValue=='xianix-agent <xianix-agent@99x.io>'` and `resource.revision.fields."System.State"=='To Do'`

Execution-block shape

Each execution block in rules.json follows this top-level shape:

Field	Purpose
`name`	Human-readable id for the execution
`platform`	`"github"` or `"azuredevops"` — drives which provider the plugin uses
`repository.url`	Webhook path to the repository URL (e.g. `repository.clone_url`). Omit the entire `repository` block for Azure DevOps work items — the work item itself is not bound to a single repo.
`repository.ref`	Optional. Webhook path to the branch ref. Not used by req-analyst — included only when the plugin needs to read repo content for a specific branch.
`match-any`	Array of trigger filters — first one to match wins
`use-inputs`	Minimal — usually just the entry-point id (e.g. `issue-number`, `workitem-id`). The repository URL is injected automatically from the `repository` block when present. Mark inputs the plugin must have as `mandatory: true`.
`use-plugins`	The plugin to invoke
`with-envs`	Required environment variables, sourced from the agent’s `secrets.*` store and marked `mandatory: true`
`execute-prompt`	The prompt sent to the agent. Implicit interpolations: `{{repository-name}}` from the `repository` block (when present), plus any `name` from `use-inputs`

GitHub

{
  "name": "github-issue-requirement-analysis",
  "platform": "github",
  "repository": {
    "url": "repository.clone_url"
  },
  "match-any": [
    {
      "name": "github-issue-tag-applied",
      "rule": "action==labeled&&label.name=='ai-dlc/issue/analyze'"
    },
    {
      "name": "github-issue-opened-with-tag",
      "rule": "action==opened&&issue.labels.*.name=='ai-dlc/issue/analyze'"
    }
  ],
  "use-inputs": [
    { "name": "issue-number", "value": "issue.number", "mandatory": true }
  ],
  "use-plugins": [
    {
      "plugin-name": "req-analyst@xianix-plugins-official",
      "marketplace": "xianix-team/plugins-official"
    }
  ],
  "with-envs": [
    { "name": "GITHUB-TOKEN", "value": "secrets.GITHUB-TOKEN", "mandatory": true }
  ],
  "execute-prompt": "Issue #{{issue-number}} in the repository {{repository-name}} has been assigned to xianix-agent for requirement analysis.\n\nRun /requirement-analysis {{issue-number}} to perform the automated requirement analysis and elaboration."
}

Azure DevOps

{
  "name": "azuredevops-work-item-requirement-analysis",
  "platform": "azuredevops",
  "match-any": [
    {
      "name": "azuredevops-workitem-assigned-to-agent",
      "rule": "eventType==workitem.updated&&resource.fields.\"System.AssignedTo\".newValue=='xianix-agent <xianix-agent@99x.io>'&&resource.revision.fields.\"System.State\"=='To Do'"
    }
  ],
  "use-inputs": [
    { "name": "workitem-id", "value": "resource.workItemId" }
  ],
  "use-plugins": [
    {
      "plugin-name": "req-analyst@xianix-plugins-official",
      "marketplace": "xianix-team/plugins-official"
    }
  ],
  "with-envs": [
    { "name": "AZURE-DEVOPS-TOKEN", "value": "secrets.AZURE-DEVOPS-TOKEN", "mandatory": true }
  ],
  "execute-prompt": "Work item #{{workitem-id}} has been assigned to xianix-agent for requirement analysis.\n\nRun /requirement-analysis {{workitem-id}} to perform the automated requirement analysis and elaboration."
}