business-requirement-testcase-generator

name: business-requirement-testcase-generator description: Generate business-domain manual QA test cases from a user-provided business domain, PRD, TRD, design links, repository knowledge-base content, and manual-case rules. Use when the user asks to create, understand, organize, or write manual test cases for any business requirement, especially prompts like "帮我生成需求xxx的测试用例", "业务域：xxx", "阅读PRD/TRD/设计稿并输出测试用例", or "写入测试用例到Google Sheet".

Business Requirement Testcase Generator

Purpose

Use this skill to run an end-to-end manual test-case workflow for any business domain:

1. Identify the business domain from the user input.
2. Read business knowledge for that domain from the local or remote knowledge base.
3. Read requirement artifacts such as PRD, TRD, design files, and repository changes.
4. Explain the requirement back to the user.
5. Create a requirement-understanding Markdown document.
6. Learn the manual test-case writing rules.
7. Generate scoped manual test cases.
8. Write cases to the target spreadsheet when permitted, or create a local fallback when external writes are blocked.

Default language for user-facing feedback and generated business documents is Chinese unless the user asks otherwise.

Expected User Prompt

Typical invocation:

帮我生成需求xxx的测试用例，以下是需求信息：
业务域：xxx
PRD：链接（如有）
TRD：链接（如有）
设计稿：链接（如有）
生成位置：sheet文档链接

Accept partial inputs. Treat 业务域 as the primary key for finding related business knowledge. If 业务域 is missing and cannot be inferred from the requirement title, Jira key, PRD title, or repo path, ask one concise question before generating cases. If the generation scope or output destination is missing, infer when safe and state the assumption.

Source Reading

Use tool_search to discover MCP tools before accessing deferred connectors. Prefer connector/MCP reads over web search for internal systems.

• Confluence PRD/TRD: use Atlassian/Confluence MCP tools. Read page title, version, Jira key, anchors/headings, tables, images, and comments only when relevant. If a page is too large or truncated, use Confluence search with requirement-specific keywords and headings to recover missing sections.
• Google Docs: use Google Docs MCP tools. Preserve headings, tables, comments, and embedded links that affect requirements.
• Google Sheets: use Google Sheets MCP tools. Inspect spreadsheet title, sheet names, headers, and existing rows before writing.
• Figma/design links: use Figma MCP tools when available. Identify frames, flows, visible states, component behavior, error states, and permission/empty/loading states. Use screenshots only as supporting evidence.
• GitLab/GitHub/repository links: use the relevant MCP or repository tools to inspect MR descriptions, diffs, config changes, API changes, migrations, and test-impacting implementation details.
• Remote business knowledge base: use the provided 业务域 to search the local checkout or remote knowledge-base repository. Search by exact domain name, common aliases, product/module names, Jira project keys, PRD title keywords, and path fragments.

Do not invent inaccessible source content. If a source cannot be opened, tell the user what is missing and continue only from available materials.

Manual Case Rule Location

Do not require manual_case_rule.mdc to live in the skill directory. Treat the rule file as project or organization knowledge because columns, tags, priorities, creators, regions, and automation conventions may differ by team.

Use this lookup priority:

1. Rule file path or link explicitly provided by the user.
2. manual_case_rule.mdc in the current working repo, repo root, or nearby parent directories.
3. Rule docs in the requested business-domain knowledge-base folder.
4. Rule docs in the remote knowledge-base repository, searched by manual_case_rule, case_rule, 测试用例规则, 用例规则, and the business-domain name.
5. A bundled skill reference only if the organization keeps a stable default template inside this skill.

If multiple rule files are found, prefer the one closest to the target project or business domain. Ask the user only when two candidates conflict in required columns or required tags.

Business-Domain Knowledge Lookup

When 业务域：xxx is provided:

1. Search the current repo first with rg --files and rg -n "<业务域|aliases|module keywords>".
2. If the user provides a remote knowledge-base repository or connector-backed repo, use the relevant MCP or repository tools to search it.
3. Prefer business architecture docs, module docs, glossary docs, process docs, permission/config docs, and previous requirement-understanding docs.
4. Read focused files instead of bulk-loading the whole repository.
5. Capture domain boundaries, core entities, entity relationships, upstream/downstream modules, market/region differences, permissions, configs, and historical rules.

If multiple domains match the same name, use the requirement source context to disambiguate. Ask only when ambiguity would materially change test coverage.

Workflow

Step 1: Build Business Context

Briefly read business knowledge for the requested domain before analyzing the requirement. Capture:

• Business domain and module boundaries.
• Core entities and relationships.
• Market, region, tenant, role, or permission differences.
• Upstream/downstream dependencies and data flow.
• Existing rules that may constrain the new requirement.
• Known high-risk regression areas.

Send a short feedback message after this step. If the user explicitly asked for a staged workflow, stop and wait for the next instruction.

Step 2: Explain the Requirement

Read the PRD/TRD/design/repository artifacts and explain the requirement in detail. Include:

• Background, objective, business value, and target users.
• In-scope and out-of-scope modules.
• Entry points, filters, pages, tabs, buttons, tables, forms, uploads, exports, logs, permissions, and configuration.
• Main flow, alternate flow, exception flow, boundary rules, data validation, state changes, and scheduled/async behavior.
• Region, market, tenant, role, and feature-switch differences.
• Cross-module impacts and downstream effects.
• Test focus, risk points, and open questions.

Keep the explanation grounded in the cited documents and clearly label assumptions.

Step 3: Create Requirement Understanding Markdown

Create a .md requirement-understanding document in the current repo or the closest relevant knowledge-base folder. Use a deterministic filename that includes the business domain and Jira key or requirement name when known.

Recommended sections:

• Document information and source links.
• Business domain and knowledge-base sources.
• Business background and goals.
• Glossary.
• Business architecture and data flow.
• Module scope.
• Detailed functional requirements by page/module/action.
• Permissions, configs, region differences, and compatibility rules.
• Data import/export/log behavior.
• Exception and validation rules.
• Test focus and risk points.
• Open questions.

Use apply_patch for manual file creation or edits. Send the file path to the user after creation. If the user requested staged execution, stop and wait.

Step 4: Learn Manual Case Rules

Locate and read the manual case rule document, usually manual_case_rule.mdc, unless the user provides another rule file. Extract:

• Required spreadsheet columns and column order.
• Required fields.
• Step and expected-result writing style.
• Priority definitions.
• Type, region, Jira key, tag, creator, automation-type conventions.
• Any project-specific restrictions or examples.

If no rule file is available, ask for it before generating final cases. Do not silently substitute unrelated rules. If a bundled default rule exists, use it only as a clearly stated fallback.

Step 5: Generate Test Cases

Generate cases only for the user-requested requirement scope. If the scope is a specific part, module, page, tab, API, or flow, exclude unrelated modules even if they appear in the PRD.

Coverage checklist:

• Normal user flows and happy paths.
• Required filters, cascades, defaults, sorting, frozen columns/rows, pagination, search, refresh, and display formatting.
• Create, edit, delete, upload, import, export, log, detail view, batch action, approval action, and single-record action behavior as applicable.
• Positive and negative validations, required fields, nonexistent values, duplicate values, conflicts, overlap checks, boundary values, time windows, date ranges, empty data, and partial success.
• Permissions, configs, feature switches, market/region/tenant differences, data-access scope, and role-specific visibility.
• State transitions, past/present/future rules, disabled/read-only states, hidden/excluded data, and retry/reversal flows.
• API, backend job, event, message queue, cache, and data migration behavior when the TRD or code indicates them.
• Cross-module data effects, downstream consumption, and audit/log expectations.
• Compatibility with existing data and regression risks.

Each case should be independently executable and include clear test data assumptions. Avoid vague steps such as "verify normally"; specify menu path, action, input, and expected result.

Step 6: Write to Spreadsheet or Local Fallback

When the user provides a Google Sheet link:

1. Read spreadsheet metadata and headers first.
2. Map generated fields to the sheet headers exactly.
3. Preserve existing rows; append or update only the intended range.
4. Write in small batches using Google Sheets MCP tools.
5. Verify by reading back the target range.

External write rules:

• Only write after the user has provided the sheet destination and given permission.
• If a tool or policy blocks the external write, stop trying to write that destination. Do not retry through another connector or workaround.
• When external writing is blocked, create a local .md or .csv fallback containing all unwritten cases, tell the user which rows were written, which cases remain local, and where the fallback file is.

Step 7: Feedback and Handoff

After each major step, report:

• What business domain was used.
• What sources were read.
• What artifact was produced or updated.
• Case count and target scope.
• Sheet range written or local fallback path.
• Any blocked access, assumptions, or open questions.

If the user explicitly breaks the workflow into tasks and asks to wait after each task, wait for the next instruction after each feedback message.

Case Field Guidance

Follow the rule document exactly when it conflicts with this guidance. Common fields:

• id(update is needed): leave blank or use temporary sequential IDs only if the target sheet expects them.
• Business hierarchy columns: fill with the business domain, product/module, requirement module, page, tab, or action according to the target sheet headers.
• 用例名称: concise, behavior-oriented, unique.
• 前置条件: include role, permissions, region/market/tenant, config, existing data, and time/date setup.
• 用例步骤: numbered actionable steps with paths, inputs, and operations.
• 预期结果: numbered results aligned to the steps.
• 优先级: assign P0/P1/P2 by business criticality and risk, not evenly by habit.
• Type: use FE/API/Integration/Backend or the project convention from the rule file.
• Region: use All unless the case is market-specific.
• Jira key: use the requirement Jira key when available.
• 用例tag: include required tags from the rule file and useful business/module tags.
• 备注: use only for assumptions, source references, or special data setup.

Quality Bar

Before final response:

• Confirm the generated cases cover every in-scope PRD/TRD/design behavior.
• Check that negative, permission, boundary, region, integration, and regression cases are present.
• Check column count and order against the target sheet.
• Verify generated Markdown/CSV files exist if created.
• Verify sheet writes by reading back when tool policy permits.
• Clearly state any source that could not be accessed.