JanVas

Test Plan Flow — Testing skill for Claude Code

Testing community

A workflow for turning a tracker issue into reviewed manual test cases — review depth decided by criticality tier before any code is read.

How to install Test Plan Flow

This entry records only its repository, not the path inside it, so there is no exact command to give. Open JanVas/test-plan-flow and copy the folder into ~/.claude/skills/, or the file into ~/.claude/agents/.

What Test Plan Flow does

A workflow for turning a tracker issue into reviewed manual test cases — review depth decided by criticality tier before any code is read. Claude Code skill + method.

Alternatives in Testing

Fix Issue — by metabase - Addresses GitHub issues by taking issue number as parameter, analyzing context, implementing sol 46.5k ★
Debug — You are tasked with helping debug issues during manual testing or implementation 10k ★
Spec Driven Develop — Spec-driven development workflow for AI coding agents: architecture-first planning, task decomposition, GitHub 975 ★

README

Test plan flow

A workflow for turning a tracker issue into a reviewed set of manual test cases, where **how much review the change gets is decided before anyone reads the diff**.

It ships as a [Claude Code](https://claude.com/claude-code) skill ([`SKILL.md`](SKILL.md)), but the method is the point and it works as a checklist for a human. If you only read one file, read [`examples/discount-code-at-checkout.md`](examples/discount-code-at-checkout.md) — it is one fictional issue run through the whole flow, output included.

The problem it solves

Test planning fails in two directions, usually in the same sprint.

A tooltip change gets an afternoon of diff reading because the code turned out to be interesting. Then a payment change gets the same six cases as the tooltip, because by then there was no time left and nobody had said out loud that this one was different.

Both failures have the same cause: **the depth of the review was never decided, it just happened.** So this flow decides it first, in one line, before the first file is opened.

The four ideas

**1. A criticality tier gates the review, not just the output.** Low, Standard or Critical is settled in Step 2 — before the pull request, the code or the test suite is touched. Low means the diff is deliberately *not* traced and 3–6 cases are enough. Critical means full depth and no case budget. The tier is inferred and confirmed in one line rather than asked as an open question, because "how critical is this?" is a question most people answer with "fairly".

**2. Test the product, not the implementation.** A test plan covers product behaviour against the spec. Code quality, architecture, naming and unit-test coverage belong to code review — a different job, with different people on it. A technical weakness that creates a user-visible risk gets one line under Gaps and nothing more. This single rule removes most of the noise a code-aware tester is tempted to produce.

**3. Every case carries a confidence ta