A QA skill my project team now shares

Teifi Digital · Associate Product Manager co-op · June 2026 · Claude Code

QA on our project meant reading a ticket, planning test cases, running them, then writing it all up in the team's format. I built a Claude skill that does everything around the testing. It became the shared QA skill for our 33-person project team.

Run a ticket through it

Two write-ups for every ticket

Every ticket I QA'd needed a short comment on the ticket for developers, and a longer document with steps and a result for every acceptance criterion. I wrote both by hand, sometimes with help from a tool built for another team's format.

The team had agreed on QA rules in a meeting, like how to treat a UI mismatch and when a ticket should fail. Applying them by hand is where things slipped.

The format drifted, because I copied it from whatever I'd written last.
Failure notes got vague, so developers had to come back and ask.
A ticket could fail over a bug that wasn't in its scope.
On a re-test, it was easy to lose track of what failed the round before.

A template would have fixed the layout and nothing else. A skill could read the ticket, apply the team's rules and keep the history straight.

Run a ticket through it

You give the skill a ticket ID. It pulls the ticket and its comments, plans test cases from the acceptance criteria, and lays them all out. You test and reply with results. Then it drafts both write-ups. This ticket is invented and trimmed to four cases; a real one comes out at 7 to 12.

Checkout: discount codes

Invented example

The code field is labelled "Discount code".
A valid code lowers the total by its amount right away.
A customer can remove an applied code.
An expired code shows "This code has expired" and leaves the total alone.

Your results

Case 1 · Field label

Case 2 · Apply a valid code

Case 3 · Remove a code

Case 4 · Expired code

Your reply 1 fail: label blank, 2 pass, 3 pass, 4 fail: expired code still gives the discount

Ticket comment

Draft, not posted

QA failed. 2 of 4 cases fail.

Case 1, field label: label blank
Case 2, apply a valid code: total only updates after a reload
Case 3, remove a code: remove does nothing on mobile
Case 4, expired code: expired code still gives the discount

@developer, over to you.

QA document

Draft, not posted

Test case 1, field label (AC 1)

Open checkout with one item in the cart
Find the code field under the order summary
Read the field's label

Pass.Fail: label blankWaiting on your result.

Test case 2, apply a valid code (AC 2)

Open checkout with one item in the cart
Enter a valid code and apply it
Confirm the total drops by the code's amount

Pass.Fail: total only updates after a reloadWaiting on your result.

Test case 3, remove a code (AC 3)

Apply a valid code
Select Remove next to it, on desktop and on a phone
Confirm the total goes back up

Pass.Fail: remove does nothing on mobileWaiting on your result.

Test case 4, expired code (AC 4)

Open checkout with one item in the cart
Enter an expired code and apply it
Check for the "expired" message and an unchanged total

Pass.Fail: expired code still gives the discountWaiting on your result.

Failures: cases 1 and 4.

Four rules it doesn't break

A write-up is only useful if people trust it, so these are fixed.

It never makes up a result.: It writes the steps. Every pass or fail comes from me. Clear a result above and the drafts wait for you.
It drafts and never posts.: Nothing goes onto a ticket until I've read it.
It keeps my failure wording.: If I describe a bug a certain way, that's what the developer reads.
Out-of-scope bugs don't fail the ticket.: They get flagged on their own line instead.

From one case at a time to all at once

The first version walked through one test case at a time and waited for my result before moving on. After several rounds of real QA, I changed it to lay out every case at once, so I can reply in shorthand. Real rounds also showed me what wasn't working in the document format, and I changed that too.

First version Re-created

Case 1: apply a valid code. Result?

pass

Case 2: field label. Result?

fail, label blank

Case 3: remove a code. Result?

and so on, one at a time

Now Re-created

Cases 1 to 4 are ready. Reply with your results.

1 pass, 2 fail, label blank

Both drafts are ready to read.

About an hour back per ticket

These are my estimates for one ticket, phase by phase, not measurements. Running the tests takes the same time either way; the skill doesn't touch that part.

70–135minutes around the testing, by hand

10–20minutes with the skill

My estimates, in minutes per ticket
Phase	By hand	With the skill
Read the ticket and its comments	10–15	about 2
Plan cases from the acceptance criteria	20–40	about 3
Run the tests	30–90	30–90
Write the ticket comment	5–10	drafted
Write the QA document	30–60	about 5
Check the format against past write-ups	5–10	not needed

Beyond time, every write-up now has the same shape, and the cases come straight from the acceptance criteria, so none get skipped.

I shared it with the project team, and it became the 33-person team's shared QA skill. I've since built three more: for drafting tickets, client meeting notes and internal notes.

What it can't do

It can't run a test. Every result comes from a person.
It leans toward "partial" where I'd call it a fail, so I still check every verdict.
Thin acceptance criteria give thin test cases. It groups what's there; it doesn't invent coverage.
It never posts, so every run still ends with a copy and paste.

What I'd build next

Post the comment and attach the document once I've approved them.
Carry earlier failures forward on a re-test, without me pasting them in.
Make comparing records across connected systems a standard type of test case.

Hiring for a product role? Send me a note.

Email jeffreykim2005@gmail.com