How long does the integration take?

Change one base URL in an OpenAI-compatible client, or install the Python or TypeScript SDK; the quickstart routes a first request in a few minutes.

Will this lock us into another vendor?

No. The router is Apache-2.0 open source, your provider keys stay yours, and the API is OpenAI-compatible, so leaving is a change of base URL.

What happens when a provider fails?

The router falls back to the next model your policy allows and records the fallback in the trace, so an outage costs a retry, not an incident.

create-missing-tests - Prompt

Name: create-missing-tests
Author: sarthchawla

Prompt file imported from sarthchawla/InZone (.claude/commands/create-missing-tests.md). Copyright stays with the author.

Create Missing Tests for Branch Changes

Analyze all changes on the current branch compared to master, then create missing tests using a team of parallel agents.

Context

Repository: InZone monorepo
Current branch: {{ git.currentBranch }}
Base branch: master

Project Structure

InZone/
├── apps/
│   ├── web/                              # React frontend (Vite + Vitest + RTL + Playwright-BDD)
│   │   ├── src/
│   │   │   ├── components/               # UI components
│   │   │   ├── hooks/                    # Custom hooks
│   │   │   ├── api/                      # API client
│   │   │   ├── lib/                      # Utilities
│   │   │   ├── pages/                    # Page components
│   │   │   └── architecture/             # Architecture tests (*.arch.test.ts)
│   │   └── tests/bdd/
│   │       ├── features/                 # Playwright-BDD feature files
│   │       └── steps/                    # Step definitions
│   └── api/                              # Backend API (Vitest + Cucumber.js BDD)
│       ├── src/
│       │   ├── routes/                   # Route handlers
│       │   ├── services/                 # Business logic
│       │   ├── middleware/               # Middleware
│       │   ├── validators/               # Input validators
│       │   └── architecture/             # Architecture tests (*.arch.test.ts)
│       └── tests/bdd/
│           ├── features/                 # Cucumber-BDD feature files
│           └── step-definitions/         # Step definitions
└── packages/
    └── shared/                           # Shared types/utilities
        └── src/
            └── architecture/             # Architecture tests

Step 1: Analyze Branch Changes

Run the following to identify all changed/added files:

git diff master...HEAD --name-only --diff-filter=ACMR

Categorize the changed files into these buckets:

web-source: Files in apps/web/src/ that are NOT test files (*.test.ts, *.test.tsx, *.arch.test.ts)
api-source: Files in apps/api/src/ that are NOT test files
web-features: New routes, pages, or components with user flows (candidates for BDD)
api-features: New or changed API endpoints, services with business logic (candidates for BDD)
structural: New directories, new modules, new patterns (candidates for arch tests)
shared: Files in packages/shared/

Skip files that are already test files, config files, or documentation.

Step 2: Create Team and Tasks

Create a team called test-creators.
Create one task per agent type, but only for categories that have relevant changes. Each task description should include:
- The list of changed source files relevant to that agent
- The full diff for those files (or instructions to read the diff)
- What the agent should do (detailed below)

Task Descriptions

Task: `web-unit-tests`

Condition: Only create if there are changed files in apps/web/src/

Analyze and create missing unit tests for changed frontend files.

Changed files:
<list the web-source files here>

Instructions:
1. For each changed source file, check if a corresponding test file exists:
   - Component files (*.tsx) -> *.test.tsx
   - Hook files (*.ts in hooks/) -> *.test.ts
   - Utility files (*.ts) -> *.test.ts
   - Files in architecture/ are excluded (handled by arch-tests agent)
2. Read the diff for each file: git diff master...HEAD -- <file>
3. Read existing test files nearby to understand patterns and conventions
4. If test file is MISSING: create it following existing patterns in the codebase
5. If test file EXISTS but doesn't cover the changes: add new test cases
6. Run tests to verify they pass: cd apps/web && pnpm vitest run --coverage <test-file>
7. Ensure coverage meets 80% threshold for the changed files
8. Report what was created/updated

Rules:
- Use pnpm (never npm/npx/yarn)
- NEVER lower coverage thresholds — add more tests instead
- Use fireEvent instead of userEvent.type() for inputs with special chars, long strings, or whitespace
- Follow existing test patterns in the codebase
- Do not commit any changes

Task: `api-unit-tests`

Condition: Only create if there are changed files in apps/api/src/

Analyze and create missing unit tests for changed backend files.

Changed files:
<list the api-source files here>

Instructions:
1. For each changed source file, check if a corresponding .test.ts file exists
   - Files in architecture/ are excluded (handled by arch-tests agent)
2. Read the diff for each file: git diff master...HEAD -- <file>
3. Read existing test files nearby to understand patterns and conventions
4. If test file is MISSING: create it following existing patterns
5. If test file EXISTS but doesn't cover the changes: add new test cases
6. Run tests to verify they pass: cd apps/api && pnpm vitest run --coverage <test-file>
7. Ensure coverage meets 80% threshold for the changed files
8. Report what was created/updated

Rules:
- Use pnpm (never npm/npx/yarn)
- NEVER lower coverage thresholds — add more tests instead
- Follow existing test patterns in the codebase
- Do not commit any changes

Task: `web-bdd-tests`

Condition: Only create if there are new routes, pages, or components with user-facing flows

Analyze and create missing BDD feature files for new frontend functionality.

Changed files with user flows:
<list the web-features files here>

Instructions:
1. Read the changed source files to understand the new user-facing functionality
2. Check existing BDD features in apps/web/tests/bdd/features/ for coverage
3. Read existing feature files and step definitions to understand patterns
4. If a new user flow is NOT covered by any existing feature:
   a. Create a new .feature file in apps/web/tests/bdd/features/
   b. Create corresponding step definitions in apps/web/tests/bdd/steps/
   c. Tag new scenarios with @wip
5. If an existing feature partially covers the flow: add new scenarios (tagged @wip)
6. Do NOT run BDD tests (they require dev servers) — just create the files
7. Report what was created/updated

Rules:
- Use pnpm (never npm/npx/yarn)
- Write scenarios in business language, not technical language
- Follow existing Playwright-BDD patterns in the codebase
- Tag all new features/scenarios as @wip
- Do not commit any changes

Task: `api-bdd-tests`

Condition: Only create if there are new/changed API endpoints or business logic

Analyze and create missing BDD feature files for new API functionality.

Changed files with API logic:
<list the api-features files here>

Instructions:
1. Read the changed source files to understand the new API functionality
2. Check existing BDD features in apps/api/tests/bdd/features/ for coverage
3. Read existing feature files and step definitions to understand patterns
4. If new API behavior is NOT covered by any existing feature:
   a. Create a new .feature file in apps/api/tests/bdd/features/
   b. Create corresponding step definitions in apps/api/tests/bdd/step-definitions/
   c. Tag new scenarios with @wip
5. If an existing feature partially covers the behavior: add new scenarios (tagged @wip)
6. Do NOT run BDD tests (they require dev servers + DB) — just create the files
7. Report what was created/updated

Rules:
- Use pnpm (never npm/npx/yarn)
- Write scenarios in business language, not technical language
- Follow existing Cucumber.js patterns in the codebase
- Tag all new features/scenarios as @wip
- Do not commit any changes

Task: `arch-tests`

Condition: Only create if there are structural changes (new modules, directories, patterns)

Analyze and update architecture tests for structural changes.

Structural changes:
<list the structural changes here>

Instructions:
1. Read the changed/added files to understand new structure
2. Check existing architecture tests:
   - apps/web/src/architecture/*.arch.test.ts
   - apps/api/src/architecture/*.arch.test.ts
   - packages/shared/src/architecture/*.arch.test.ts (if applicable)
3. Read existing arch test files to understand patterns and conventions
4. If new modules/directories/patterns are not covered by existing arch rules:
   a. Add new rules to existing arch test files
   b. Or create new arch test files if needed
5. Run arch tests to verify: cd <app-dir> && pnpm run test:arch
6. Report what was created/updated

Rules:
- Use pnpm (never npm/npx/yarn)
- Follow existing architecture test patterns
- Only add rules for genuinely new structural patterns
- Do not commit any changes

Step 3: Spawn Agents

Spawn agents using the Task tool with subagent_type: "general-purpose" and team_name: "test-creators".

Batch 1 (up to 4 agents): Unit test and arch test agents

Spawn these in parallel:

web-unit-tests agent (if task exists)
api-unit-tests agent (if task exists)
arch-tests agent (if task exists)

Batch 2: BDD agents (after Batch 1 completes)

Spawn these in parallel:

web-bdd-tests agent (if task exists)
api-bdd-tests agent (if task exists)

BDD agents are spawned last because they depend on understanding what the unit test agents may have already created, and they are creating feature files that describe higher-level behavior.

Step 4: Monitor and Collect Results

Wait for each batch to complete before starting the next.
Use TaskList and TaskGet to monitor progress.
Collect results from all agents.

Step 5: Present Final Summary

Present a summary table of all created/updated test files:

## Test Creation Summary — `<branch>` vs `master`

### Created/Updated Test Files

| File | Type | Action | Status |
|------|------|--------|--------|
| apps/web/src/components/Foo.test.tsx | Unit | Created | PASS |
| apps/api/src/routes/bar.test.ts | Unit | Updated | PASS |
| apps/web/tests/bdd/features/login.feature | BDD | Created | @wip |
| apps/api/tests/bdd/features/auth.feature | BDD | Created | @wip |
| apps/web/src/architecture/naming.arch.test.ts | Arch | Updated | PASS |

### Summary
- Unit tests created: X
- Unit tests updated: X
- BDD features created: X
- BDD step definitions created: X
- Arch tests updated: X
- All unit/arch tests passing: YES/NO

After presenting the summary, clean up the team with TeamDelete.

Important Notes

Launch agents immediately — do NOT wait for user confirmation.
Only create tasks for agent types that have relevant changes. If no files changed in apps/api/, do not create api-unit-tests or api-bdd-tests tasks.
Each agent prompt MUST include the shared rules (pnpm, fireEvent, no coverage lowering, no commits).
If there are no changes vs master, report that and exit early.
Do not commit any changes — show the user what was created for review.

Install create-missing-tests and it becomes one more candidate the router can pick - when it fits.

A listing is a routing target with a manifest: what it does, which domains it covers, what it costs and who publishes it. Once installed it sits beside your own models and tools, is scored like any other candidate for each request, and shows up in the trace when it wins. Ratings come from workspaces that installed it, one per account.

# Create Missing Tests for Branch Changes Analyze all changes on the current branch compared to `master`, then create missing tests using a team of parallel agents. ## Context - **Repository**: InZone monorepo - **Current branch**: `{{ git.currentBranch }}` - **Base branch**: `master` ## Project Structure ``` InZone/ ├── apps/ │ ├── web/ # React frontend (Vite + Vitest + RTL + Playwright-BDD) │ │ ├── src/ │ │ │ ├── components/ # UI components │ │ │ ├── hooks/ # Custom hooks │ │ │ ├── api/ # API client │ │ │ ├── lib/ # Utilities │ │ │ ├── pages/ # Page components │ │ │ └── architecture/ # Architecture tests (*.arch.test.ts) │ │ └── tests/bdd/ │ │ ├── features/ # Playwright-BDD feature files │ │ └── steps/ # Step definitions │ └── api/ # Backend API (Vitest + Cucumber.js BDD) │ ├── src/ │ │ ├── routes/ # Route handlers │ │ ├── services/ # Business logic │ │ ├── middleware/ # Middleware │ │ ├── validators/ # Input validators │ │ └── architecture/ # Architecture tests (*.arch.test.ts) │ └── tests/bdd/ │ ├── features/ # Cucumber-BDD feature files │ └── step-definitions/ # Step definitions └── packages/ └── shared/ # Shared types/utilities └── src/ └── architecture/ # Architecture tests ``` ## Step 1: Analyze Branch Changes Run the following to identify all changed/added files: ```bash git diff master...HEAD --name-only --diff-filter=ACMR ``` Categorize the changed files into these buckets: - **web-source**: Files in `apps/web/src/` that are NOT test files (`*.test.ts`, `*.test.tsx`, `*.arch.test.ts`) - **api-source**: Files in `apps/api/src/` that are NOT test files - **web-features**: New routes, pages, or components with user flows (candidates for BDD) - **api-features**: New or changed API endpoints, services with business logic (candidates for BDD) - **structural**: New directories, new modules, new patterns (candidates for arch tests) - **shared**: Files in `packages/shared/` Skip files that are already test files, config files, or documentation. ## Step 2: Create Team and Tasks 1. **Create a team** called `test-creators`. 2. **Create one task per agent type**, but only for categories that have relevant changes. Each task description should include: - The list of changed source files relevant to that agent - The full diff for those files (or instructions to read the diff) - What the agent should do (detailed below) ### Task Descriptions #### Task: `web-unit-tests` **Condition**: Only create if there are changed files in `apps/web/src/` ``` Analyze and create missing unit tests for changed frontend files. Changed files: <list the web-source files here> Instructions: 1. For each changed source file, check if a corresponding test file exists: - Component files (*.tsx) -> *.test.tsx - Hook files (*.ts in hooks/) -> *.test.ts - Utility files (*.ts) -> *.test.ts - Files in architecture/ are excluded (handled by arch-tests agent) 2. Read the diff for each file: git diff master...HEAD -- <file> 3. Read existing test files nearby to understand patterns and conventions 4. If test file is MISSING: create it following existing patterns in the codebase 5. If test file EXISTS but doesn't cover the changes: add new test cases 6. Run tests to verify they pass: cd apps/web && pnpm vitest run --coverage <test-file> 7. Ensure coverage meets 80% threshold for the changed files 8. Report what was created/updated Rules: - Use pnpm (never npm/npx/yarn) - NEVER lower coverage thresholds — add more tests instead - Use fireEvent instead of userEvent.type() for inputs with special chars, long strings, or whitespace - Follow existing test patterns in the codebase - Do not commit any changes ``` #### Task: `api-unit-tests` **Condition**: Only create if there are changed files in `apps/api/src/` ``` Analyze and create missing unit tests for changed backend files. Changed files: <list the api-source files here> Instructions: 1. For each changed source file, check if a corresponding .test.ts file exists - Files in architecture/ are excluded (handled by arch-tests agent) 2. Read the diff for each file: git diff master...HEAD -- <file> 3. Read existing test files nearby to understand patterns and conventions 4. If test file is MISSING: create it following existing patterns 5. If test file EXISTS but doesn't cover the changes: add new test cases 6. Run tests to verify they pass: cd apps/api && pnpm vitest run --coverage <test-file> 7. Ensure coverage meets 80% threshold for the changed files 8. Report what was created/updated Rules: - Use pnpm (never npm/npx/yarn) - NEVER lower coverage thresholds — add more tests instead - Follow existing test patterns in the codebase - Do not commit any changes ``` #### Task: `web-bdd-tests` **Condition**: Only create if there are new routes, pages, or components with user-facing flows ``` Analyze and create missing BDD feature files for new frontend functionality. Changed files with user flows: <list the web-features files here> Instructions: 1. Read the changed source files to understand the new user-facing functionality 2. Check existing BDD features in apps/web/tests/bdd/features/ for coverage 3. Read existing feature files and step definitions to understand patterns 4. If a new user flow is NOT covered by any existing feature: a. Create a new .feature file in apps/web/tests/bdd/features/ b. Create corresponding step definitions in apps/web/tests/bdd/steps/ c. Tag new scenarios with @wip 5. If an existing feature partially covers the flow: add new scenarios (tagged @wip) 6. Do NOT run BDD tests (they require dev servers) — just create the files 7. Report what was created/updated Rules: - Use pnpm (never npm/npx/yarn) - Write scenarios in business language, not technical language - Follow existing Playwright-BDD patterns in the codebase - Tag all new features/scenarios as @wip - Do not commit any changes ``` #### Task: `api-bdd-tests` **Condition**: Only create if there are new/changed API endpoints or business logic ``` Analyze and create missing BDD feature files for new API functionality. Changed files with API logic: <list the api-features files here> Instructions: 1. Read the changed source files to understand the new API functionality 2. Check existing BDD features in apps/api/tests/bdd/features/ for coverage 3. Read existing feature files and step definitions to understand patterns 4. If new API behavior is NOT covered by any existing feature: a. Create a new .feature file in apps/api/tests/bdd/features/ b. Create corresponding step definitions in apps/api/tests/bdd/step-definitions/ c. Tag new scenarios with @wip 5. If an existing feature partially covers the behavior: add new scenarios (tagged @wip) 6. Do NOT run BDD tests (they require dev servers + DB) — just create the files 7. Report what was created/updated Rules: - Use pnpm (never npm/npx/yarn) - Write scenarios in business language, not technical language - Follow existing Cucumber.js patterns in the codebase - Tag all new features/scenarios as @wip - Do not commit any changes ``` #### Task: `arch-tests` **Condition**: Only create if there are structural changes (new modules, directories, patterns) ``` Analyze and update architecture tests for structural changes. Structural changes: <list the structural changes here> Instructions: 1. Read the changed/added files to understand new structure 2. Check existing architecture tests: - apps/web/src/architecture/*.arch.test.ts - apps/api/src/architecture/*.arch.test.ts - packages/shared/src/architecture/*.arch.test.ts (if applicable) 3. Read existing arch test files to understand patterns and conventions 4. If new modules/directories/patterns are not covered by existing arch rules: a. Add new rules to existing arch test files b. Or create new arch test files if needed 5. Run arch tests to verify: cd <app-dir> && pnpm run test:arch 6. Report what was created/updated Rules: - Use pnpm (never npm/npx/yarn) - Follow existing architecture test patterns - Only add rules for genuinely new structural patterns - Do not commit any changes ``` ## Step 3: Spawn Agents Spawn agents using the Task tool with `subagent_type: "general-purpose"` and `team_name: "test-creators"`. ### Batch 1 (up to 4 agents): Unit test and arch test agents Spawn these in parallel: - `web-unit-tests` agent (if task exists) - `api-unit-tests` agent (if task exists) - `arch-tests` agent (if task exists) ### Batch 2: BDD agents (after Batch 1 completes) Spawn these in parallel: - `web-bdd-tests` agent (if task exists) - `api-bdd-tests` agent (if task exists) BDD agents are spawned last because they depend on understanding what the unit test agents may have already created, and they are creating feature files that describe higher-level behavior. ## Step 4: Monitor and Collect Results - Wait for each batch to complete before starting the next. - Use TaskList and TaskGet to monitor progress. - Collect results from all agents. ## Step 5: Present Final Summary Present a summary table of all created/updated test files: ```markdown ## Test Creation Summary — `<branch>` vs `master` ### Created/Updated Test Files | File | Type | Action | Status | |------|------|--------|--------| | apps/web/src/components/Foo.test.tsx | Unit | Created | PASS | | apps/api/src/routes/bar.test.ts | Unit | Updated | PASS | | apps/web/tests/bdd/features/login.feature | BDD | Created | @wip | | apps/api/tests/bdd/features/auth.feature | BDD | Created | @wip | | apps/web/src/architecture/naming.arch.test.ts | Arch | Updated | PASS | ### Summary - Unit tests created: X - Unit tests updated: X - BDD features created: X - BDD step definitions created: X - Arch tests updated: X - All unit/arch tests passing: YES/NO ``` After presenting the summary, clean up the team with TeamDelete. ## Important Notes - Launch agents immediately — do NOT wait for user confirmation. - Only create tasks for agent types that have relevant changes. If no files changed in `apps/api/`, do not create api-unit-tests or api-bdd-tests tasks. - Each agent prompt MUST include the shared rules (pnpm, fireEvent, no coverage lowering, no commits). - If there are no changes vs master, report that and exit early. - Do not commit any changes — show the user what was created for review.

{ "prompt": "# Create Missing Tests for Branch Changes\n\nAnalyze all changes on the current branch compared to `master`, then create missing tests using a team of parallel agents.\n\n## Context\n\n- **Repository**: InZone monorepo\n- **Current branch**: `{{ git.currentBranch }}`\n- **Base branch**: `master`\n\n## Project Structure\n\n```\nInZone/\n├── apps/\n│ ├── web/ # React frontend (Vite + Vitest + RTL + Playwright-BDD)\n│ │ ├── src/\n│ │ │ ├── components/ # UI components\n│ │ │ ├── hooks/ # Custom hooks\n│ │ │ ├── api/ # API client\n│ │ │ ├── lib/ # Utilities\n│ │ │ ├── pages/ # Page components\n│ │ │ └── architecture/ # Architecture tests (*.arch.test.ts)\n│ │ └── tests/bdd/\n│ │ ├── features/ # Playwright-BDD feature files\n│ │ └── steps/ # Step definitions\n│ └── api/ # Backend API (Vitest + Cucumber.js BDD)\n│ ├── src/\n│ │ ├── routes/ # Route handlers\n│ │ ├── services/ # Business logic\n│ │ ├── middleware/ # Middleware\n│ │ ├── validators/ # Input validators\n│ │ └── architecture/ # Architecture tests (*.arch.test.ts)\n│ └── tests/bdd/\n│ ├── features/ # Cucumber-BDD feature files\n│ └── step-definitions/ # Step definitions\n└── packages/\n └── shared/ # Shared types/utilities\n └── src/\n └── architecture/ # Architecture tests\n```\n\n## Step 1: Analyze Branch Changes\n\nRun the following to identify all changed/added files:\n\n```bash\ngit diff master...HEAD --name-only --diff-filter=ACMR\n```\n\nCategorize the changed files into these buckets:\n- **web-source**: Files in `apps/web/src/` that are NOT test files (`*.test.ts`, `*.test.tsx`, `*.arch.test.ts`)\n- **api-source**: Files in `apps/api/src/` that are NOT test files\n- **web-features**: New routes, pages, or components with user flows (candidates for BDD)\n- **api-features**: New or changed API endpoints, services with business logic (candidates for BDD)\n- **structural**: New directories, new modules, new patterns (candidates for arch tests)\n- **shared**: Files in `packages/shared/`\n\nSkip files that are already test files, config files, or documentation.\n\n## Step 2: Create Team and Tasks\n\n1. **Create a team** called `test-creators`.\n\n2. **Create one task per agent type**, but only for categories that have relevant changes. Each task description should include:\n - The list of changed source files relevant to that agent\n - The full diff for those files (or instructions to read the diff)\n - What the agent should do (detailed below)\n\n### Task Descriptions\n\n#### Task: `web-unit-tests`\n**Condition**: Only create if there are changed files in `apps/web/src/`\n\n```\nAnalyze and create missing unit tests for changed frontend files.\n\nChanged files:\n<list the web-source files here>\n\nInstructions:\n1. For each changed source file, check if a corresponding test file exists:\n - Component files (*.tsx) -> *.test.tsx\n - Hook files (*.ts in hooks/) -> *.test.ts\n - Utility files (*.ts) -> *.test.ts\n - Files in architecture/ are excluded (handled by arch-tests agent)\n2. Read the diff for each file: git diff master...HEAD -- <file>\n3. Read existing test files nearby to understand patterns and conventions\n4. If test file is MISSING: create it following existing patterns in the codebase\n5. If test file EXISTS but doesn't cover the changes: add new test cases\n6. Run tests to verify they pass: cd apps/web && pnpm vitest run --coverage <test-file>\n7. Ensure coverage meets 80% threshold for the changed files\n8. Report what was created/updated\n\nRules:\n- Use pnpm (never npm/npx/yarn)\n- NEVER lower coverage thresholds — add more tests instead\n- Use fireEvent instead of userEvent.type() for inputs with special chars, long strings, or whitespace\n- Follow existing test patterns in the codebase\n- Do not commit any changes\n```\n\n#### Task: `api-unit-tests`\n**Condition**: Only create if there are changed files in `apps/api/src/`\n\n```\nAnalyze and create missing unit tests for changed backend files.\n\nChanged files:\n<list the api-source files here>\n\nInstructions:\n1. For each changed source file, check if a corresponding .test.ts file exists\n - Files in architecture/ are excluded (handled by arch-tests agent)\n2. Read the diff for each file: git diff master...HEAD -- <file>\n3. Read existing test files nearby to understand patterns and conventions\n4. If test file is MISSING: create it following existing patterns\n5. If test file EXISTS but doesn't cover the changes: add new test cases\n6. Run tests to verify they pass: cd apps/api && pnpm vitest run --coverage <test-file>\n7. Ensure coverage meets 80% threshold for the changed files\n8. Report what was created/updated\n\nRules:\n- Use pnpm (never npm/npx/yarn)\n- NEVER lower coverage thresholds — add more tests instead\n- Follow existing test patterns in the codebase\n- Do not commit any changes\n```\n\n#### Task: `web-bdd-tests`\n**Condition**: Only create if there are new routes, pages, or components with user-facing flows\n\n```\nAnalyze and create missing BDD feature files for new frontend functionality.\n\nChanged files with user flows:\n<list the web-features files here>\n\nInstructions:\n1. Read the changed source files to understand the new user-facing functionality\n2. Check existing BDD features in apps/web/tests/bdd/features/ for coverage\n3. Read existing feature files and step definitions to understand patterns\n4. If a new user flow is NOT covered by any existing feature:\n a. Create a new .feature file in apps/web/tests/bdd/features/\n b. Create corresponding step definitions in apps/web/tests/bdd/steps/\n c. Tag new scenarios with @wip\n5. If an existing feature partially covers the flow: add new scenarios (tagged @wip)\n6. Do NOT run BDD tests (they require dev servers) — just create the files\n7. Report what was created/updated\n\nRules:\n- Use pnpm (never npm/npx/yarn)\n- Write scenarios in business language, not technical language\n- Follow existing Playwright-BDD patterns in the codebase\n- Tag all new features/scenarios as @wip\n- Do not commit any changes\n```\n\n#### Task: `api-bdd-tests`\n**Condition**: Only create if there are new/changed API endpoints or business logic\n\n```\nAnalyze and create missing BDD feature files for new API functionality.\n\nChanged files with API logic:\n<list the api-features files here>\n\nInstructions:\n1. Read the changed source files to understand the new API functionality\n2. Check existing BDD features in apps/api/tests/bdd/features/ for coverage\n3. Read existing feature files and step definitions to understand patterns\n4. If new API behavior is NOT covered by any existing feature:\n a. Create a new .feature file in apps/api/tests/bdd/features/\n b. Create corresponding step definitions in apps/api/tests/bdd/step-definitions/\n c. Tag new scenarios with @wip\n5. If an existing feature partially covers the behavior: add new scenarios (tagged @wip)\n6. Do NOT run BDD tests (they require dev servers + DB) — just create the files\n7. Report what was created/updated\n\nRules:\n- Use pnpm (never npm/npx/yarn)\n- Write scenarios in business language, not technical language\n- Follow existing Cucumber.js patterns in the codebase\n- Tag all new features/scenarios as @wip\n- Do not commit any changes\n```\n\n#### Task: `arch-tests`\n**Condition**: Only create if there are structural changes (new modules, directories, patterns)\n\n```\nAnalyze and update architecture tests for structural changes.\n\nStructural changes:\n<list the structural changes here>\n\nInstructions:\n1. Read the changed/added files to understand new structure\n2. Check existing architecture tests:\n - apps/web/src/architecture/*.arch.test.ts\n - apps/api/src/architecture/*.arch.test.ts\n - packages/shared/src/architecture/*.arch.test.ts (if applicable)\n3. Read existing arch test files to understand patterns and conventions\n4. If new modules/directories/patterns are not covered by existing arch rules:\n a. Add new rules to existing arch test files\n b. Or create new arch test files if needed\n5. Run arch tests to verify: cd <app-dir> && pnpm run test:arch\n6. Report what was created/updated\n\nRules:\n- Use pnpm (never npm/npx/yarn)\n- Follow existing architecture test patterns\n- Only add rules for genuinely new structural patterns\n- Do not commit any changes\n```\n\n## Step 3: Spawn Agents\n\nSpawn agents using the Task tool with `subagent_type: \"general-purpose\"` and `team_name: \"test-creators\"`.\n\n### Batch 1 (up to 4 agents): Unit test and arch test agents\nSpawn these in parallel:\n- `web-unit-tests` agent (if task exists)\n- `api-unit-tests` agent (if task exists)\n- `arch-tests` agent (if task exists)\n\n### Batch 2: BDD agents (after Batch 1 completes)\nSpawn these in parallel:\n- `web-bdd-tests` agent (if task exists)\n- `api-bdd-tests` agent (if task exists)\n\nBDD agents are spawned last because they depend on understanding what the unit test agents may have already created, and they are creating feature files that describe higher-level behavior.\n\n## Step 4: Monitor and Collect Results\n\n- Wait for each batch to complete before starting the next.\n- Use TaskList and TaskGet to monitor progress.\n- Collect results from all agents.\n\n## Step 5: Present Final Summary\n\nPresent a summary table of all created/updated test files:\n\n```markdown\n## Test Creation Summary — `<branch>` vs `master`\n\n### Created/Updated Test Files\n\n| File | Type | Action | Status |\n|------|------|--------|--------|\n| apps/web/src/components/Foo.test.tsx | Unit | Created | PASS |\n| apps/api/src/routes/bar.test.ts | Unit | Updated | PASS |\n| apps/web/tests/bdd/features/login.feature | BDD | Created | @wip |\n| apps/api/tests/bdd/features/auth.feature | BDD | Created | @wip |\n| apps/web/src/architecture/naming.arch.test.ts | Arch | Updated | PASS |\n\n### Summary\n- Unit tests created: X\n- Unit tests updated: X\n- BDD features created: X\n- BDD step definitions created: X\n- Arch tests updated: X\n- All unit/arch tests passing: YES/NO\n```\n\nAfter presenting the summary, clean up the team with TeamDelete.\n\n## Important Notes\n\n- Launch agents immediately — do NOT wait for user confirmation.\n- Only create tasks for agent types that have relevant changes. If no files changed in `apps/api/`, do not create api-unit-tests or api-bdd-tests tasks.\n- Each agent prompt MUST include the shared rules (pnpm, fireEvent, no coverage lowering, no commits).\n- If there are no changes vs master, report that and exit early.\n- Do not commit any changes — show the user what was created for review.", "variables": [], "notes": "Find and create missing tests for current branch changes vs master Tools: Bash(*), Read, Write, Edit, Glob, Grep, Task, TeamCreate, TeamDelete, TaskCreate, TaskUpdate, TaskList.", "metadata": { "source": { "provider": "github-claude-commands", "repository": "https://github.com/sarthchawla/InZone", "path": ".claude/commands/create-missing-tests.md", "ref": "df65dbb52d61168b118825f95a8bfe64f9b1164a", "url": "https://github.com/sarthchawla/InZone/blob/df65dbb52d61168b118825f95a8bfe64f9b1164a/.claude/commands/create-missing-tests.md", "key": "sarthchawla/InZone/.claude/commands/create-missing-tests.md" } } }

create-missing-tests

About

Create Missing Tests for Branch Changes

Context

Project Structure

Step 1: Analyze Branch Changes

Step 2: Create Team and Tasks

Task Descriptions

Task: `web-unit-tests`

Task: `api-unit-tests`

Task: `web-bdd-tests`

Task: `api-bdd-tests`

Task: `arch-tests`

Step 3: Spawn Agents

Batch 1 (up to 4 agents): Unit test and arch test agents

Batch 2: BDD agents (after Batch 1 completes)

Step 4: Monitor and Collect Results

Step 5: Present Final Summary

Important Notes

Install create-missing-tests and it becomes one more candidate the router can pick - when it fits.

What it costs to adopt - in engineering time.

One base URL

No vendor lock-in

Failover built in

Use it

Manifest

Reviews

About

Create Missing Tests for Branch Changes

Context

Project Structure

Step 1: Analyze Branch Changes

Step 2: Create Team and Tasks

Task Descriptions

Task: web-unit-tests

Task: api-unit-tests

Task: web-bdd-tests

Task: api-bdd-tests

Task: arch-tests

Step 3: Spawn Agents

Batch 1 (up to 4 agents): Unit test and arch test agents

Batch 2: BDD agents (after Batch 1 completes)

Step 4: Monitor and Collect Results

Step 5: Present Final Summary

Important Notes

Install create-missing-tests and it becomes one more candidate the router can pick - when it fits.

What it costs to adopt - in engineering time.

One base URL

No vendor lock-in

Failover built in

Use it

Manifest

Reviews

Task: `web-unit-tests`

Task: `api-unit-tests`

Task: `web-bdd-tests`

Task: `api-bdd-tests`

Task: `arch-tests`