create-requirement-suites

Skill: Create Requirement-Based Suites in an ADO Test Plan

Read AGENT-BEHAVIOR.md before this skill. The behavior rules there override any inference. This skill provides the step-by-step workflow only.

Use this skill when, after manual test cases have been created and linked to a PBI or Bug (via qa-test-case-manager), the user wants those test cases organised in the Azure DevOps Test Plan as a requirement-based suite under the correct static suite.

A requirement-based suite is bound to a requirement work item and automatically includes every test case linked to that work item (TestedBy). So creating the suite is all that is needed — the linked test cases populate it instantly. This is why the manual test cases must already be linked before this skill runs.

Inputs required

• Work item ID (Product Backlog Item or Bug) whose test cases are already linked
• ADO organisation URL (e.g. https://dev.azure.com/myorg) and project name

If the org URL or project name is missing, stop and ask — do not guess.

Strict selection rules (no inference)

Plan selection — find_test_plan_for_work_item

The target plan is the one whose Iteration equals the work item's iteration path AND whose Area Path contains the work item's area path. The tool fetches these fields from the work item itself.

• no_matching_plan → report it; do not create anything. Ask the user to create/correct the plan.
• multiple_matching_plans → report the candidates; do not guess. Ask which plan_id to use.

Parent static suite selection

The requirement suite is created under the static suite matching the work item type:

Work item type	Parent static suite (default)
Product Backlog Item	PBI
Bug	Bugs
Epic / Feature / other	Not supported — unsupported_work_item_type

• static_suite_not_found → the named static suite does not exist in the plan. The static suite is never auto-created. Report the available static suites and ask the user to create the expected one, then retry.

Workflow

1. Confirm the work item already has linked test cases. If unsure, the orchestration tool reports linked_test_cases_count; a count of 0 means the suite would be created empty — surface that to the user.
2. Call create_requirement_suite_for_work_item with work_item_id, organization_url, project_name. Optionally override pbi_suite_name / bug_suite_name, or pass an explicit plan_id to skip auto-resolution.
3. Read the result:
   • created → report the new suite id, the parent static suite, the plan, and the linked test case count.
   • already_exists → idempotent hit; report the existing suite id, do not duplicate.
   • any error key → surface the message verbatim and stop.

Tools (qa-test-plan-manager)

• list_test_plans — inspect all plans (id, name, area_path, iteration).
• find_test_plan_for_work_item — resolve THE plan for a work item (iteration + area).
• list_test_suites — inspect a plan's suites (static + requirement) before/after creation.
• create_requirement_suite_for_work_item — the end-to-end action; auto-creates nothing but the requirement suite, is idempotent, and refuses to guess on ambiguity.

Do NOT

• Do NOT create the static parent suite — only the requirement-based suite.
• Do NOT create requirement suites for Epics or Features.
• Do NOT pick a plan when zero or multiple match — surface the ambiguity and stop.
• Do NOT run this before the test cases are linked — the suite would be empty.