teamcraft-jcg:qa-support

---
name: teamcraft-jcg:qa-support
description: QA support for the current sprint — surface what's ready to test, prepare a testing approach for a specific issue, or create a bug from findings. Works without codebase access. Use when asking "what's ready to test", "what can I QA", checking sprint testing status, reporting a bug found during testing, or needing a test plan for a specific ticket. Also run when someone says "found a bug", "how should I test this", or wants to file a defect from QA findings.
argument-hint: "(no arguments — you'll choose your goal at the start)"
disable-model-invocation: true
user-invocable: true
allowed-tools:
  - Bash
  - mcp__sooperset-mcp-atlassian__jira_get_all_projects
  - mcp__sooperset-mcp-atlassian__jira_search
  - mcp__sooperset-mcp-atlassian__jira_get_issue
  - mcp__sooperset-mcp-atlassian__jira_create_issue
  - mcp__sooperset-mcp-atlassian__jira_get_agile_boards
  - mcp__sooperset-mcp-atlassian__jira_get_sprints_from_board
  - mcp__sooperset-mcp-atlassian__jira_get_sprint_issues
---

## Goal

Give QA everything they need to validate the sprint's deliverables — without requiring codebase access, developer involvement, or manual status-chasing.

## Hard Constraints

- This skill is Cowork compatible — no local filesystem tools are used at any point.
- Never create a bug issue without presenting the full draft and getting explicit confirmation. No exceptions.
- Never search Jira or Confluence before asking the user if they can point at the project or sprint directly. Search is the fallback when they cannot.
- If an Atlassian MCP tool call fails, report the exact error and stop. Do not improvise alternatives.

## Establish Intent First

Before loading anything, ask the QA analyst what they want to accomplish in this session. Present the three options clearly:

1. **Sprint awareness** — see what's in the current sprint and what's ready to test
2. **Issue test prep** — get full context on a specific issue to prepare a testing approach
3. **Create a bug** — document findings from testing as a Jira bug issue

Follow their choice. Do not load sprint data before they've confirmed their goal.

## Identify the Project

Use `mcp__sooperset-mcp-atlassian__jira_get_all_projects` to see what is visible, surface the results, and ask the QA analyst which Jira project they are working on. Never ask them to supply a project key or ID — surface options and let them confirm. Confirm once identified.

---

## Option 1: Sprint Awareness

**Goal:** Surface what is ready to test, what is still in progress, and what hasn't started — so QA never has to ask a developer for status.

Use `mcp__sooperset-mcp-atlassian__jira_get_agile_boards` to find the project's board, then `mcp__sooperset-mcp-atlassian__jira_get_sprints_from_board` to list sprints. Surface the active sprint and recent sprints and offer them to the QA analyst. Ask them to confirm which sprint.

Fetch the complete issue list using `mcp__sooperset-mcp-atlassian__jira_get_sprint_issues` for the confirmed sprint. Supplement with `mcp__sooperset-mcp-atlassian__jira_search` using JQL for additional detail if needed. For each issue: key, summary, status, issue type, assignee.

For each issue, determine its current status using Jira issue status rather than labels:

- **Ready to test** — Jira status is "Done" or "Closed" and a merged PR exists for this issue
- **In review** — Jira status is "In Review" or similar, and an open non-draft PR exists
- **In progress** — Jira status is "In Progress" and no merged PR yet
- **Not started** — status is "To Do" or "Backlog" with no activity

To look up associated PRs: try `gh pr list --state all --json number,title,state,headRefName` via Bash; if Bash is unavailable, use a GitHub MCP connector if one is configured; if neither is available, skip PR status and note that PR status requires GitHub access — QA can check this in the GitHub UI.

Present a clear breakdown by status. For issues in "ready to test" or "in review," include the PR number, title, and URL. QA should be able to see the full sprint state in a single view.

---

## Option 2: Issue Test Prep

**Goal:** Give QA the full context to prepare a testing approach for a specific issue — acceptance criteria, what was implemented, and edge cases worth considering.

Ask the QA analyst which issue they want to prepare for. They may provide a Jira issue key (e.g. PROJ-42), a title, or a description. Use `mcp__sooperset-mcp-atlassian__jira_get_issue` to fetch it by key.

Read the issue fully: summary, description, acceptance criteria, status, labels, and any comments that contain scope changes or technical clarifications.

If the issue has a linked pull request, try to read it: (1) `gh pr list --head [branch]` and `gh pr view [PR-number] --json title,body,state` via Bash; (2) if Bash is unavailable, use a GitHub MCP connector if configured; (3) if neither is available, note that PR details require GitHub access and proceed without them.

Present a test preparation brief:

**What the issue requires** — restate the acceptance criteria in clear language, calling out any criteria that are ambiguous or that have implicit edge cases.

**What was implemented** — drawn from the PR description and any implementation notes in comments. If no PR is linked yet, note that implementation is not yet reflected.

**Edge cases to consider** — based on the requirements and implementation, what scenarios are worth testing beyond the happy path. Error conditions, boundary values, authorization scenarios, integration dependencies, states that could be tricky. These come from reasoning about the requirements — not from the codebase.

**Testing questions** — any ambiguities in the requirements that QA may want to clarify with the PM or developer before building a test plan.

---

## Option 3: Create a Bug

**Goal:** Create a well-formed bug issue in Jira from the QA analyst's findings. The bug must give a developer everything they need to pick it up cold.

Gather what the QA analyst found. Ask for:
- What they were testing when they found the bug
- What they expected to happen
- What actually happened
- Steps to reproduce (as specific as possible)
- Any debug information, error messages, or log snippets they have

Do not rush to drafting — a bug without clear reproduction steps wastes developer time. Ask follow-up questions until the picture is complete enough to write a bug that can be acted on without calling the QA analyst.

Read `references/example-bug-issue.md` before drafting — it defines the required structure. The draft must include all sections from the reference: Problem Statement, Environment, Steps to Reproduce, Current/Expected Behavior, Debug Information, Root Cause Analysis, Investigation Areas, Potential Approaches, Testing Requirements, Priority, and Labels. Omit a section only if the information genuinely doesn't exist yet (e.g., no debug logs available) — not because it was forgotten. Show the full draft to the QA analyst before creating anything.

Get explicit confirmation. Incorporate any changes they request.

Create the issue using `mcp__sooperset-mcp-atlassian__jira_create_issue` with issue type "Bug". Set appropriate priority if the situation warrants it — pass it via the `additional_fields` parameter (e.g., `{"priority": {"name": "High"}}`).

After the issue is created, report the issue key, summary, and Jira URL.