test-plan

test-plan is a cursor rule for Cursor from katalon-labs/true-skills. It costs 137 tokens per session (1,512 once invoked), scanned A, original, MIT.

A set of instructions for planning Katalon True Platform/TestOps testing for a release, sprint, or feature.

In plain words
What is it for?
Use it to resolve project and iteration scope, find coverage gaps, and create folders and test suites containing the cases to execute.
Why use it?
It turns quality goals into prioritized testing work based on requirements and risk, with a structure the team can run.

Cursor rule for Cursor

Written for Cursor: installed under .cursor/.

Good fit Use it to resolve project and iteration scope, find coverage gaps, and…

Compare 6 cursor rules from other repositories ↓
Install with agentmods
npx agentmods add rules/katalon-labs/true-skills/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/katalon-labs/true-skills

Made for: Cursor.

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/rules/katalon-labs/true-skills/test-plan.svg)](https://agentmods.dev/rules/katalon-labs/true-skills/test-plan)
Your own site
<a href="https://agentmods.dev/rules/katalon-labs/true-skills/test-plan"><img src="https://agentmods.dev/badge/rules/katalon-labs/true-skills/test-plan.svg" alt="Measured on agentmods" height="20"></a>
Per session 137 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,512 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.00137 $0.01512
Opus 5 $0.00068 $0.00756
Sonnet 5 $0.00027 $0.00302
Haiku 4.5 $0.00014 $0.00151

Measured 7d ago against content hash b5cc1d3d670b, 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 7d 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.

.cursor/rules/test-plan.mdc · 110 lines

How it starts

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

Katalon Test Plan

Use this skill for the planning stage of the Katalon lifecycle: turn quality goals into a scoped, risk-prioritized, executable plan. The output is a plan the team can act on plus the folder/suite/release structure that makes it runnable. Prefer Katalon MCP tools for platform data; use the human as a tool when scope, risk appetite, or release target cannot be resolved safely.

Availability Boundary

State the boundary before promising a plan:

  • Available via MCP: resolve scope (list_projects, list_repositories, find_iterations), read requirement coverage and gaps (fetch_requirement_data, find_requirements, find_test_cases_by_requirement), and build the executable plan structure (manage_test_folder, manage_test_suite, add cases to suites).
  • Not directly available: create a Release or Build entity, create a formal Test Plan entity, or author release gates through MCP. These live in the TestOps UI.
  • Workaround (the MCP-legal test plan): a named folder + test suite associated with a sprint/release is the executable plan. Create it, populate it, and report it as the plan of record.

Planning Workflow

+---------------+     +----------------------+     +----------------------+
| Resolve scope | --> | Read coverage + risk | --> | Prioritize what first|
+---------------+     +----------------------+     +----------------------+
        |                        |                             |
        v                        v                             v
+---------------+     +----------------------+     +----------------------+
| Propose plan  | --> | Build folder + suite | --> | Associate sprint/rel |
+---------------+     +----------------------+     +----------------------+

Steps and tool rules

  1. Resolve scope. list_projects -> list_repositories. If exactly one matches the user's wording or context, use it. Use find_iterations to bind the plan to a sprint/release when named.
  2. Read coverage and gaps. Use fetch_requirement_data for requirement coverage status and find_test_cases_by_requirement to see which requirements already have cases. find_requirements / read_requirement when requirement keys are supplied.
  3. Prioritize by risk and evidence. Rank scope using: requirement coverage gaps first, then high-change/high-traffic areas, then areas with historically unstable tests (defer stability detail to test-review). State the risk basis; do not invent traffic numbers the MCP does not return.
  4. Propose the plan in chat. Objectives, in-scope / out-of-scope, coverage matrix (requirement -> planned cases), risk ranking, target environments, and the suite/folder structure you will create.
  5. Materialize the executable structure. manage_test_folder for the plan folder, manage_test_suite for the runnable suite, add the selected/known cases. Reuse an existing folder/suite when one already matches instead of creating a duplicate.
  6. Verify and report. read_test_suite to confirm; report the plan of record with the suite as the executable artifact and the open gaps to fill next.

Read the full file on GitHub · 110 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. 7d ago First seen · 110 lines · 137 tokens per session scan A b5cc1d3d670b

Subscribe to this mod's changes

test-plan is a cursor rule published in the GitHub repository katalon-labs/true-skills (7 stars, last pushed 12d ago), licensed MIT. It adds 137 tokens to every session and 1,512 once invoked, about $0.0007 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-31.