Jira → TestRail case generator

Convert acceptance criteria from a Jira ticket into TestRail test cases under a chosen section.

Preconditions — check before doing anything else

1. A Jira tool must be available in this session. Look for any tool exposing Jira issue reads (e.g. mcp__atlassian__getJiraIssue, mcp__jira__get_issue, etc.). If none exists, stop and tell the user: "I need a Jira MCP connected to read the ticket. Please install one (e.g. Atlassian's official MCP) and re-run."
2. The TestRail MCP must be available (tools prefixed with mcp__testrails__ such as list_projects, add_case). If not, stop and tell the user to install/register testrails-mcp.
3. The user must have provided a destination. See Step 0 below — do not skip it.

Inputs to gather

• jira_key — e.g. PROJ-1234. Accept a full URL too and parse the key out.
• section_id — TestRail section the cases will be created under. Required.
• suite_id (optional) — only relevant for multi-suite projects. If unsure, infer from the section.

Step 0 — Establish the destination (do this first, always)

Before reading the Jira ticket, before doing anything else, confirm you have a section_id.

If the user provided a numeric `section_id` (e.g. "section 47", "under section_id 47"): use it. Skip to Step 1.

If the user provided names instead of an ID (e.g. "the Authentication section in the Login suite of the Mobile App project"): resolve them via list_projects → list_suites → list_sections. Once you have the section_id, confirm the resolved path back to the user in one line ("Found: Mobile App › Login › Authentication (section 47). Proceed?") and wait for yes before continuing.

If the user provided no destination at all: do NOT guess, do NOT pick a default, do NOT proceed to read the ticket. Ask. Walk them through it interactively:

1. Call list_projects and present the list as a numbered menu. Ask which project.
2. After they pick, call list_suites(project_id). If exactly one suite exists, use it silently. If more than one, present as a numbered menu and ask.
3. Call list_sections(project_id, suite_id). Present as a numbered menu (indent nested sections to show hierarchy). Ask which section.
4. Confirm the full path back to them and wait for explicit "yes" before moving on.

Never call add_case without a confirmed section_id. If the user tries to skip ahead ("just create them, you pick"), refuse and ask again — destination is the user's call, not yours.

Workflow

Step 1 — Read the ticket

Call the Jira read tool for jira_key. Pull out:

• Summary — seed for case titles.
• Acceptance Criteria — the primary source. Each AC becomes one case. If ACs are written as Gherkin (Given/When/Then), preserve that structure in the steps field.
• Description / reproduction steps — use for preconditions and step detail.
• Linked issues — capture keys for the refs field.
• Priority — for mapping to TestRail priority.

If the ticket has no acceptance criteria, do NOT invent any. Surface this and ask the user whether to derive cases from the description or abort.

Step 2 — Discover the TestRail custom-field shape

TestRail instances vary: some use custom_steps (plain text), others custom_steps_separated (structured list of {content, expected} dicts). Before writing cases:

1. Call list_cases for the target section with limit=1.
2. If a case exists, call get_case on it and inspect which custom_steps* fields are populated.
3. Use the same shape for the new cases. If no existing case is available, default to custom_steps (plain text) and tell the user you're doing so.

Step 3 — Draft the cases

For each acceptance criterion produce a case object:

• title: concise, behavior-focused, ≤ 100 chars. Prefer "User can …" / "System rejects …" over "Test that …".
• refs: jira_key plus any linked keys, comma-separated.
• priority_id: map Jira priority → TestRail (Highest/High → 4, Medium → 3, Low/Lowest → 2). Omit if unsure.
• custom_fields:
• custom_steps (or custom_steps_separated) — the test steps.
• custom_preconds — preconditions if the ticket implies any.
• custom_expected — only if the instance uses a separate expected-result field.

One AC → one case. Do not bundle multiple behaviors. If an AC has multiple distinct assertions, split it.

Step 4 — Confirm before creating

Show the user the proposed cases as a numbered list with title + steps. Ask explicitly: "Create these N cases in section {section_id}? (yes/no/edit)". Do not call add_case until they say yes. If they say "edit", take their changes and re-confirm.

Step 5 — Create

On approval, call mcp__testrails__add_case once per case. Collect the returned case ids and report them to the user as a table:

Construct the URL as {TESTRAIL_URL}/index.php?/cases/view/{case_id} if you know the base URL; otherwise just show the id.

Step 6 — Handle failures

If add_case fails partway through, report which cases were created and which failed. Do not retry automatically — ask the user how to proceed (retry failures, roll back, ignore).

Guardrails

• Never invent acceptance criteria the ticket does not state.
• Never create cases without explicit user confirmation.
• Do not call delete_case from this skill under any circumstances.
• If the ticket is a bug (not a story/feature), ask whether the user wants regression cases rather than assuming.