Critical Thinking Mindset — Apply critical thinking, sequential thinking. Every claim needs traced proof, confidence >80% to act. Anti-hallucination: Never present guess as fact — cite sources for every claim, admit uncertainty freely, self-check output for errors, cross-reference independently, stay skeptical of own confidence — certainty without evidence root of all hallucination.

AI Mistake Prevention — Failure modes to avoid on every task:

• Check downstream references before deleting. Deleting components causes documentation and code staleness cascades. Map all referencing files before removal.
• Verify AI-generated content against actual code. AI hallucinates APIs, class names, and method signatures. Always grep to confirm existence before documenting or referencing.
• Trace full dependency chain after edits. Changing a definition misses downstream variables and consumers derived from it. Always trace the full chain.
• Trace ALL code paths when verifying correctness. Confirming code exists is not confirming it executes. Always trace early exits, error branches, and conditional skips — not just happy path.
• When debugging, ask "whose responsibility?" before fixing. Trace whether bug is in caller (wrong data) or callee (wrong handling). Fix at responsible layer — never patch symptom site.
• Assume existing values are intentional — ask WHY before changing. Before changing any constant, limit, flag, or pattern: read comments, check git blame, examine surrounding code.
• Verify ALL affected outputs, not just the first. Changes touching multiple stacks require verifying EVERY output. One green check is not all green checks.
• Holistic-first debugging — resist nearest-attention trap. When investigating any failure, list EVERY precondition first (config, env vars, DB names, endpoints, DI registrations, data preconditions), then verify each against evidence before forming any code-layer hypothesis.
• Surgical changes — apply the diff test. Bug fix: every changed line must trace directly to the bug. Don't restyle or improve adjacent code. Enhancement task: implement improvements AND announce them explicitly.
• Surface ambiguity before coding — don't pick silently. If request has multiple interpretations, present each with effort estimate and ask. Never assume all-records, file-based, or more complex path.

Skill: e2e-test

Category: [Testing] Trigger: e2e test, e2e from recording, generate e2e, playwright test, cypress test, selenium test, webdriver, puppeteer

Generate and maintain E2E tests using the project's configured testing framework.

• docs/test-specs/

  — Test specifications by module (read existing TCs for E2E scenario coverage; match TC codes to E2E test implementations)

Be skeptical. Apply critical thinking, sequential thinking. Every claim needs traced proof, confidence percentages (Idea should be more than 80%).

⚠️ MANDATORY: Read Project E2E Reference (FIRST)

BEFORE ANY E2E WORK, you MUST ATTENTION:

# 1. Read project-specific E2E patterns (REQUIRED)
head -100 docs/project-reference/e2e-test-reference.md

# 2. Read project config for framework, paths, commands
grep -A 50 '"e2eTesting"' docs/project-config.json

# 3. Find TC codes you need to implement
grep -r "TC-.*-E2E-" docs/test-specs/ docs/business-features/

The

e2eTesting

docs/project-config.json

• Framework, language, paths, run commands, TC code format
• Project-specific best practices and entry points

When investigating/fixing E2E failures, update

docs/project-reference/e2e-test-reference.md

• docs/project-reference/domain-entities-reference.md

  — Domain entity catalog, relationships, cross-service sync (read when task involves business entities/models)

Framework Detection (SECOND STEP)

Detect the project's E2E stack before generating tests:

# TypeScript/JavaScript
grep -l "playwright\|cypress\|selenium\|webdriver" package.json 2>/dev/null
ls playwright.config.* cypress.config.* wdio.conf.* 2>/dev/null

# C# .NET
grep -r "Selenium.WebDriver\|Microsoft.Playwright" **/*.csproj 2>/dev/null

npx playwright test

npx cypress run

npx wdio run

dotnet test

Workflow Modes

from-recording

update-ui

from-changes

from-spec

Core Principles

1. TC Code Traceability (MANDATORY)

Every E2E test MUST ATTENTION have:

• TC code in test name:

  TC-{MODULE}-E2E-{NNN}

• Tag/trait linking to spec
• Comment linking to feature doc

// TypeScript
test('TC-LR-E2E-001: Submit leave request', async () => { ... });

// C# .NET
[Fact]
[Trait("TC", "TC-LR-E2E-001")]
public async Task SubmitLeaveRequest() { ... }

2. Page Object Model

All frameworks should use Page Object pattern:

• Encapsulate page locators in page class
• Methods represent user actions
• Assertions in test file, not page object

3. Selector Strategy (Priority Order)

1. Semantic classes — BEM (

   .block__element

   ), component classes
2. Data attributes —

   [data-testid]

   ,

   [data-cy]

   ,

   [data-test]

3. ARIA/Role —

   role=button

   ,

   aria-label

4. Text content — Visible user text (last resort)

AVOID: Generated classes (

.ng-star-inserted

.MuiButton-root

:nth-child

4. Unique Test Data

Tests must generate unique data to be repeatable:

• Append GUIDs/timestamps to test data
• Don't depend on specific database state
• Don't clean up data (creates side effects)

5. Preconditions Documentation

Document what must exist before test runs:

• System: Infrastructure running, APIs healthy
• Data: Seed data exists (users, companies)
• Feature: Configurations complete

Steps

1. Detect framework from project files
2. Read project E2E docs for conventions and patterns
3. Load test specs with TC codes from feature docs
4. Generate/update tests following Page Object pattern
5. Run tests using project's configured commands
6. Update e2e-test-reference.md with any learnings

Output

Report:

• Files created/modified
• TC codes covered
• Run command to execute tests
• Any preconditions or setup needed

Workflow Recommendation

MANDATORY IMPORTANT MUST ATTENTION — NO EXCEPTIONS: If you are NOT already in a workflow, you MUST ATTENTION use

AskUserQuestion

to ask the user. Do NOT judge task complexity or decide this is "simple enough to skip" — the user decides whether to use a workflow, not you:

1. Activate

   e2e-from-changes

   workflow (Recommended) — scout → e2e-test → test → watzup
2. Execute

   /e2e-test

   directly — run this skill standalone

Closing Reminders

• MANDATORY IMPORTANT MUST ATTENTION break work into small todo tasks using

  TaskCreate

  BEFORE starting
• MANDATORY IMPORTANT MUST ATTENTION search codebase for 3+ similar patterns before creating new code
• MANDATORY IMPORTANT MUST ATTENTION cite

  file:line

  evidence for every claim (confidence >80% to act)
• MANDATORY IMPORTANT MUST ATTENTION add a final review todo task to verify work quality <!-- SYNC:critical-thinking-mindset:reminder -->
• MUST ATTENTION apply critical thinking — every claim needs traced proof, confidence >80% to act. Anti-hallucination: never present guess as fact. <!-- /SYNC:critical-thinking-mindset:reminder --> <!-- SYNC:ai-mistake-prevention:reminder -->
• MUST ATTENTION apply AI mistake prevention — holistic-first debugging, fix at responsible layer, surface ambiguity before coding, re-read files after compaction. <!-- /SYNC:ai-mistake-prevention:reminder -->