agentleFS
naddrzznaddrzz/nalarupa/.github/claude-skills/bmad-qa-generate-e2e-tests/SKILL.md

bmad-qa-generate-e2e-tests

Skill8 starsChanged 27 days agoMITView on GitHub

Generate automated API and end-to-end tests for implemented features. Use when the user says "create qa automated tests for [feature]"

24 other projects use a version of this, 23 of them edited.

Adopted by

Most recently taken up by

Used with

Projects with it also use bmad-dev-auto, bmad-checkpoint-preview and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • areesh-aliSkill

    bmad-dev-auto

    One iteration of an unattended development loop. Use when invoked by name.

    Also in 8 projects that use this

  • GauravRatnawatSkill

    bmad-checkpoint-preview

    LLM-assisted human-in-the-loop review. Make sense of a change, focus attention where it matters, test. Use when the user says "checkpoint", "human review", or "walk me through this change".

    Also in 15 projects that use this

  • 2233adminSkill

    bmad-editorial-review

    Deprecated — forwards to bmad-review.

    Also in 6 projects that use this

  • 2233adminSkill

    bmad-review-verification-gap

    Deprecated — forwards to bmad-review.

    Also in 6 projects that use this

  • DogaOztuzunSkill

    bmad-agent-architect

    System architect and technical design leader. Use when the user asks to talk to Winston or requests the architect.

    Also in 21 projects that use this

  • DogaOztuzunSkill

    bmad-agent-pm

    Product manager for PRD creation and requirements discovery. Use when the user asks to talk to John or requests the product manager.

    Also in 21 projects that use this

  • +2 more from DogaOztuzun

The file

Show its rules and text

We split this skill into the rules it gives an agent

19 rules. 16 are common, 0 are distinctive, and 3 are very specific to this project.

  • 16

    Common

    Most of the 24 edited versions we read keep these.

  • 0

    Distinctive

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Treat every entry in {workflow.persistent_facts} as foundational context you carry for the rest of the workflow run.

    line 41
  2. Common:

    Check project for existing test framework:

    line 73
  3. Very specific:

    Look for package.json dependencies (playwright, jest, vitest, cypress, etc.)

    line 75
  4. Common:

    Check for existing test files to understand patterns

    line 76
  5. Common:

    Use whatever test framework the project already has

    line 77
  6. Common:

    If no framework exists:

    line 78
  7. Common:

    Search online for current recommended test framework for that stack

    line 80
  8. Common:

    Ask user what to test:

    line 85
  9. Common:

    Use project's existing test framework patterns

    line 98
  10. Common:

    Test user workflows end-to-end

    line 104
  11. Common:

    Use semantic locators (roles, labels, text)

    line 105
  12. Common:

    Keep tests linear and simple

    line 108
  13. Common:

    Follow project's existing test patterns

    line 109
  14. Common:

    If failures occur, fix them immediately.

    line 115
  15. Common:

    Use standard test framework APIs

    line 145
  16. Common:

    Write readable, maintainable tests

    line 147
  17. Common:

    Run tests to verify they pass

    line 148
  18. Common:

    If the project needs:

    line 158
  19. Very specific:

    If the resolved workflow.on_complete is non-empty, follow it as the final terminal instruction before exiting.

    line 178

“Common” is measured: kept by at least 6 in 10 of the 24 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

QA Generate E2E Tests Workflow

Goal: Generate automated API and E2E tests for implemented code.

Your Role: You are a QA automation engineer. You generate tests ONLY — no code review or story validation (use the bmad-code-review skill for that).

Conventions

  • Bare paths (e.g. checklist.md) resolve from the skill root.
  • {skill-root} resolves to this skill's installed directory (where customize.toml lives).
  • {project-root} is the nearest folder containing _bmad/, starting at the project working directory and moving up through its parents.
  • {skill-name} resolves to the skill directory's basename.

On Activation

Step 1: Resolve the Workflow Block

Run: uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --project-root {project-root} --key workflow

If the script is not found, BMad is not set up here. Offer to run the bmad skill's setup, installing bmad first if you do not have it (npx skills add bmad-code-org/BMAD-METHOD --skill bmad), then run the command again.

If it fails for any other reason, resolve the workflow block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:

  1. {skill-root}/customize.toml — defaults
  2. {project-root}/_bmad/custom/{skill-name}.toml — team overrides
  3. {project-root}/_bmad/custom/{skill-name}.user.toml — personal overrides

Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by code or id replace matching entries and append new entries, and all other arrays append.

Step 2: Execute Prepend Steps

Execute each entry in {workflow.activation_steps_prepend} in order before proceeding.

Step 3: Load Persistent Facts

Treat every entry in {workflow.persistent_facts} as foundational context you carry for the rest of the workflow run. Entries prefixed file: are paths or globs under {project-root} — load the referenced contents as facts. All other entries are facts verbatim.

Step 4: Load Config

Run: uv run {project-root}/_bmad/scripts/resolve_config.py --project-root {project-root} --key core.project_name --key core.output_folder --key core.active_initiative

  • Script not found, or no output_folder: BMad is not set up here. Offer to run the bmad skill's setup, installing bmad first if you do not have it (npx skills add bmad-code-org/BMAD-METHOD --skill bmad), then run the command again.
  • No active_initiative: drop /{active_initiative} from the paths below.
  • date as system-generated current datetime
  • YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style

Step 5: Greet the User

Greet the user.

Step 6: Execute Append Steps

Execute each entry in {workflow.activation_steps_append} in order.

Activation is complete. If activation_steps_prepend or activation_steps_append were non-empty, confirm every entry was executed in order before proceeding. Do not begin the main workflow until all activation steps have been completed.

Paths

  • test_dir = {project-root}/tests
  • source_dir = {project-root}
  • default_output_file = {output_folder}/{active_initiative}/test-summary-{slug}/test-summary-{slug}.md, {slug} naming the feature tested

Execution

Step 0: Detect Test Framework

Check project for existing test framework:

  • Look for package.json dependencies (playwright, jest, vitest, cypress, etc.)
  • Check for existing test files to understand patterns
  • Use whatever test framework the project already has
  • If no framework exists:
    • Analyze source code to determine project type (React, Vue, Node API, etc.)
    • Search online for current recommended test framework for that stack
    • Suggest the meta framework and use it (or ask user to confirm)

Step 1: Identify Features

Ask user what to test:

  • Specific feature/component name
  • Directory to scan (e.g., src/components/)
  • Or auto-discover features in the codebase

Step 2: Generate API Tests (if applicable)

For API endpoints/services, generate tests that:

  • Test status codes (200, 400, 404, 500)
  • Validate response structure
  • Cover happy path + 1-2 error cases
  • Use project's existing test framework patterns

Step 3: Generate E2E Tests (if UI exists)

For UI features, generate tests that:

  • Test user workflows end-to-end
  • Use semantic locators (roles, labels, text)
  • Focus on user interactions (clicks, form fills, navigation)
  • Assert visible outcomes
  • Keep tests linear and simple
  • Follow project's existing test patterns

Step 4: Run Tests

Execute tests to verify they pass (use project's test command).

If failures occur, fix them immediately.

Step 5: Create Summary

Output markdown summary:

# Test Automation Summary

## Generated Tests

### API Tests
- [x] tests/api/endpoint.spec.ts - Endpoint validation

### E2E Tests
- [x] tests/e2e/feature.spec.ts - User workflow

## Coverage
- API endpoints: 5/10 covered
- UI features: 3/8 covered

## Next Steps
- Run tests in CI
- Add more edge cases as needed

Keep It Simple

Do:

  • Use standard test framework APIs
  • Focus on happy path + critical errors
  • Write readable, maintainable tests
  • Run tests to verify they pass

Avoid:

  • Complex fixture composition
  • Over-engineering
  • Unnecessary abstractions

For Advanced Features:

If the project needs:

  • Risk-based test strategy
  • Test design planning
  • Quality gates and NFR assessment
  • Comprehensive coverage analysis
  • Advanced testing patterns and utilities

Install Test Architect (TEA) module: https://bmad-code-org.github.io/bmad-method-test-architecture-enterprise/

Output

Save summary to: {default_output_file}

Done! Tests generated and verified. Validate against checklist.md.

On Complete

Run: uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --project-root {project-root} --key workflow.on_complete

If the resolved workflow.on_complete is non-empty, follow it as the final terminal instruction before exiting.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.