teamcraft-glgd:qa-support

What this skill does

## 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 GitLab or Google Drive before asking the user if they can point at the project or milestone directly. Search is the fallback when they cannot.
- If a Drive file operation fails with a path error, read the error message to identify a valid accessible host path and retry with it.
- If a GitLab tool call fails, report the exact error and stop. Do not improvise alternatives.

## Resolve Drive Account

Call `mcp__google-drive__list_accounts` before any other Drive operation:
- **No accounts** — Drive is not configured for this user. Tell them and skip Drive operations.
- **One account** — Use it. Pass `account_email` explicitly on every Drive tool call this session.
- **Multiple accounts** — Present the list, ask which account to use for this session. Pass that `account_email` on every Drive tool call.

If any Drive call returns a permission error, surface it: the active account may not have access to that file or folder. Offer to try another account if one is available.

## 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 GitLab bug issue

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

## Identify the Project

Use `mcp__gitlab__list_projects` to see what is visible, surface the results, and ask the QA analyst which project they are working on. Never ask them to supply a namespace or project ID. 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.

Ask the QA analyst if they can identify the active milestone (sprint) by name or ID. If they can, fetch it directly. If not, use `mcp__gitlab__list_milestones` to find active milestones and confirm which one they want.

Fetch all issues in the milestone using `mcp__gitlab__list_issues`. For each issue, determine its current status by reading its labels and any linked merge requests:

- **Ready to test** — implementation is merged to the default branch (MR merged, issue closed by merge or label indicates merged)
- **In review** — an open, non-draft MR exists for this issue
- **In progress** — issue has "In Progress" label or similar, no merged MR yet
- **Not started** — no activity beyond issue creation

Present a clear breakdown by status. For issues in "ready to test" or "in review," include the MR 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 an IID, a title, or a description. Use `mcp__gitlab__get_issue` to fetch it.

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

If the issue has a linked merge request, use `mcp__gitlab__get_merge_request` to read the MR description — this often contains the implementation summary that tells QA exactly what was built.

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 MR description and any implementation notes in comments. If no MR 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 GitLab 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. Only then create the issue using `mcp__gitlab__create_issue`.

Apply appropriate labels — at minimum `bug`. If the project's labels (from `mcp__gitlab__list_labels`) include component or priority labels that fit, apply them. Ask the QA analyst if they are uncertain.

After the issue is created, report the IID, title, and GitLab URL.