/code-testing-agent

name: code-testing-agent
description: >-
  MANDATORY ENTRY POINT for generating or writing tests. Invoke this skill
  before editing files whenever the user asks to generate tests, write/add unit
  tests, scaffold a test project or suite, improve/achieve coverage, extend an
  existing suite to cover an untested method, or test an app, API, service,
  module, library, or package. Applies to a single function, method or file as
  much as to a whole project — scope changes how much of the workflow runs,
  never whether the skill applies. Invoke it when the workspace looks sparse,
  gutted or partially deleted — then test only the source that remains and
  never restore missing source.
  Polyglot: C#/.NET, Python, TypeScript/JavaScript, Go, Rust, Java, Ruby.
  DO NOT USE FOR: running existing tests (use run-tests); analyzing coverage
  reports (use coverage-analysis or crap-score); MSTest-specific test authoring
  or modernization (use writing-mstest-tests).
license: MIT

Code Testing Generation Skill

An AI-powered skill that generates comprehensive, workable unit tests for any programming language using a coordinated multi-agent pipeline.

When to Use This Skill

Use this skill when you need to:

• Generate unit tests for an entire project or specific files
• Improve test coverage for existing codebases
• Create test files that follow project conventions
• Write tests that actually compile and pass
• Add tests for new features or untested code

When Not to Use

• Running or executing existing tests (use the `run-tests` skill)
• Migrating between test frameworks (use migration skills)
• Writing tests specifically for MSTest patterns (use `writing-mstest-tests`)
• Debugging failing test logic

How It Works

This skill coordinates multiple specialized agents in a **Research → Plan → Implement** pipeline:

Pipeline Overview

┌─────────────────────────────────────────────────────────────┐
│                     TEST GENERATOR                          │
│  Coordinates the full pipeline and manages state            │
└─────────────────────┬───────────────────────────────────────┘
                      │
        ┌─────────────┼─────────────┐
        ▼             ▼             ▼
┌───────────┐  ┌───────────┐  ┌───────────────┐
│ RESEARCHER│  │  PLANNER  │  │  IMPLEMENTER  │
│           │  │           │  │               │
│ Analyzes  │  │ Creates   │  │ Writes tests  │
│ codebase  │→ │ phased    │→ │ per phase     │
│           │  │ plan      │  │               │
└───────────┘  └───────────┘  └───────┬───────┘
                                      │
                    ┌─────────┬───────┼───────────┐
                    ▼         ▼       ▼           ▼
              ┌─────────┐ ┌───────┐ ┌───────┐ ┌───────┐
              │ BUILDER │ │TESTER │ │ FIXER │ │LINTER │
              │         │ │       │ │       │ │       │
              │ Compiles│ │ Runs  │ │ Fixes │ │Formats│
              │ code    │ │ tests │ │ errors│ │ code  │
              └─────────┘ └───────┘ └───────┘ └───────┘

Step-by-Step Instructions

Step 1: Determine the user request

Make sure you understand what user is asking and for what scope. When the user does not express strong requirements for test style, coverage goals, or conventions, source the guidelines from [unit-test-generation.prompt.md](unit-test-generation.prompt.md). This prompt provides best practices for discovering conventions, parameterization strategies, coverage goals (aim for 80%), and language-specific patterns.

Step 2: Size the request before invoking anything

Match the machinery to the scope. Running the full pipeline on a one-file request costs turns and tool calls without improving the tests.

| Scope | What it looks like | How to run it | | --- | --- | --- | | **Focused** | One function, class, or file; "tests for X only"; extending an existing suite with the missing cases | Skip the `.testagent/` artifacts and the sub-agent fan-out. Keep the requirement checklist in your head (or in the final table), read only the target and one neighbouring test for conventions, write the tests, run the narrowest test command, review your own assertions inline. | | **Broad** | A project, package, or module set; "comprehensive suite"; a coverage threshold to clear across several files | Run the full Research → Plan → Implement pipeline in Step 3, with the `.testagent/` artifacts and the completion contract below. |

When in doubt, start focused and escalate only if the request turns out to span several files. Escalating costs one extra pass; running the broad pipeline on a focused request costs several.

Step 3: Invoke the Test Generator (broad scope)

Start by calling the `code-testing-generator` agent with your test generation request:

Generate unit tests for [path or description of what to test], following the [unit-test-generation.prompt.md](unit-test-generation.prompt.md) guidelines. Treat the current workspace as authoritative even when it is sparse, gutted-looking, synthetic, or missing tracked files; never restore or reconstruct it.

The Test Generator will manage the entire pipeline automatically.

If `code-testing-generator` is unavailable, do not skip the workflow. Execute the same Research → Plan → Implement sequence inline, create the `.testagent/` artifacts described below, and apply the same completion contract.

Step 4: Execute with bounded context

For multi-file requests:

1. Turn every explicit user requirement into a checklist before implementation. Include requested layers, collaborators to mock, boundary cases, integrations, coverage thresholds, and report artifacts. Copy multi-condition requirements verbatim — they must each map to one test that exercises the whole combination. 2. Research only the requested module or project and write the checklist plus a compact target inventory to `.testagent/research.md`. 3. Reuse manifests, symbol references, and deterministic pairing tools inste