From Dev10x
Analyze a PR for QA needs, check e2e coverage gaps, and create QA sub-tickets when manual testing or new e2e tests are needed. TRIGGER when: PR needs QA analysis for coverage gaps or manual test requirements. DO NOT TRIGGER when: executing QA test cases (use Dev10x:qa-self), or PR has no user-facing changes.
npx claudepluginhub dev10x-guru/dev10x-claude --plugin Dev10xThis skill is limited to using the following tools:
This skill follows `references/task-orchestration.md` patterns.
Creates isolated Git worktrees for feature branches with prioritized directory selection, gitignore safety checks, auto project setup for Node/Python/Rust/Go, and baseline verification.
Executes implementation plans in current session by dispatching fresh subagents per independent task, with two-stage reviews: spec compliance then code quality.
Dispatches parallel agents to independently tackle 2+ tasks like separate test failures or subsystems without shared state or dependencies.
This skill follows references/task-orchestration.md patterns.
Create a task at invocation, mark completed when done:
REQUIRED: Create a task at invocation. Execute at startup:
TaskCreate(subject="Analyze PR for QA needs", activeForm="Analyzing QA scope")Mark completed when done: TaskUpdate(taskId, status="completed")
Analyzes a PR for QA needs by assessing regression risk, checking existing e2e test coverage in app-e2e, identifying gaps, and creating QA sub-tickets in Linear when manual testing or new e2e scenarios are needed.
Use when:
/Dev10x:gh-pr-monitor triggers Phase 2.5 (automatic)Do NOT use for:
Required:
Available context:
/work/example/app-e2e/ — E2E test repositoryAccept input as PR URL, PR number, or auto-detect from current branch:
# Auto-detect from current branch
PR_NUMBER=$(gh pr view --json number -q '.number')
REPO=$(gh repo view --json nameWithOwner -q '.nameWithOwner')
PR_URL=$(gh pr view --json url -q '.url')
BRANCH=$(git branch --show-current)
Parse ticket ID from branch name following username/TICKET-ID/[worktree/]description convention:
TICKET_ID=$(echo "$BRANCH" | grep -oP '[A-Z]+-\d+')
gh pr diff $PR_NUMBER
Identify changed modules by examining file paths in the diff. Map each changed
file to its bounded context (e.g., src/payments/ → payments, src/square_oauth/ → square_oauth).
Use Linear MCP to retrieve:
Store the Linear issue ID — it will be used as parent when creating the QA sub-ticket in Phase 5.1. Look up by the ticket identifier parsed in Step 1.2 (e.g. search for JIRA-5345 or PAY-133).
Before doing any risk assessment, check if QA work already exists:
list_issues to find sub-tickets with "QA" in the title under the parent ticketIf existing QA tickets cover the changed area AND unit tests are comprehensive, set the recommendation to "No new ticket needed" and skip to Phase 4 presentation.
Why? Recommending a new QA ticket without checking existing ones causes redundant work. Unit test coverage at 100% on a guard clause / defensive check (no UI impact) often makes a separate QA ticket unnecessary. Turn 16 of the PAY-58 pr:monitor session.
Classify the change into a risk level based on what was changed.
| Risk Level | Criteria | QA Action |
|---|---|---|
| Low | Config-only, docs, test-only, CI changes | No QA ticket needed |
| Medium | New scope/permission, refactoring with tests, admin changes | QA regression ticket |
| High | Payment flow changes, new features, DB migrations, external API changes | QA regression + e2e coverage ticket |
Evaluate each factor and aggregate:
| Factor | Risk Contribution |
|---|---|
Touches payments/ or money calculation code | +High |
| Modifies external API integrations (Square, Motor, PartsTech) | +High |
| Includes DB migrations | +Medium-High |
| Changes OAuth scopes or authentication | +Medium-High |
| Adds new user-facing feature | +High |
| Refactors existing code with full test coverage | +Medium |
| Modifies admin/config only | +Medium |
| Test-only or config-only changes | Low (stop here) |
| PR has 100% unit test coverage for new code | Reduces risk one level |
Reference the coverage map at references/e2e-coverage-map.md to quickly identify
relevant e2e tests without searching the entire app-e2e repo.
For each changed app-pos module, look up the corresponding e2e feature files, tags, and step definitions in the coverage map.
Search /work/example/app-e2e/features/ for scenarios that exercise the changed code paths:
# Search feature files for relevant keywords
grep -r "keyword" /work/example/app-e2e/features/ --include="*.feature"
# Search step definitions for relevant steps
grep -r "keyword" /work/example/app-e2e/features/steps/ --include="*.py"
# Check page objects for relevant UI interactions
grep -r "keyword" /work/example/app-e2e/tests/pages/ --include="*.py"
Compare what the PR changes against what existing e2e tests cover:
Format and present the QA verdict to the user for approval before creating any tickets.
QA Assessment for PR #<number>
Risk: <Low | Medium | High>
Reason: <1-line summary of why this risk level>
Changed Modules:
- <module 1> (<risk contribution>)
- <module 2> (<risk contribution>)
E2E Coverage:
Existing: <what's already covered>
Gap: <what's missing>
Gap: <what's missing>
Recommendation: <No QA needed | QA regression ticket | QA regression + e2e ticket>
Regression Test Cases:
1. <test case>
2. <test case>
3. <test case>
New E2E Scenarios Needed:
1. <scenario description>
2. <scenario description>
Create QA sub-ticket? (y/n)
Use AskUserQuestion to get approval:
Before creating a new ticket, check if one already exists:
list_issues to find sub-tickets with "QA" in the
title under the parent ticketWhy? PAY-616 session found QA-202 (On Hold) covering the same domain. Creating a duplicate would be noisy and confusing.
Create the QA ticket as a sub-ticket of the PR's Linear ticket. Use the Linear
issue ID retrieved in Step 1.4 as the parent parameter. This links the QA
ticket to the feature ticket in Linear's hierarchy.
Ticket destination routing — choose based on user instruction:
| User says | Destination | How |
|---|---|---|
| (default, no instruction) | Linear QA team | team: "QA" (id: c89229e5-8aeb-4934-8575-aa9f18c22e99) |
| "JIRA team ticket" | Linear JIRA Sync team | team: "JIRA Sync" (id: 0c456d25-e332-4210-992e-65f668a5080e) — auto-syncs to Jira application |
| "JIRA ticket" (no "team") | Jira application directly | Use Jira REST API with credentials from MEMORY.md |
Use Linear MCP create_issue:
Team: <see routing table above>
Title: QA: <PR ticket title>
Parent: <PR's Linear issue ID from Step 1.4>
Description: <structured test plan — see format below>
## Context
PR: <PR URL>
Ticket: <parent ticket ID and title>
Risk: <level>
## Changed Areas
- <module>: <what changed>
## Regression Test Cases
- [ ] <test case 1>
- [ ] <test case 2>
- [ ] <test case 3>
## E2E Coverage Gaps
Existing coverage: <summary>
New scenarios needed:
- [ ] <scenario 1>
- [ ] <scenario 2>
## Related Resources
- <links to relevant admin pages, API docs, Square docs, etc.>
Use AskUserQuestion to ask who to assign:
Output the created ticket ID and URL.
Dev10x:qa-scope
├── Uses: Linear MCP (ticket data, create sub-ticket)
├── Uses: GitHub CLI (PR diff, PR details)
├── Reads: /work/example/app-e2e/ (e2e coverage check)
├── References: references/e2e-coverage-map.md
├── Called by: pr:monitor (Phase 2.5)
└── Standalone: /qa-scope <PR URL or number>
/qa-scope https://github.com/example-org/app-pos/pull/1169
/qa-scope 1169
/qa-scope # auto-detect from current branch
Triggered automatically in Phase 2.5 when CI passes and PR has approval.
QA Assessment for PR #1169
Risk: Medium
Reason: Adds new Square OAuth scope (DEVICES_READ) — changes external API authorization
Changed Modules:
- square_oauth/ (OAuth scope change → Medium-High)
E2E Coverage:
Existing: square.feature covers invoice + payment link flows
Gap: No terminal device pairing/listing tests
Gap: No OAuth re-authorization flow tests
Recommendation: Create QA regression ticket
Regression Test Cases:
1. Verify existing Square OAuth authorization still works
2. Verify legacy token refresh includes new scope
3. Verify terminal checkout flow unaffected
4. Verify new OAuth authorization includes DEVICES_READ
New E2E Scenarios Needed:
1. OAuth re-authorization flow after scope change
2. Terminal device listing in POS settings
Create QA sub-ticket? (y/n)