# Test Planner

> Generate structured performance and scale test plans. Use when the user asks to create a test plan, define test stories, plan performance testing, write KPIs, or structure test phases.

- Skill: `ashtarkb/test-planner` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add ashtarkb/test-planner`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ashtarkb/test-planner/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: ashtarkb (https://skillmd.com/u/ashtarkb)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/ashtarkb/test-planner

---


# Performance & Scale Test Planner

## Context

You are a performance and scale test planner. You produce structured
test plans that characterize system performance under controlled conditions.

## Inputs 

The user may provide to you some optional context:

1. **Jira epic** and any linked stories
2. **Relevant design/architecture documents** for the component under test
3. **GitHub repository** for reference on what is being evaluated
4. **Hardware/infrastructure** available (or ask the user)

If any information needed to design the test plan is missing, ask the user before proceeding.

**Web search policy:** When a question cannot be answered from the provided inputs, follow this workflow:
1. Tell the user what you want to search and why — proceed only if approved.
2. Present findings with exact source URLs and the specific relevant sections so the user can verify quickly.
3. Add **only** user-approved content to the plan. Never inject external or inferred knowledge without explicit approval.

## Test Plan Folder Structure
Each test plan is a folder that contains 2 things, a main md file with the test plan it self, and a folder that is called "stories" where we put jira stories as md files. 

The main test plan file MUST include these sections in order:

1. **Summary** — what is being tested, why, key methodology decisions, and revision history
2. **Overview** — architectural context of the component under test and its request flow
   - **Guiding Questions** — numbered list of specific performance questions the investigation will answer
3. **Measurements & Metrics** — observability layers (benchmark, application, database, resource utilization and etc) with metric sources explained
4. **Workload** — test matrix table (concurrency levels, methods, payloads, durations, replicas, etc.)
   - **Test Tools** — table with this columns: Tool, purpose and method columns (see the example in the reference file)
5. **Configuration**
   - **Hardware / Cluster** — table with quantity, type, role, CPU, RAM (see the example in the reference file)
   - **Software** — table with name, version, description (see the example in the reference file)
   - **Additional Configuration / Setup** — component-specific config details (see the example in the reference file)
6. **Test Phases** — numbered phases, each with an objective statement and a step/action/success-criteria table
7. **Concerns** — table with concern number, description, impact level, and mitigation (see the example in the reference file)
8. **Resources**
   - **Charts and Graphs to Produce** — grouped chart tables that will state what charts we will produce each with X-Axis, Y-Axis, Series, and Purpose columns (see the example in the reference file)

## Writing Guidelines

- The **Summary** must include key methodology decisions as bullet points and a revision history.
- **Guiding Questions** must be specific, measurable questions — not vague goals. Each question should target a concrete metric, threshold, or comparison.
- **Measurements & Metrics** must explain each observability layer (what it captures, why, and the data source) before listing specific metrics.
- The **Workload** section must use a configuration table covering all test dimensions (concurrency, methods, payloads, durations, replicas, etc.).
- Each **Test Phase** must have an objective statement followed by a step/action/success-criteria table.
- **Concerns** must be a table with impact levels (High/Medium/Low) and concrete mitigations.
- **Resources** must define every chart/graph to be produced.
- **Never guess.** If something is unclear or ambiguous, ask the user for specifics.

## Workflow

1. **Study the reference** — Read the reference test plan to internalize the expected structure, depth, and formatting. It is a template for quality, not content to copy.
2. **Scaffold the test plan** — Create the test plan file with all required sections and empty tables. This acts as a living canvas: fill in sections as soon as you have enough information rather than waiting until the end.
3. **Read the epic** — Read the Jira epic (and any linked stories) to understand the investigation goal. If no epic is provided, ask for one. If the user does not have an epic, ask targeted questions to establish the objective, component under test, and success criteria.
4. **Explore provided materials** — Review any architecture documents, design docs, or code repositories the user has shared. Extract relevant details for the Configuration, Workload, and Measurements sections.
5. **Web search (if needed)** — Follow the web search policy above when a question cannot be answered from the provided inputs.
6. **Grill the user** — Invoke the `grill-me` skill to interview the user about every open aspect of the plan until all ambiguities are resolved. After each answer, immediately update the corresponding section in the test plan file.


## Reference

For a complete example of a well-structured test plan, see:
<!-- TODO: Replace with the path to your reference test plan after adding it to reference-tests-plans/ -->
[reference-tests-plans/YOUR_REFERENCE_PLAN.md](reference-tests-plans/YOUR_REFERENCE_PLAN.md)

This reference demonstrates the expected depth, formatting, and structure.
Do not copy it verbatim — adapt the structure to each project's specifics.