Automate Code Quality: Write, Fix, and Review Tests with Claude Skills

The Hidden Cost of Manual Code Quality Work

Every engineering team spends a significant slice of each sprint on work that feels necessary but never quite finished: writing tests for new code, fixing the tests that break after a refactor, and reviewing pull requests before they merge. These are not optional activities — they are how teams maintain trust in their codebase. But when done manually, they are slow, inconsistent, and the first thing cut when deadlines tighten.

Claude Skills address this directly. A small set of purpose-built skills — write-tests, fix-tests, review-pr, and review-local-changes — forms a complete code quality automation layer that runs inside Claude Code on your local machine. Together, they handle the most time-consuming parts of the quality loop, letting your team focus on the decisions that actually require human judgment.

This guide walks through how each skill works, how they fit together, and how to integrate them into a development workflow that ships higher-quality code faster.

---

write-tests: Automated Test Generation at Scale

The write-tests skill solves the most common gap in any codebase: code that ships without adequate test coverage because writing tests takes almost as long as writing the feature itself.

When you run /write-tests, the skill begins by discovering your test infrastructure. It reads your existing test configuration files (jest.config.js, pytest.ini, go.mod, or equivalent), identifies the testing patterns already in use, and maps the files you want covered. This discovery phase means the generated tests match the conventions your team has already established — same file naming, same assertion style, same mock patterns.

After discovery, write-tests dispatches parallel sub-agents to write tests for each module or function in scope. Because agents run in parallel, covering a 10-file module takes roughly the same clock time as covering one file. Each agent receives the full context of the function under test, existing tests as style references, and explicit instructions to test edge cases, error paths, and boundary conditions — not just the happy path.

The output is a set of test files you can review, run, and commit. The skill does not invent behavior; it derives tests from the actual function signatures and docstrings in your code. If a function has unclear behavior at the edges, the generated tests expose that ambiguity, which is useful information on its own.

# Example: run write-tests on a specific module
# Inside Claude Code, after installing the skill:
/write-tests src/payments/processor.ts

# The skill will:
# 1. Auto-detect Jest + TypeScript from your project config
# 2. Analyze processor.ts: functions, types, error handling
# 3. Dispatch parallel agents for unit + integration tests
# 4. Write src/payments/processor.test.ts
# 5. Run the test suite to verify all new tests pass

For teams with legacy codebases, write-tests is particularly useful pointed at a specific directory during a coverage improvement sprint. Rather than writing tests by hand for hundreds of functions, you point the skill at a directory, review the output, and iterate.

---

fix-tests: Systematic Repair of Failing Test Suites

Refactors break tests. Dependency upgrades break tests. Even a simple rename can cascade into a dozen failing specs. The fix-tests skill exists for exactly this situation.

The skill begins with auto-discovery: it runs your test suite, collects all failing tests, and groups them by failure type — assertion mismatches, missing mocks, type errors, changed API signatures. Grouping matters because most broken test suites have a small number of root causes; fixing one type of failure often resolves a cluster of tests at once.

Once grouped, fix-tests dispatches parallel agents to repair each failure class. Each agent receives the failing test, the test output, and the relevant source code. The agent's goal is to fix the test without changing the production code — a constraint that forces the repair to reflect the actual new behavior of the system rather than making tests pass by weakening assertions.

After agents complete their repairs, the skill runs the full suite again to verify. If new failures appeared (a rare but possible side effect of the repairs), it runs another repair cycle. The result is a clean test suite that accurately reflects the current state of your code.

# Example: fix all failing tests after a refactor
/fix-tests

# Output summary (example):
# Discovered 23 failing tests across 8 files
# Grouped into 3 failure types:
#   - API signature changes (14 tests)
#   - Missing mock setup (6 tests)
#   - Type assertion errors (3 tests)
# Dispatching 3 parallel repair agents...
# Re-running suite: 0 failures
# All tests passing. Review changes before committing.

One critical design choice: fix-tests refuses to delete tests or weaken assertions to make the suite pass. If a test genuinely cannot be fixed without changing the assertion, the skill flags it for human review rather than silently downgrading coverage. This makes the skill safe to run in CI as a step that proposes repairs for human approval.

---

Browser Testing with playwright-skill

For teams building web applications, test coverage must extend beyond unit tests to actual browser behavior. The playwright-skill adds browser automation directly to the Claude Code workflow.

Playwright Skill auto-detects running development servers, eliminating the most frustrating part of E2E test setup. You describe a user flow — log in, navigate to settings, update a preference, confirm the change persists — and the skill produces a well-structured Playwright test with proper selectors, assertions, and retry logic. It takes screenshots at each step, making failures easy to diagnose.

Where playwright-skill shines is in covering interactions that are difficult to unit test: form validation flows, optimistic UI updates, session expiry handling, and responsive layout transitions. These scenarios require a real browser, and the skill handles the plumbing so you can focus on what to assert.

---

review-local-changes and review-pr: Multi-Agent Code Review

Writing and maintaining tests is only half the quality story. The other half is ensuring that code reaching production has been reviewed thoroughly. Manual code review is valuable but scales poorly with team size; reviewers develop blind spots, and the same categories of bugs appear in post-mortems year after year.

review-local-changes and review-pr bring structured, multi-agent code review into Claude Code.

Both skills operate by dispatching six specialized reviewer agents in parallel, each focusing on a distinct quality dimension:

• Security reviewer: checks for OWASP Top 10 vulnerabilities, secrets in code, injection risks
• Bug reviewer: identifies logic errors, off-by-one conditions, null dereferences
• Quality reviewer: assesses naming, structure, DRY compliance, complexity
• Contract reviewer: verifies API contracts match documentation and callers
• Testing reviewer: identifies coverage gaps and tests that pass for the wrong reasons
• History reviewer: checks for regressions against previously fixed issues

The parallel execution means a full review completes in a fraction of the time a sequential review would take. Findings from all six agents are consolidated into a single report, deduplicated, and ranked by severity.

# Example: review-pr output structure
review:
  pr_number: 142
  summary: "Payment processor refactor — 3 critical, 7 moderate, 12 low findings"
  findings:
    - severity: critical
      agent: security
      file: src/payments/processor.ts
      line: 87
      message: "User-controlled input used directly in SQL query — parameterize this."
    - severity: moderate
      agent: testing
      file: src/payments/processor.test.ts
      line: 34
      message: "Test asserts status code but not response body — partial coverage."
    - severity: low
      agent: quality
      file: src/payments/utils.ts
      line: 12
      message: "Function `buildPayload` duplicates logic from `formatRequest` on line 45."

review-local-changes is designed for use before committing — you run it against your uncommitted diff and catch problems before they ever reach a PR. review-pr integrates with GitHub CLI to post inline comments directly on the pull request, making findings visible to the whole team in the place they already review code.

---

Building a Complete Quality Workflow

These four skills are most effective when used together as a pipeline:

1. After writing new code, run /write-tests to generate initial coverage.
2. After any refactor, run /fix-tests to repair any broken specs.
3. Before committing, run /review-local-changes to catch issues early.
4. Before merging, run /review-pr to post structured inline comments.

This pipeline requires no external CI configuration, no additional services, and no context switching out of your editor. Every step runs inside Claude Code, and every step produces output you can act on immediately.

Teams that adopt this workflow consistently report two improvements: fewer bugs caught in production review, and less time spent per PR on repetitive feedback. The repetitive feedback — "add tests for the error path," "this variable name is unclear," "parameterize that query" — moves to the automated layer, freeing reviewers to focus on architectural decisions and business logic.

For teams already using CI, these skills complement rather than replace existing pipelines. Run them locally for fast feedback, and keep your CI as the final gate.

---

Getting Started

Install any of these skills by downloading the .md file from Claude Skills Hub and placing it in your project's .claude/skills/ directory (or your global ~/.claude/skills/ directory for use across all projects). No additional configuration is required for most projects — the skills discover your test framework and code structure automatically.

Start with write-tests if your coverage is low, fix-tests if you have a backlog of failing tests, or review-local-changes if you want immediate value with zero friction. All four are available now in the Claude Skills Hub catalog.

Code quality is not a checkpoint at the end of development — it is a continuous property of the work. These skills make that property easier to maintain.