Tdd

Skill jovd83/playwright-skill/documentation/test_cases/tdd

End-to-end Playwright skill pack for planning, authoring, debugging, documenting, and operationalizing test automation.

Install

npx -y skills add jovd83/playwright-skill --skill tdd

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Legacy Playwright-specific alias for TDD-style case documentation. Prefer the standalone `test-artifact-export-skill` skill for formatting approved test cases or building export-ready artifacts, and use this only when Playwright-local conventions must be preserved explicitly.

SKILL.md

2.2 KB, as published. Nobody here has run it

Playwright TDD Documentation

Use this skill when the user wants structured test-case specs rather than lightweight notes.

Output Contract

Produce one scenario document per test case with these fields:

title
description
test_suite
covered_requirement
preconditions
steps
execution_type
design_status
test_engineer
test_level
jira
test_script

Use a markdown step table with Step, Action, and Expected result.

Traceability Rules

Use repo-relative automation references such as tests/e2e/auth/login.spec.ts#AUTH-US02-user-login.
Keep requirement references explicit and stable.
If automation does not exist yet, say so instead of inventing a script link.

Organization Rules

Prefer feature- or story-based folders when the user wants a persistent test-doc tree.
Keep one scenario per file when the docs are meant to be maintained over time.
Name files after the behavior they describe, not after arbitrary numbering alone.

Writing Rules

Preconditions should describe the meaningful starting state, not boilerplate every test shares implicitly.
Steps should reflect meaningful user or system actions, not every low-level click.
Expected results should assert the requirement, not generic success language.