test-plan

test-plan is a command for Claude Code from thapaliyabikendra/ai-artifacts. It costs 12 tokens per session (1,111 once invoked), scanned A, original, Apache-2.0.

A command that turns feature requirements and acceptance criteria into a structured test plan. It covers unit tests, integration tests, and end-to-end tests, which check complete user journeys.

In plain words
What is it for?
Use it to plan tests from a requirements file or feature name, including business logic, database access, application services, and critical user flows.
Why use it?
It helps avoid missing important cases when planning tests for a new feature. It also organizes which parts of the system each test should cover.

Command for Claude Code

Written for Claude Code: $ARGUMENTS substitution.

Good fit Use it to plan tests from a requirements file or feature name…

Compare 6 commands from other repositories ↓
Install with agentmods
npx agentmods add commands/thapaliyabikendra/ai-artifacts/test-plan
Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

Clone the repo
git clone --depth 1 https://github.com/thapaliyabikendra/ai-artifacts

Made for: Claude Code.

Wrote this? Show the measurements

A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.

agentmods badge for test-plan

README.md
[![agentmods](https://agentmods.dev/badge/commands/thapaliyabikendra/ai-artifacts/test-plan.svg)](https://agentmods.dev/commands/thapaliyabikendra/ai-artifacts/test-plan)
Your own site
<a href="https://agentmods.dev/commands/thapaliyabikendra/ai-artifacts/test-plan"><img src="https://agentmods.dev/badge/commands/thapaliyabikendra/ai-artifacts/test-plan.svg" alt="Measured on agentmods" height="20"></a>
Per session 12 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.
When invoked 1,111 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. A grade says what 26 rules found in the file — not that it is safe.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5.1 $0.00012 $0.01111
Opus 5 $0.00006 $0.00556
Sonnet 5 $0.00002 $0.00222
Haiku 4.5 $0.00001 $0.00111

Measured 6d ago against content hash 23463e969754, method: parsed. Prices are Anthropic first-party input rates as of 2026-09-06, from the pricing page.

Security

Grade A, and why

test-plan scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 6d ago.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

.claude/commands/qa/test-plan.md · 173 lines

How it starts

The opening of the file, as written. The whole thing — 173 lines — stays where its author put it; the contents beside it link to each section on GitHub.

Generate Test Plan

Generate a comprehensive test plan for: $ARGUMENTS.feature Test scope: $ARGUMENTS.type

Instructions

Step 1: Gather Context

  1. Read requirements/feature file if path provided
  2. If feature name only, search for:
    • docs/features/{feature}/requirements.md
    • docs/features/{feature}/design.md
    • Related entity definitions in docs/domain/entities/
  3. Identify all user stories and acceptance criteria

Step 2: Identify Test Categories

For each user story, identify:

Category Coverage Target Framework
Unit Tests Business logic, validators, domain services xUnit + NSubstitute
Integration Tests AppServices, repositories, EF queries xUnit + WebApplicationFactory
E2E Tests Critical user flows Playwright

Step 3: Generate Test Plan

Use this template:

# Test Plan: [Feature Name]

## Overview
- **Feature**: [Name]
- **Version**: 1.0
- **Created**: [Date]
- **Test Scope**: [unit/integration/e2e/all]

## Test Summary

| Type | Test Count | Coverage Target |
|------|------------|-----------------|
| Unit | [N] | >80% business logic |
| Integration | [N] | All AppService methods |
| E2E | [N] | Critical paths only |

## User Stories Coverage

### US-001: [Story Title]

**Acceptance Criteria:**
- [ ] AC1: [Description]
- [ ] AC2: [Description]

**Test Cases:**

| ID | Type | Scenario | Given | When | Then | Priority |
|----|------|----------|-------|------|------|----------|
| TC-001 | Unit | [name] | [setup] | [action] | [expected] | P1 |
| TC-002 | Integration | [name] | [setup] | [action] | [expected] | P1 |
| TC-003 | E2E | [name] | [setup] | [action] | [expected] | P2 |

### US-002: [Story Title]
[Repeat structure...]

## Unit Test Specifications

### [ClassName]Tests.cs
Location: `test/[Module].Application.Tests/`

```csharp
public class [ClassName]Tests : [Module]ApplicationTestBase
{
    // TC-001: [Test scenario]
    [Fact]
    public async Task [MethodName]_[Scenario]_[ExpectedResult]()
    {
        // Arrange
        // Act
        // Assert
    }
}

Integration Test Specifications

[FeatureName]IntegrationTests.cs

Location: test/[Module].HttpApi.Tests/

public class [FeatureName]IntegrationTests : [Module]HttpApiTestBase
{
    // TC-002: [Test scenario]
    [Fact]
    public async Task [Endpoint]_[Scenario]_Returns[StatusCode]()
    {
        // Arrange
        // Act: var response = await Client.GetAsync("/api/...");
        // Assert
    }
}

E2E Test Specifications

[feature-name].spec.ts

Location: e2e/tests/

test.describe('[Feature Name]', () => {
    // TC-003: [Test scenario]
    test('[user action] should [expected result]', async ({ page }) => {
        // Arrange: Navigate, login if needed
        // Act: User interactions
        // Assert: Verify outcomes
    });
});

Test Data Requirements

Entity Test Data Seeder Location
[Entity1] [Description] TestDataSeeder.cs
[Entity2] [Description] TestDataSeeder.cs

Risks and Mitigations

Risk Impact Mitigation
[Risk 1] [High/Medium/Low] [Strategy]

Dependencies

  • Test database configured
  • Test data seeders implemented
  • Mocks for external services ready

Read the full file on GitHub · 173 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. 6d ago First seen · 173 lines · 12 tokens per session scan A 23463e969754

Subscribe to this mod's changes

test-plan is a command published in the GitHub repository thapaliyabikendra/ai-artifacts (24 stars, last pushed 5mo ago), licensed Apache-2.0. It adds 12 tokens to every session and 1,111 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.