test-cases-authoring

Generates test-cases.md catalogs grouping success and exception test cases by user story.

Updated Jan 28, 2024
One-click install
npx skills add https://github.com/Thiago-Cruz-eng/KrockSide --skill test-cases-authoring-thiago-cruz-eng
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: test-cases-authoring
Source: https://github.com/Thiago-Cruz-eng/KrockSide/tree/main/.agents/skills/test-cases-authoring
Command: npx skills add https://github.com/Thiago-Cruz-eng/KrockSide --skill test-cases-authoring-thiago-cruz-eng

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes assets (resource) components.

What problem does it solve? Work units often ship without a systematic catalog of test cases, leaving manual validation ad hoc and automated E2E tests without a traceable source. This Skill standardizes how a test-cases.md is authored so every acceptance criterion and declared exception maps to a stable, classified test case. ## Core Features & Use Cases - Story-grouped coverage: Organizes test cases by user story from spec.md, covering both success paths and exceptions (access denied, validation errors, idempotency, side effects). - Stable ids and classification: Assigns permanent TC-<n> ids and mandatory/recommended classifications so implementation tasks and E2E tests can reference cases without renumbering. - Stack-specific templates: Ships backend and frontend skeleton templates covering endpoint calls, database/queue/cache assertions, and full UI navigation paths from a known entry point. - Use Case: After finishing spec.md and plan.md for a feature, invoke this Skill to produce a test-cases.md that doubles as the manual validation runbook and the source for Playwright E2E tests. ## Quick Start Ask the agent to author the test-cases.md for the current work unit using the test-cases-authoring standard, based on the existing spec.md and plan.md.

Frequently Asked Questions about test-cases-authoring

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write a test-cases.md for a work unit?

Group test cases by user story from spec.md, assign each a stable TC-<n> id with a mandatory or recommended classification, and close every case with an Expected line. Cover both success paths and declared exceptions without inventing behavior not in the spec or plan.

When should test cases be authored in a spec-driven workflow?

Author test-cases.md in its own sub-phase after spec.md and plan.md are complete and before tasks.md is written. It consumes both artifacts and must never be produced as part of authoring the spec or plan itself.

What is the difference between mandatory and recommended test cases?

Mandatory cases cover core paths or critical failures that must pass for the unit to be acceptable. Recommended cases cover relevant but non-blocking edges such as secondary variations or cosmetic messages, validated when time or automation allows.

Can a test case introduce behavior not in the spec?

No. The test-cases.md is a derived catalog, not a source of truth. If covering a flow requires a fact missing from spec.md or plan.md, escalate it as a divergence gap instead of inventing the detail.

Why must frontend test cases start from a known entry point?

Cases that begin mid-screen, such as inside an already-open panel, are not reproducible and cannot map to an automated E2E test. Each case must spell out the full navigation path from a route or app home before the action under test.