qa-test-planner

Overview of qa-test-planner skill

What qa-test-planner does

qa-test-planner is a QA documentation and planning skill for turning a feature, release, bug, or UI surface into structured testing outputs. Its core jobs are to generate test plans, manual test cases, regression suites, Figma-based design validation notes, and bug reports in a repeatable format.

Who should use qa-test-planner

This skill fits QA engineers, product-minded testers, engineering leads, and teams that need clearer acceptance coverage without inventing templates from scratch each time. It is especially useful when you already know the feature or change set, but need disciplined test artifacts fast.

Best job-to-be-done

The real value of qa-test-planner is not “write QA docs.” It is: convert incomplete feature context into testable scope, prioritized scenarios, reproducible steps, and consistent documentation that other humans can actually execute.

Why users pick this over a generic prompt

Compared with a normal “write me some test cases” prompt, the qa-test-planner skill gives you:

• explicit activation and task framing
• built-in output patterns for plans, cases, regression suites, and bug reports
• stronger QA structure around preconditions, expected results, priorities, and edge cases
• reference material for regression strategy, Figma validation, and templates
• helper scripts that show the expected information model

Most important differentiators

The strongest differentiators are practical rather than novel:

• support for both planning and execution-ready manual test case writing
• dedicated regression guidance, including smoke, targeted, and full regression thinking
• Figma validation workflow for acceptance/UI checks
• structured bug report templates that improve reproducibility

When qa-test-planner is a poor fit

Skip qa-test-planner for Acceptance Testing if you need automated test generation, code-level test harness creation, or deep environment-specific QA orchestration out of the box. This skill is strongest for manual QA artifacts and structured analysis, not end-to-end automation code.

How to Use qa-test-planner skill

Install qa-test-planner in your skills environment

If you use the shared repository installer pattern, install with:

npx skills add softaworks/agent-toolkit --skill qa-test-planner

The repository marks this as an explicit-trigger skill, so installation alone is not enough; you must call it by name when you want it used.

Trigger qa-test-planner explicitly

Use one of the explicit forms shown in the repository:

• /qa-test-planner
• qa-test-planner
• use the skill qa-test-planner

That matters because the skill is not designed to activate implicitly from vague QA wording alone.

Start with the right files first

For a quick, high-signal reading path, open these in order:

1. skills/qa-test-planner/SKILL.md
2. skills/qa-test-planner/README.md
3. skills/qa-test-planner/references/test_case_templates.md
4. skills/qa-test-planner/references/regression_testing.md
5. skills/qa-test-planner/references/bug_report_templates.md
6. skills/qa-test-planner/references/figma_validation.md

If you want to understand the exact fields the skill expects, the shell scripts are also useful:

• scripts/generate_test_cases.sh
• scripts/create_bug_report.sh

Choose the deliverable before you prompt

qa-test-planner usage works best when you ask for one concrete output type at a time:

• test plan
• manual test cases
• regression suite
• Figma validation
• bug report

A single mixed request often produces shallow coverage. Better pattern: generate the plan first, then derive cases, then build a regression subset.

What input qa-test-planner needs

The skill performs much better when you provide:

• feature name and business goal
• user roles involved
• acceptance criteria or expected behavior
• environment and platform scope
• known integrations or dependencies
• risk areas
• relevant URLs, screenshots, or Figma links
• release type: new feature, bug fix, refactor, hotfix

Without that, the output will still be formatted well, but may miss real edge cases or overgeneralize.

Turn a rough request into a strong prompt

Weak prompt:

Generate test cases for checkout.

Stronger prompt:

Use qa-test-planner to generate manual test cases for guest and logged-in checkout on web. Cover shipping address, coupon application, payment failure, order confirmation, and inventory edge cases. Environment: staging. Browser scope: Chrome and Safari. Include preconditions, test data, step-by-step expected results, and a priority for each case.

Why this works better:

• narrower feature boundary
• explicit user modes
• known risky flows
• environment and browser scope
• requested output structure

Example prompt for acceptance testing

For qa-test-planner for Acceptance Testing, ask for business-verifiable scenarios, not only UI clicks:

Use qa-test-planner to create an acceptance test plan for the user authentication feature. Include happy path, invalid credentials, password reset, session timeout, remember-me behavior, account lockout, and role-based redirect behavior. Mark which scenarios are critical for release sign-off.

This pushes the output toward acceptance criteria coverage instead of generic functional checks.

Example prompt for regression planning

A good regression request should define the change surface and release risk:

Use qa-test-planner to build a targeted regression suite for the payment module after changes to card tokenization and retry logic. Separate smoke tests from deeper regression. Prioritize revenue-impacting paths first and call out dependencies on tax, order summary, and email confirmation.

This helps the skill produce execution order and sensible prioritization rather than a flat list.

Example prompt for bug report creation

When using the bug-report side of the skill, include observed facts:

Use qa-test-planner to create a bug report. Issue: on Safari 17, the signup form clears all inputs after submitting with one invalid field. Environment: staging, macOS 14. Repro rate: 4/5. Expected: only the invalid field should be highlighted and valid inputs preserved. Include severity, priority suggestion, repro steps, and evidence checklist.

That aligns closely with the repository template and yields a report another engineer can act on.

How Figma validation works in practice

The skill includes a Figma MCP-oriented workflow, but it assumes prerequisites:

• Figma MCP server configured
• access to the design file
• usable Figma URL

In practice, provide both the design target and the implementation target. Example:

Use qa-test-planner to validate the login page against this Figma design: [URL]. Focus on spacing, typography, button states, error message styling, and responsive layout differences. Output a discrepancy list and convert failures into test cases.

If you do not have Figma MCP access configured, the design-validation portion is a bad fit.

Use the templates as output-quality checks

A practical qa-test-planner guide move is to compare the model output against the repository references:

• test_case_templates.md for missing preconditions or test data
• bug_report_templates.md for missing environment or repro details
• regression_testing.md for wrong suite scope
• figma_validation.md for weak comparison criteria

This is often faster than rerunning from scratch.

Suggested workflow for real teams

A reliable sequence is:

1. create a feature test plan
2. generate manual test cases for high-risk flows
3. extract a smoke or targeted regression set
4. run UI/design validation if applicable
5. write structured bug reports from failures

This staged approach gives better QA artifacts than asking the skill for “everything” in one pass.

qa-test-planner skill FAQ

Is qa-test-planner good for beginners?

Yes, if you already understand the feature under test. The templates and structure help newer QA contributors avoid missing basics like preconditions, expected results, priority, and environment details. It is less helpful if you need the skill to discover the product behavior for you.

Does qa-test-planner create automated tests?

Not primarily. The repository evidence points to manual test planning, regression structuring, Figma validation, and bug reporting. If your goal is Playwright, Cypress, or unit-test code generation, treat this as an upstream planning tool, not the final implementation layer.

What makes qa-test-planner better than a normal AI prompt?

The main gain is consistency. qa-test-planner is opinionated about output shape and QA best practices, so you spend less time reformatting or reminding the model to include preconditions, edge cases, environment details, and regression scope.

When should I not install qa-test-planner?

Do not prioritize qa-test-planner install if your team:

• only wants automated test code
• has no manual QA artifact workflow
• does not use structured bug reports
• does not need acceptance or regression planning
• cannot provide enough feature context for useful outputs

Is qa-test-planner only for UI testing?

No. It covers functional, integration-minded, and regression-oriented planning too. But its Figma validation support makes it especially attractive for UI-heavy acceptance workflows.

Can qa-test-planner fit Agile release work?

Yes. It is well suited to sprint-level acceptance planning, release regression scoping, and documenting bugs found during validation. It is less about full test management tooling and more about producing solid QA artifacts quickly.

How to Improve qa-test-planner skill

Give qa-test-planner narrower scope

The most common failure mode is asking for coverage that is too broad, such as “test the whole app.” Better: isolate one feature, one release, one role set, or one changed subsystem. Narrow scope increases realism and reduces checklist fluff.

Provide acceptance criteria, not just feature names

“Test login” is weak. “Test login with MFA, lockout after five failures, remembered session for 7 days, and redirect to original page after auth” gives the skill actual behavioral anchors. This is the fastest way to improve qa-test-planner usage.

Include concrete environments and constraints

Outputs improve when you specify:

• browser/device matrix
• staging vs production-like environment
• role permissions
• test data limits
• external dependencies
• release deadline or smoke-test time budget

This helps the skill decide what belongs in smoke, targeted regression, or full coverage.

Ask for risk-based prioritization

If you care about execution order, say so. Example:

Use qa-test-planner and prioritize by revenue impact, authentication risk, and production incident history.

Otherwise, you may get comprehensive cases without a useful order for real release pressure.

Separate happy path from edge cases

A strong prompt explicitly asks the skill to split:

• core acceptance scenarios
• negative tests
• boundary conditions
• cross-browser or responsive checks
• integration failure cases

That structure makes the output easier to execute and turn into regression assets.

Iterate using the reference files

After the first draft, tighten it by checking repository references:

• missing severity or repro data → references/bug_report_templates.md
• weak edge cases → references/test_case_templates.md
• poor regression selection → references/regression_testing.md
• vague design checks → references/figma_validation.md

This is the quickest way to improve result quality without rewriting your entire prompt.

Use the helper scripts as field checklists

The two shell scripts are useful even if you never run them. They reveal the practical data fields the maintainers consider necessary for good bug reports and test cases. If your prompt omits those fields, your output will usually be less actionable.

Common output issues to correct after first pass

Watch for these in qa-test-planner outputs:

• steps that are too generic to execute
• expected results that restate the action instead of the system response
• no preconditions or test data
• no priority or risk labeling
• regression suites that mix smoke and full regression without distinction
• bug reports missing exact environment and reproduction rate

These are usually fixable with one focused follow-up prompt.

Best follow-up prompt pattern

After the first output, refine instead of starting over:

Revise this qa-test-planner output. Add missing preconditions, explicit test data, browser coverage, and edge cases for invalid input, timeout, duplicate submission, and permission failure. Re-rank tests into P0/P1/P2 and separate smoke tests from full regression.

That kind of directed second pass typically produces much stronger QA documentation than a single broad request.