/test

name: test
description: "Generate tests for completed phase code. Detects test framework and targets key files."
allowed-tools: Read, Write, Bash, Glob, Grep, Task, AskUserQuestion
argument-hint: "<phase-number>"

**STOP — DO NOT READ THIS FILE. You are already reading it. This prompt was injected into your context by Claude Code's plugin system. Using the Read tool on this SKILL.md file wastes ~7,600 tokens. Begin executing Step 1 immediately.**

/pbr:test — Post-Phase Test Generation

You are the orchestrator for `/pbr:test`. This skill generates tests for code that was built WITHOUT TDD mode. It targets key files from completed phases and creates meaningful test coverage.

Context Budget

Reference: `skills/shared/context-budget.md` for the universal orchestrator rules. Reference: `skills/shared/agent-type-resolution.md` for agent type fallback when spawning Task() subagents.

Additionally for this skill:

• **Delegate** all test writing to executor subagents — never write test code in the main context
• Read only SUMMARY.md frontmatter for `key_files` lists — do not read full summaries

Step 0 — Immediate Output

**Before ANY tool calls**, display this banner:

╔══════════════════════════════════════════════════════════════╗
║  PLAN-BUILD-RUN ► GENERATING TESTS FOR PHASE {N}             ║
╚══════════════════════════════════════════════════════════════╝

Where `{N}` is the phase number from `$ARGUMENTS`.

**CRITICAL — DO NOT SKIP: Set active skill.** Write `.planning/.active-skill` with content `test`.

Then proceed to Step 1.

Prerequisites

• `.planning/config.json` exists
• Phase has been built: SUMMARY.md files exist in `.planning/phases/{NN}-{slug}/`
• If no SUMMARY.md files exist in the phase directory, display error and exit. Do not proceed without build output.
• Phase should NOT already have TDD coverage (check if `features.tdd_mode` is false in config — if TDD mode is enabled, warn user that tests should already exist and ask to proceed anyway)

---

Argument Parsing

Parse `$ARGUMENTS` according to `skills/shared/phase-argument-parsing.md`.

| Argument | Meaning | |----------|---------| | `3` | Generate tests for phase 3 | | (no number) | Use current phase from STATE.md |

---

Step 1 — Gather Context

**CRITICAL: Run init command to load project state efficiently.**

pbr-tools" init execute-phase {phase_number}

This returns STATE.md snapshot, phase plans, ROADMAP excerpt, and config — all in one call.

The init command returns `files_to_read` context. Ensure SUMMARY.md files are read before spawning test agents.

Step 2 — Detect Test Framework

Scan the project root for test framework indicators:

1. Check `package.json` for `jest`, `vitest`, `mocha`, `ava` in devDependencies 2. Check for `pytest.ini`, `pyproject.toml` (with `[tool.pytest]`), `setup.cfg` (with `[tool:pytest]`) 3. Check for `jest.config.*`, `vitest.config.*`, `.mocharc.*` 4. Check for existing test directories: `tests/`, `test/`, `__tests__/`, `spec/` 5. Check for existing test file patterns: `*.test.*`, `*.spec.*`, `test_*.py`

If no test framework is detected, ask the user:

Use AskUserQuestion: question: "No test framework detected. Which should I use?" header: "Framework" options:

• label: "Jest" description: "JavaScript/TypeScript testing (most common)"
• label: "Vitest" description: "Vite-native testing (faster, ESM-friendly)"
• label: "pytest" description: "Python testing framework"

multiSelect: false

Step 3 — Collect Target Files

Read SUMMARY.md frontmatter from each plan in the phase to extract `key_files`:

pbr-tools" frontmatter .planning/phases/{NN}-{slug}/SUMMARY.md

Collect all `key_files` across all plans in the phase. Filter to only source files (exclude config, docs, assets). Group by:

• **High priority**: Files with business logic, API endpoints, data models
• **Medium priority**: Utility functions, helpers, middleware
• **Low priority**: Config, types-only files, constants

Present the file list to the user:

Use AskUserQuestion: question: "Found {N} source files from phase {P}. Generate tests for which?" header: "Scope" options:

• label: "High priority only" description: "{X} files — business logic, APIs, models"
• label: "High + Medium" description: "{Y} files — adds utilities and helpers"
• label: "All files" description: "{Z} files — comprehensive coverage"

multiSelect: false

Step 4 — Generate Test Plans

For each target file, create a lightweight test plan (NOT a full PBR PLAN.md — just a task list):

File: src/auth/login.js
Tests to generate:
  - Happy path: valid credentials return token
  - Error: invalid password returns 401
  - Error: missing email returns 400
  - Edge: expired session handling
Framework: jest
Output: tests/auth/login.test.js

Step 5 — Spawn Executor Agents

**CRITICAL: Delegate ALL test writing to subagents. Do NOT write test code in the main context.**

For each target file (or batch of related files), spawn an executor agent:

Spawn subagent_type: "pbr:executor"

Task: Generate tests for the following file(s):

<files_to_test>
{file_path}: {brief description from SUMMARY}
</files_to_test>

<test_framework>
{detected framework name and version}
Existing test directory: {path}
Test file naming: {pattern, e.g., *.test.js}
</test_framework>

<test_plan>
{test plan from Step 4}
</test_plan>

Instructions:
1. Read each source file to understand the implementation
2. Write test files following the project's existing test patterns
3. Each test file should cover: happy path, error cases, edge cases
4. Use the project's existing mocking patterns if any exist
5. Run the tests to verify they pass: {test command}
6. Commit with format: test({phase}-tests): add tests for {file}

Spawn up to `parallelization.max_concurrent_agents` agents in parallel for independent files.

Step 6 — Verify and Report

After all agents