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.
npx skills add chrono-meta/forge-harness --skill qp-plan -a claude-codeWhat 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.mdand 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-code2Manually: put the files in place
~/.claude/skills/qp-plan/SKILL.mdCopy the whole skill folder; for one project use .claude/skills/qp-plan/
1Skills CLI (Vercel)
npx skills add chrono-meta/forge-harness --skill qp-plan -a codex2Manually: put the files in place
.agents/skills/qp-plan/SKILL.mdFor all projects use ~/.agents/skills/
1Skills CLI (Vercel)
npx skills add chrono-meta/forge-harness --skill qp-plan -a cursor2Manually: put the files in place
.cursor/skills/qp-plan/SKILL.mdCursor also reads .agents/skills/ and .claude/skills/
1GitHub CLI
gh skill install chrono-meta/forge-harness qp-plan2Manually: put the files in place
.github/skills/qp-plan/SKILL.md1Skills CLI (Vercel)
npx skills add chrono-meta/forge-harness --skill qp-plan -a gemini-cli2Platform CLI
gemini skills install https://github.com/chrono-meta/forge-harness --path plugins/fh-qp/skills/qp-planManually: put the files in place
.devin/skills/qp-plan/SKILL.mdThe legacy .windsurf/skills/ path still works
Skills CLI (Vercel)
npx skills add chrono-meta/forge-harness --skill qp-plan -a opencodeClaude.ai
Zip the folder and upload it in Settings → Capabilities → Skills
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