QA Bug Report Only (QA-Only)

Core Concepts

Difference Between QA-Only and QA

The QA-Only skill and the regular QA skill (/qa) have fundamentally different purposes.

	QA-Only	QA
Purpose	Bug discovery + report only	Bug discovery + fix + verification
Code changes	None	Yes
Output	Structured report	Fixed code + verification results
When to use	Assessing current state, generating reports	When immediate fixes are needed

QA-Only plays the role of "collecting evidence like a detective". Because it does not touch the code, it is especially suitable for the following situations:

• When you don't have permission to modify the code (reviewing someone else's code)
• When you need a baseline document before making changes (obtaining a list of current bugs before refactoring)
• Stakeholder reporting (reporting current status to professors, PM, or team leader)

Report Components

The report generated by the QA-Only skill includes the following items:

• Health Score: Ratio of pages/features operating normally out of all (e.g., 78/100)
• List of discovered bugs: Classified by severity (Critical/High/Medium/Low)
• Screenshots: Visual evidence for each bug, with annotations on problem areas
• Reproduction Steps: Step-by-step procedure to reproduce the bug
• Impact scope: Which users and which flows are affected

Systematic Testing Methodology

QA-Only does not simply click through a few pages — it aims for systematic coverage.

1. Traverse all page routes
2. Execute core user flows (happy path)
3. Test edge cases and error paths
4. Check responsive layout (mobile/tablet/desktop)
5. Check basic accessibility items

One-Line Summary

A report-only QA skill that systematically tests web applications and generates structured reports containing health score, screenshots, and reproduction steps, but never modifies code.

Getting Started

/qa-only

SKILL.md file location: ~/.claude/skills/qa-only/SKILL.md

To customize, copy the SKILL.md content and modify it.

Practical Example

Situation: You have deployed a Next.js 15 + TypeScript "Student Club Notice Board" project to Vercel. There are 3 days until the final professor presentation, and the team lead asked "create a full bug status report and share it at the team meeting." There's no time to fix things right now — the priority is understanding what the issues are.

Requesting a Full Site QA Report

> Use qa-only skill to test all of https://my-club-board.vercel.app
  and create a structured bug report.
  Do not modify any code, just write the report.

Example of Generated Report

# Student Club Notice Board QA Report
Date: 2026-04-12
Test environment: Vercel deployment (https://my-club-board.vercel.app)
Health Score: 71/100

---

## Summary

| Severity | Count |
|-------|------|
| Critical | 1 |
| High | 3 |
| Medium | 4 |
| Low | 2 |

---

## Critical Bugs

### BUG-001: Unauthenticated users can create notices
**Severity**: Critical
**Impact**: All unauthenticated users
**Reproduction Steps**:
1. Access `/notices/new` directly while logged out
2. Enter title and content, click "Register Notice"
3. → Notice is successfully registered (without authentication)

**Screenshot**: [BUG-001-screenshot.png]
**Expected behavior**: Should redirect to the login page

GitHub Issues Integration

> Format the Critical/High bugs from the qa-only report
  as individual GitHub Issues.
  Add "bug" label and severity labels (critical/high/medium/low).

// Can also be auto-created via GitHub Issues API
const issues = qaReport.bugs
  .filter(bug => bug.severity === "Critical" || bug.severity === "High")
  .map(bug => ({
    title: `[${bug.severity}] ${bug.title}`,
    body: `## Reproduction Steps\n${bug.reproSteps}\n\n## Expected Behavior\n${bug.expected}`,
    labels: ["bug", bug.severity.toLowerCase()],
  }));

Learning Points / Common Pitfalls

• Uphold the principle of not modifying code: The core value of the QA-Only skill is "objective reports without fixes". When you discover a bug and feel the urge to say "wait, fix this too", the skill's intent gets blurred. If fixes are needed, use the /qa skill in a separate session or handle them manually.
• Establish a baseline before presentations: Run QA-Only 1-2 weeks before a team project presentation and record the health score. You can then track how the health score improves as you fix bugs. Showing the improvement process as "initial 71 → current 94" during the presentation makes a strong impression.
• Difference from Browse skill: The Browse skill is a tool for quickly verifying a single scenario. QA-Only specializes in systematically scanning the entire site and generating a structured report. They differ in scale and purpose.
• Common pitfall — Environment dependency: QA-Only tests against an actual deployed URL. Behavior may differ between local localhost:3000 and the Vercel deployment environment (environment variables, CORS configuration, Edge Runtime differences, etc.). Clearly specify which environment is the baseline.
• Next.js 15 perspective: Server Action responses, revalidatePath behavior, and loading states at Suspense boundaries are difficult to verify with unit tests. Running QA-Only against the actual deployed environment can reveal these integration issues.

Related Resources

• qa — QA skill that discovers bugs + auto-fixes them
• browse — Single-scenario headless browser testing
• setup-browser-cookies — Authentication cookie setup

---

Field	Value
Source URL	https://docs.anthropic.com/en/docs/claude-code/skills
Author/Source	Anthropic (gstack ecosystem)
License	Commentary MIT, original for reference only
Translation Date	2026-04-13