← ClaudeAtlas

userflow-to-testcaseslisted

Author a complete test-case suite FROM a user-flow or feature document — a PDF (preferred), markdown, doc, text, or screenshots of an app's flows — and output an importer-ready CSV. Models the flow as state machines (actor + resource), then writes cases per transition with cross-flow downstream impact, a matrix, end-to-end journeys, and a security/abuse (VAPT) pass; tags each case Type (POS/NEG/VAPT), Outcome (TN/TP/FP/FN!) and Priority with severity reasoning. Its CSV feeds testcase-importer (flow → CSV → console). Use whenever someone has a flow/spec/guide and wants QA test cases GENERATED from it — e.g. "write test cases from this user-flow PDF", "generate a test suite from this feature spec", "cover this checkout/onboarding flow end to end", "model the states in this flow and test them". Do NOT use to import/reformat EXISTING test cases (that's testcase-importer), to generate code-level unit/integration tests (pytest/jest), to create test fixtures or seed data, or to render/edit the console.
labspangaea/pangaealabs-claude-plugins-marketplace · ★ 0 · Testing & QA · score 62
Install: claude install-skill labspangaea/pangaealabs-claude-plugins-marketplace
# userflow-to-testcases Turn a document that describes **how an app works** into a thorough, importer-ready test-case CSV. This skill **authors new cases** from a flow; its sibling `testcase-importer` **imports existing** cases. They chain: `flow → [this skill] → cases CSV → [testcase-importer] → console`. The authoring method (state modeling, per-transition cases, matrix, E2E, VAPT, the tag taxonomy, severity rules, ID scheme, and the importer-ready output schema) lives in `references/methodology.md`. **Read it before authoring** — it's the heart of this skill. ## Workflow ### 1 — Read the source Read the flow document in full. The `Read` tool renders PDFs (preferred input), images, and markdown/text. Understand every flow, screen, and state transition described, plus the concrete data shown (IDs, amounts, formats) — you'll reuse real values, never fabricate. ### 2 — Model the states Per `references/methodology.md` §1: extract the actor/account machine and the resource machine, code the states, and map each flow/step to a transition. Where the document is ambiguous (what does "inactive" mean? what deactivates a resource? is zero-balance distinct?), pick the most defensible reading, **note it as an assumption**, and keep a running list of open questions — you can't ask the user mid-run. ### 3 — Author comprehensively Following `references/methodology.md` §2–6, write: - per-transition cases (happy / negative / edge), each stating its **downstream impact**; - the **actor×