Skip to main content
skill CX Codex

qp-plan — Claude Code skill: test planning and installation

qp-plan maps the visible surfaces of a web page or desktop app, then writes test cases to TSV. Use it to prepare a structured pass through an interface.

Install into Claude Code · Skills CLI (Vercel) All methods and platforms ↓
npx skills add chrono-meta/forge-harness --skill qp-plan -a claude-code
Open on GitHub

What qp-plan does

The skill records routes, menu items, dialogs, forms, and tabs it can reach from the entry screen. It checks that inventory against the visible interface, adding omissions and merging entries that lead to the same surface. It does not make up routes.

It writes the map to qp/plan/inventory.md and cases to qp/plan/tcs.tsv. Each case includes prerequisites, steps, expected values, and the source of those expectations. Without a plan document, expectations come from the inventory. An unreachable entry screen stops the process with HARNESS_ERROR reason=entry-unreachable.

The target must pass qp_tools.sh target-class, and the skill needs an adapter line from adapter-probe. A plan document is optional. It uses Bash and an adapter; qp-run is not needed to prepare the plan. A small site may not meet the suggested surface and case counts.

What it helps with

  • map the visible screens and navigation paths
  • catch missing or duplicate interface surfaces
  • write test cases with prerequisites and expectation sources
  • save an interface inventory and TSV test plan

Example prompts for the agent

  • Make a test plan for this app and save the screen inventory and test cases.
  • List the visible screens on this page, then check the inventory for gaps and duplicate entries.
  • Create test cases from plan.md and identify the source of each expected result.

How to install qp-plan

1Skills CLI (Vercel)

npx skills add chrono-meta/forge-harness --skill qp-plan -a claude-code

2Manually: put the files in place

~/.claude/skills/qp-plan/SKILL.md

Copy the whole skill folder; for one project use .claude/skills/qp-plan/

Step by step, with commands for each platform: How to install skills in Claude Code: five ways

Questions about qp-plan

How do I install qp-plan in Claude Code?

Run npx skills add chrono-meta/forge-harness --skill qp-plan -a claude-code. The skill file is at ~/.claude/skills/qp-plan/SKILL.md.

What does qp-plan do?

It inventories visible app surfaces, checks for omissions and overlap, and writes TSV test cases with prerequisites and the source of each expected value.

Does qp-plan require a specification document?

No. When there is no plan document, expected values come from the interface inventory, and each case records that source.

Source text

SKILL.md · MIT
---
name: qp-plan
description: Prepare stage of QP — builds a surface inventory of a web page or desktop app (routes, menus, forms, dialogs), checks it is MECE (no overlap, nothing missing that is visible), and designs test cases as a TSV with preconditions and expected values whose SOURCE is named. Works without a spec document (then expected values come from the inventory, not a plan). Triggers on "what should I test on this page", "make a test plan for this app", "list the screens of this app", "테스트 케이스 뽑아줘", "이 화면 인벤토리 만들어줘".
user-invocable: true
allowed-tools: ["Read", "Bash", "Write", "Glob", "Grep"]
model: sonnet
origin: chamber run fh-qa-generic (2026-09-05)
---

# qp-plan — Prepare (inventory → MECE → TCs)

Input: a target that passed `qp_tools.sh target-class` (PUBLIC or PROFILE_OK) and an adapter line from `adapter-probe`. Optional: a plan/spec document path (`--plan <file>`). Optional profile.

## 1. Surface inventory — observe, do not guess
Open the entry route with the adapter (web: navigate + accessibility snapshot; desktop: screenshot). Record every **navigable surface** you can see: links/routes, menu items, buttons that open a dialog, forms, tabs. One row each:

```
| id | kind (route·menu·dialog·form·tab) | label as shown | how reached (from which surface, which action) | observed? (yes/no) |
```
Rules: ⓐ **do not invent routes** — a surface is listed only if you saw its trigger; ⓑ parameterised routes (`/item/:id`) are listed as `ROUTE_PARAMETERIZED`, not filled with a made-up id; ⓒ if the entry route did not load → stop with `HARNESS_ERROR reason=entry-unreachable`. Write `qp/plan/inventory.md` with the header lines `target-class: …` (the tool's literal output), `ADAPTER=… evidence=dom|pixel` (the probe's literal output), `engine=mcp-fallback` (or `engine=capability:<id>` only if the `qp` router found a registered capability — never a browser name; a floor-tier sim wrote `engine=chromium` when this line did not say so, 2026-09-05), `plan_doc: <path|NONE>`.

## 2. MECE check
Walk the inventory once more against the snapshot: any visible navigable element not in the list → add it (**missing**); any two rows reaching the same surface → merge (**overlap**). Write the count of each fix under `## MECE` in inventory.md. Zero fixes is a legitimate value; an unstated count is not.

## 3. Test-case design — `qp/plan/tcs.tsv`
Tab-separated, header row:
```
tc_id	surface_id	precondition	step_verb	step_target	expected	expected_source	priority
```
- `step_verb` ∈ `navigate click input verify` (one verb per row; a multi-step TC is several rows sharing `tc_id`).
- `expected_source` ∈ `PLAN_DOC INVENTORY CODE HUMAN` — **where the expected value came from**. With no plan document every row is `INVENTORY` (or `HUMAN` if the user told you). This field is what lets `qp-run` label a finding *differs from plan* vs *code differs*; a TC without it cannot be run.
- `precondition` is what must be true before step 1 (e.g. `at:/`, `logged-in`). Write `none` explicitly when there is none.
- **At least one TC must carry a state-changing verb (`click` or `input`)** — a verify-only plan never exercises the runner (`qp_tools.sh run-verbs` enforces this on the run output).
- Minimum: inventory ≥ 5 surfaces, TCs ≥ 3 for a first pass; say when the target is too small to reach that (a one-page site can be).

## Done When
1. `qp/plan/inventory.md` exists with the four header lines and ≥1 observed surface · **[mandatory-pass]**.
2. `qp/plan/tcs.tsv` parses: every row has 8 fields, `step_verb` and `expected_source` in their enums, ≥1 click/input row · **[measured]** — `awk -F'\t' 'NF!=8' tcs.tsv` prints nothing; `run-verbs` on the later verdicts is OK.
3. No surface in the inventory was invented (each has `observed? yes` or a `ROUTE_PARAMETERIZED` mark) · **[judged — pairing: a second session re-opens the entry route and diffs the inventory; the lane's residency/zero-constant grep on the plan files]**.

## Independently executable
Yes — bash + adapter. Does not need `qp-run`.

© chrono-meta · MIT · chrono-meta/forge-harness

Similar skills

All skills for Testing and QA →

From the same set40

Project sponsors

Companies that keep this analytics open
Gold sponsor

Impressions, clicks and code copies — open statistics. We keep the numbers public for the same reason NeBlask itself is public. Become a sponsor