Claude Skills for QA: Test Planning and Bug Review Templates

Claude skills for QA are saved prompt instructions that produce test plans, reproduction steps, and bug review checklists to a consistent standard. Call a skill by name in a Claude Project and get the same output shape every time, instead of rebuilding the prompt from memory.

Tools like fenbs store the QA conventions, lessons from past releases, and known-fragile areas alongside the skills. When a connected assistant reads those at the start of a session, the test plans and reviews reflect what your team has actually learned, not generic guidance.

What makes a QA skill worth saving

The best candidates are the prompts you already write repeatedly: risk assessments for new features, reproduction step templates for incoming bugs, and checklists for reviewing a report before it goes to the developer. Each of those has a stable structure that benefits from being written once and tested across real examples.

A skill that forces Claude to ask for missing information is more useful than one that produces a complete-looking output with invented details. A bug report without a reproduction step is a common example: the skill should flag the gap, not fill it with a guess.

A skill for risk-based test planning

Risk-based testing focuses effort on the areas most likely to fail or cause the most harm if they do. This skill takes a change description and returns a test plan organized by risk level.

Write a risk-based test plan for the following change.

Change description: {{description}}
Affected areas: {{components, APIs, or user flows affected}}

Output exactly this structure:

Risk level: Low | Medium | High with one-sentence reason

Test cases (mark each Critical, High, Medium or Low):
  TC-01: [description] | Pass condition: [what a pass looks like]
  TC-02: [description] | Pass condition: [what a pass looks like]
  (continue as needed)

Edge cases to check:
  - [list each]

Regression areas (existing tests to re-run):
  - [list each]

Ready-to-test checklist:
  - [ ] Build deployed to test environment
  - [ ] Test data seeded
  - [add any environment-specific item]

If information is missing to assess risk, write "NEEDS INPUT:" followed by the question.

The "NEEDS INPUT" instruction matters here too. A test plan written with incomplete change information misses the riskiest areas. Flag the gap early rather than discovering it after a round of testing.

A skill for writing clear reproduction steps

Poor reproduction steps are one of the most common reasons a bug bounces between QA and development. This skill takes a rough bug description and produces numbered steps a developer can follow without asking for clarification.

Write clear reproduction steps for the following bug.

Bug summary: {{summary}}
Environment: {{browser, OS, app version, or device}}
What was expected: {{expected behavior}}
What actually happened: {{actual behavior}}

Output exactly this structure:

Preconditions:
  - [any account state, data, or setup required]

Steps to reproduce:
  1. [first action]
  2. [second action]
  (continue until the bug appears)

Actual result: [one sentence]
Expected result: [one sentence]
Frequency: Always | Sometimes | Rarely (delete as applicable)
Screenshot or log attached: Yes | No

If any information above is missing, write "NEEDS INPUT:" followed by the question before writing the steps.

The preconditions section is the one most often skipped in informal reports. A bug that only appears with a specific account state or data condition cannot be reproduced without knowing that condition. The skill makes it explicit.

A skill for reviewing a bug report before filing

Before a bug goes to the developer queue, a short review catches the issues that send it back. This skill checks the report against a quality checklist and returns a pass or fail with reasons.

Review this bug report before filing.

Bug report: {{paste the full report}}

Check each item and mark Pass, Fail, or Not applicable:
- [ ] Summary describes the symptom, not the suspected cause
- [ ] Reproduction steps are numbered and complete
- [ ] Expected and actual results are both stated
- [ ] Environment details are included (version, OS, browser or device)
- [ ] Frequency is stated
- [ ] Screenshot or log is attached where relevant
- [ ] No duplicate of an existing open bug

For each Fail, write one sentence explaining the problem and one sentence on how to fix it.
End with: Ready to file: Yes / No with one-line reason.

How lessons make QA skills better over time

A skill captures a point-in-time view of what good looks like. Lessons let that view improve without rewriting the skill. After a release, record what the test plan missed, what the review checklist did not catch, and what reproduction steps were still unclear. That becomes the baseline for the next round.

Say a release shipped a bug because a test skipped a specific user role. Record the lesson: "Test plans for permission changes must include a case for each role affected." The next test plan skill call can reference that lesson and the assistant adds the role cases without being prompted.

For broader patterns in QA skills, see Claude skills examples and Claude skills for project management. For how the skills architecture fits with other Claude features, see Claude Projects vs Skills vs Artifacts.

When the same category of bug appears in a new area of the codebase, check the existing lessons before writing a new test plan. A lesson about a permissions gap in one module likely applies to similar permission checks elsewhere. The test plan skill will not know this unless the lesson is part of the project context it reads.

Lessons also help new team members. An engineer who reads the project's QA lessons before their first test round has access to the team's accumulated knowledge of past failures without having to experience them firsthand. That shortcut is only available when the lessons were recorded consistently. The QA skills make recording them part of finishing a release rather than an extra step at the end of a cycle when everyone is ready to move on. A team with six months of QA lessons has a review skill that looks nothing like the generic starting template, because it has been shaped by the actual failure patterns of that specific codebase.

How to do this with fenbs

1. Create a free account and add a project for the product or release cycle these skills belong to.
2. Go to Skills and prompts and add each skill: "Risk-based test plan", "Reproduction steps", "Bug review".
3. After each release, add lessons to Lessons learned: what the test plan missed, what caused bugs to bounce.
4. Connect Claude over MCP from Integrations. Ask Claude to read the lessons before writing a new test plan.
5. Before a session ends, save progress notes on which test cases passed, which failed, and what is still open.

fenbs does not connect to your test management tool. It stores the skills and the accumulated lessons that make the next round of testing better. For discovering and sharing skills across projects, see the claude skills marketplace.