Changelog

Added

• Postman collections for API test cases. When the requirements describe an API — endpoints as method + path, an OpenAPI/Swagger file, curl examples, response schemas, status codes, an auth section — Casely now exports the API-level cases as a runnable Postman v2.1 collection alongside the Excel file. It says so in the Phase 3 plan first, so the existing approval gate covers it and nobody receives an artefact they didn't ask for.
• scripts/build_postman_collection.py — assembles per-case JSON request specs into the collection, an environment file holding every variable, and a README covering import, variables, the Collection Runner and a Newman command for CI. Assertions are generated from each case's expected result rather than hand-written, so a typo cannot turn a broken endpoint into a green run.
• Everything environment-specific becomes a variable. {{baseUrl}}, {{authToken}}, entity ids and test data land in the environment file with descriptions and empty values, secrets typed as secrets. The value a case is actually testing stays literal — parameterizing amount: 50001 would hide what the case checks.
• The build refuses unsafe or unrunnable input, the way the Excel exporter already did: a hardcoded host, anything shaped like a JWT or a secret key, a duplicated case id, a missing or invalid field. It names the file and exits non-zero rather than writing a collection that points at production or carries someone's token.
• references/api_collection.md — the signals that decide whether a collection is worth building, the request spec format, request chaining, and the variable and assertion rules.
• Evals extended with the plan-time offer, the no-endpoints case, and the variable rules.

Changed

• Phase 5 is now "Export": Excel always, the Postman collection when the plan promised one.
• Casely never guesses an endpoint from a described flow. A spec that names screens but no paths gets a request for the API docs instead of a collection that 404s on first run.

Casely no longer runs on slash commands. Attach your requirements (and, ideally, an example of test cases your team already writes), say what you need, and Casely handles the rest in one conversation — across Claude Code, claude.ai, and the Claude desktop app.

What changed

• No more commands. /init, /parse, /style, /plan, /generate, /export are gone. Attach files, describe the task, done.
• One approval gate. Casely always stops on the test plan and waits for your OK before writing a single test case.
• Real test design. Equivalence partitioning, boundary values, decision tables, state transitions, error guessing — not a restatement of the requirements as cases.
• Reports gaps in your spec — untestable wording, contradictions, missing error paths — alongside the plan.
• One Excel file, one row per case. Matches how TestRail, Qase, Zephyr and Xray actually import, instead of forty separate files.
• No parser dependency. Claude reads PDF/DOCX/XLSX natively — nothing to install.

Full history in CHANGELOG.md.

Stop manually writing test cases. Claude skill: Requirements → Test Plan → + 100 Test Cases (Manual & Auto) in 5min 🚀

Writing test suites from scratch is the most tedious part of QA. So I built Casely — a virtual QA Lead for Claude (Anthropic Skills).

It doesn't just "hallucinate" tests. It follows a rigorous pipeline: Parse: Deep-reads PDF/DOCX into clean Markdown (using Docling).

Style: Analyzes your test cases to mimic your specific style/columns.

Plan: Segregates requirements into logical modules.

Generate: Cranks out 100+ atomic test cases.

Export: Spits out a .xlsx file ready for TestRail/Xray.

Real stats: 27-page requirement doc → 87 structured cases in 2:32 min.