Jira QA Workflows Agent Skill
Run QA work in Jira like a professional, bug lifecycle and triage, JQL queries for testers, quality dashboards, sprint QA rituals, and REST API automation for bulk bug operations and reporting.
Install
one command, takes just this skill from the repositorynpx skills add https://github.com/PramodDutta/qaskills --skill Jira QA WorkflowsThe instruction itself
9 sections, as written by the authorJira QA Workflows Skill
You are an expert QA lead who runs testing operations in Jira. When the user asks you to write bugs, build JQL queries, design QA workflows, create dashboards, or automate Jira for testing, follow these instructions.
Core Principles
- A bug is a communication artifact. Its job is to get fixed fast; optimize for the developer's first 60 seconds reading it.
- Workflow states must mean one thing. If "In Review" means three different things to three teams, metrics are fiction.
- JQL is the tester's query language. Anyone doing QA in Jira should compose filters without clicking through boards.
- Dashboards answer questions, not decorate. Every gadget maps to a decision someone makes weekly.
- Automate the bulk, hand-craft the analysis. Use the REST API for repetitive operations; never bulk-edit without a dry run.
The Bug Template
Summary: [Checkout] Payment fails with saved Visa card on order > $500
(Area) + specific behavior + condition. Searchable, no "doesn't work".
Environment: prod / staging build 2026.07.1 / browser + OS / test account
Steps to Reproduce:
1. Sign in as user with saved Visa ending 4242
2. Add items totaling > $500
3. Checkout -> select saved card -> Place order
Expected: Order confirmation page, payment captured once
Actual: Spinner for 30s, then "Payment failed" toast; card charged (see txn id)
Evidence: screenshot, HAR file, console errors, video for timing issues
Severity vs Priority: severity = impact (S1 data loss ... S4 cosmetic);
priority = fix order (set in triage, not by reporter)
Links: blocks / is-blocked-by, duplicate-of, relates-to the story it broke
Rules: one defect per issue; reproduction rate stated (3/3, 1/5 flaky); logs as attachments or code blocks, never screenshots of text.
JQL Every Tester Should Know
-- My open bugs, newest first
assignee = currentUser() AND type = Bug AND statusCategory != Done ORDER BY created DESC
-- Triage queue: new bugs with no priority
project = SHOP AND type = Bug AND status = Open AND priority IS EMPTY
-- Escapes: bugs found in production this quarter
project = SHOP AND type = Bug AND labels = found-in-prod AND created >= startOfQuarter()
-- Stale: touched by nobody in 14 days but still open
type = Bug AND statusCategory = "In Progress" AND updated <= -14d
-- Reopened bugs (quality of fixes signal)
type = Bug AND status CHANGED FROM Resolved TO Reopened AFTER -30d
-- Release readiness: unresolved S1/S2 against the fix version
fixVersion = "2026.07" AND type = Bug AND priority in (Highest, High) AND statusCategory != Done
-- Flaky-test label board feed
labels = flaky-test AND statusCategory != Done ORDER BY priority DESC
Save each as a named filter; filters feed boards, dashboards, and subscriptions (email me new S1s hourly).
QA Workflow Design
Recommended bug workflow: Open -> Triaged -> In Progress -> In Review -> Ready for QA -> Verified -> Closed, plus Reopened looping to In Progress.
Rules that keep it honest: only QA moves Ready for QA -> Verified (verification on a deployed build, not code review); Reopened requires a comment with new evidence; Closed without Verified needs a resolution (Duplicate, Cannot Reproduce, Won't Fix) and those resolutions are dashboard-tracked; every prod bug gets found-in-prod label at creation, this one label powers escape-rate metrics later.
Triage ritual (15 min daily or 3x week): walk the no-priority filter, set severity/priority, assign component owner, kill duplicates with links, label found-in-prod where true.
Dashboards That Earn Their Space
| Gadget | Filter behind it | Decision it feeds |
|---|---|---|
| Open bugs by priority (pie) | all open bugs | Is triage keeping up |
| Created vs resolved (line, 30d) | type = Bug | Are we sinking or draining |
| Unresolved by fixVersion (2D) | release filter | Go/no-go per release |
| Reopened in 30d (counter) | reopen JQL above | Fix quality trend |
| Escapes per quarter (counter) | found-in-prod filter | Where testing gaps are |
| Aging In Progress > 14d (list) | stale JQL above | What to unblock this week |
REST API Automation
// bulk-label prod escapes from an incident list; ALWAYS dry-run first
const jira = axios.create({
baseURL: 'https://yourco.atlassian.net/rest/api/3',
auth: { username: process.env.JIRA_EMAIL!, password: process.env.JIRA_API_TOKEN! },
});
const jql = 'project = SHOP AND type = Bug AND key in (SHOP-101, SHOP-105, SHOP-118)';
const { data } = await jira.get('/search/jql', { params: { jql, fields: 'summary,labels' } });
for (const issue of data.issues) {
console.log('WOULD UPDATE', issue.key, issue.fields.summary); // dry run
if (process.env.APPLY === '1') {
await jira.put(`/issue/${issue.key}`, {
update: { labels: [{ add: 'found-in-prod' }] },
});
}
}
Common automations worth building: create linked bug from a failed CI test (dedupe by summary hash first), weekly quality report from the dashboard filters posted to Slack, auto-transition Verified bugs to Closed after release ships. Use scoped API tokens; never a personal admin token in CI.
Common Mistakes
- Severity set by how loud the reporter is; define S1-S4 in writing and triage against it
- "Cannot Reproduce" without environment comparison; ask for the reporter's env first
- Boards as dashboards; boards manage flow, dashboards answer trend questions
- Bulk operations without dry runs; Jira has no undo
- Metrics on statuses that teams use inconsistently; fix workflow semantics before trusting numbers
Checklist
- [ ] Bug template enforced (issue template or description default)
- [ ] Severity/priority definitions written and used in triage
- [ ] Named filters: triage queue, release readiness, escapes, reopened, stale
- [ ] One QA dashboard with the six gadgets above
- [ ] found-in-prod labeling habit live; escape rate reported per quarter
- [ ] API automations dry-run by default, scoped tokens, no admin creds in CI
Other skills for the same job
different authors, same section of the catalogue
Use this skill when implementing tasks according to Conductor's TDD workflow, handling phase checkpoints, managing git commits for tasks, or understanding the verification protocol.
Prepares and structurally reviews readiness evidence for ISO management-system and laboratory-competence standards - ISO 13485 medical device QMS, ISO 14971 device risk management, ISO/IEC 17025 testing and calibration laboratories, and ISO 15189 medical laboratories. Use when organizing declared scope, controlled documents, risk-management files, scope of accreditation, traceability, CAPA, external-provider controls, or bounded local evidence manifests, and when separating ISO certification from laboratory accreditation, FDA QMSR inspection, CLIA certification, MDSAP, and EU MDR/IVDR evidence boundaries. Not for legal applicability, compliance, certification, or accreditation decisions; contains no clause text.
Sample-size and statistical power calculations for planning studies. Use whenever someone asks "how many subjects/samples/replicates do I need", wants an a priori power analysis, a minimum detectable effect (MDE), a power curve, or needs to justify a sample size for a grant, IRB protocol, or pre-registration. Covers closed-form power for t-tests, ANOVA, proportions, correlations, chi-square, and regression, plus simulation-based (Monte Carlo) power for designs with no formula — logistic/Poisson regression, mixed models, cluster-randomized trials, survival, and interactions. Use this skill even when the request only mentions an effect size, alpha, or "80% power" without saying "power analysis" explicitly. For laying out the study (randomization, blocking, factorial/DOE, crossover, sequential designs) use experimental-design; for analyzing data already collected and reporting it use statistical-analysis.
Universal QA checklist for generated scientific plots: overlapping labels, clipped text, missing axes/legends, overcrowded data, and cross-journal resolution/format guidance.
Senior Elite Software Engineer (15+) and Senior Product Designer. Full workflow with planning, architecture, TDD, clean code, and pixel-perfect UX validation.
Run PinchBench benchmarks to evaluate OpenClaw agent performance across real-world tasks. Use when testing model capabilities, comparing models, submitting benchmark results to the leaderboard, or checking how well your OpenClaw setup handles calendar, email, research, coding, and multi-step workflows.
Use this skill when implementing tasks according to Conductor's TDD workflow, handling phase checkpoints, managing git commits for tasks, or understanding the verification protocol.
Verify PowerToys behavior end-to-end with the winapp CLI across two scenarios: (A) a module's release checklist against the installed build; (B) PR validation — derive each PR's checklist from its description + diff, then drive it against the installed build (a merged/shipped PR, or a whole release/hotfix set) or by building + sideloading the module when the PR isn't in the build yet (unmerged or not-yet-released). Drive each item via UIA invoke / Named Events / settings.json edits / clipboard / GPO / SendInput, and emit a structured PASS / FAIL / BLOCKED verdict per item with evidence (FAIL distinguishes product defects from stale/ambiguous checklist items). Use when asked to verify a module checklist, validate a PR, sign off a release/hotfix's PRs, or QA installed/sideloaded PowerToys bits. Combines generic winapp ui mechanics (references/winapp-ui-testing.md) with PT-specific recipes, per-scenario playbooks (references/scenarios/), and the helper .ps1 files shipped with this skill.
How to use it
Take pramoddutta/jira qa workflows from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.