Agent skill
e2e-ui-execute
Implement UI E2E tests sequentially using Playwright MCP, stop on bug discovery. Use after e2e-ui-research to implement the planned test scenarios.
Install this agent skill to your Project
npx add-skill https://github.com/majiayu000/claude-skill-registry/tree/main/skills/other/e2e-ui-execute
SKILL.md
UI E2E Test Implementation Command
User Input
$ARGUMENTS
Extract test number (if specified) and consider any additional context from user input (if not empty).
Overview
-
Check Prerequisites:
- Verify
docs/e2e-ui/test-targets.mdexists (English version, for AI) - If not exists ERROR: "Please run /e2e-ui:research first"
- Verify
-
Read Project Configuration:
- Read
playwright.config.ts(or.js):- Extract test directory from
testDirortestMatch - Extract base URL from
webServer.urloruse.baseURL
- Extract test directory from
- Read
package.json(in same directory):- Detect framework from dependencies:
next,react,vue,svelte, etc.
- Detect framework from dependencies:
- Fallback: If playwright.config not found, ask user for test directory and base URL
- Read
-
Load Test Targets:
- Read test scenarios from document
- Extract test number from $ARGUMENTS (if provided)
- Identify execution order
-
Execute Tests Sequentially:
- For each test scenario (in order): a. Manual Testing Phase: Verify behavior with Playwright MCP b. Bug Detection: Check for issues c. Bug Handling: If bug found, create bilingual bug report (ko.md + md) and continue d. Code Writing Phase: Write Playwright test code if passed (skip if bug) e. Progress Reporting: Update summary document
-
Generate Documentation:
- Create
docs/e2e-ui/summary-test-N.mdfor each completed test - Create
docs/e2e-ui/bug-report-test-N.ko.mdandbug-report-test-N.mdfor bugs - Track overall progress
- Create
-
Report Results:
- List of completed tests
- List of bugs found (with details)
- Summary of test code created
- Guide next steps
Key Rules
π¨ Bug Detection (Important)
Document and continue when these situations occur:
-
Page Load Failure:
- Navigation timeout
- 404/500 errors
- Blank page
-
Element Not Found:
- Expected button/input missing
- Wrong element attributes
- Wrong page structure
-
Interaction Failure:
- Click not working
- Input text not entering
- Form submission failure
-
Console Errors:
- JavaScript errors
- Network failures (except expected ones)
- React errors/warnings
-
Unexpected Behavior:
- Wrong navigation
- Wrong data display
- Missing UI elements
- Broken functionality
Bug Report Format (create both ko.md and md versions):
Files to create:
docs/e2e-ui/bug-report-test-N.ko.md(Korean)docs/e2e-ui/bug-report-test-N.md(English)
## π Bug Found
**Test**: [Test N: name]
**Priority**: [Critical/High/Medium]
**What Was Being Tested**:
[description]
**Reproduction Steps**:
1. [step 1]
2. [step 2]
3. [bug occurs here]
**Expected Behavior**:
[what should happen]
**Actual Behavior**:
[what actually happened]
**Evidence**:
- Screenshot: [path]
- Console Errors: [if any]
- Page State: [snapshot info]
**Impact**:
[impact on users]
After creating bug report, continue to next test instead of stopping.
β MUST DO
- Read
playwright.config.tsandpackage.jsonfirst to get project configuration- playwright.config.ts: test directory, base URL, test settings
- package.json: framework detection
- Run tests one at a time (sequentially)
- Use Playwright MCP for actual testing before code writing
- Create bilingual bug reports (ko.md + md) when bugs found
- Continue testing after documenting bugs
- Write test code in directory from playwright.config.ts (testDir or testMatch)
- Write clean and maintainable test code
- Follow TypeScript and testing coding standards
- Generate summary for each test
- Take screenshots for evidence
β NEVER DO
- Skip reading
playwright.config.ts(it's the primary source of truth) - Run multiple tests in parallel
- Skip manual verification phase
- Stop testing after finding bug (should continue)
- Write test code without verifying behavior
- Create single-language bug reports (must be bilingual)
- Write test code outside directory specified in playwright.config
- Hardcode base URLs or test directories
- Ignore console errors or warnings
- Skip edge cases
π― Test Implementation Process
For each test:
-
Manual Verification (using Playwright MCP):
- Navigate to page - Interact with UI elements - Take snapshots - Verify expected behavior - Check console messages -
Bug Check:
- Did everything work as expected?
- Any errors or warnings?
- Is behavior correct?
-
Decision Point:
- β If Pass: Proceed to write test code
- π If Bug Found: Create bilingual bug report, continue to next test
-
Write Test Code (only if passed):
typescript// Create test file in directory from playwright.config.ts (testDir or testMatch) // Follow project test patterns // Include assertions and error handling // Follow naming convention from testMatch pattern (e.g., *.spec.ts, *.e2e.ts) -
Documentation:
- Generate summary document
- Record what was tested
- Note observations
Document Template
File to create: docs/e2e-ui/summary-test-N.md
# Test N: [scenario name]
> **Created**: [YYYY-MM-DD HH:mm]
> **Related Plan**: `test-targets.md` > Test N
> **Status**: β
Pass / π Bug Found
---
## π― Test Objective
[what this test verifies]
---
## π§ͺ Manual Verification Results
**Test Steps Performed**:
1. [step 1] - β
Success
2. [step 2] - β
Success
3. [step 3] - β
Success
**Screenshots**:
- [screenshot 1]: `path/to/screenshot1.png`
- [screenshot 2]: `path/to/screenshot2.png`
**Console Output**:
- [relevant console messages]
**Observations**:
- [interesting findings]
---
## π Generated Test Code
**File**: `[path/to/test/file.spec.ts]`
**Main Assertions**:
- [assertion 1]
- [assertion 2]
**Code Structure**:
```typescript
// Brief overview of test structure
test("scenario name", async ({ page }) => {
// test steps
});
```
β Verification
Test Execution:
- Manual verification: β Pass
- Code implementation: β Complete
- Test successfully run: [β / Not yet run]
Edge Cases Tested:
π Coverage
What This Test Covers:
- [feature 1]
- [user flow 2]
What It Doesn't Cover (future):
- [out of scope items]
π Technical Notes
- [technical decisions made]
- [workarounds if needed]
- [dependencies or setup required]
---
## Bug Report Template
**Create bilingual bug reports when bug found**:
Files to create:
- `docs/e2e-ui/bug-report-test-N.ko.md` (Korean version)
- `docs/e2e-ui/bug-report-test-N.md` (English version)
### Korean Version Template
```markdown
# π λ²κ·Έ 리ν¬νΈ: Test N
> **λ°κ²¬μΌμ**: [YYYY-MM-DD HH:mm]
> **ν
μ€νΈ**: Test N: [μλλ¦¬μ€ μ΄λ¦]
> **μ°μ μμ**: [Critical/High/Medium]
---
## π λ²κ·Έ μμ½
[λ²κ·Έμ λν ν λ¬Έμ₯ μ€λͺ
]
---
## π μμΈ λ΄μ©
**ν
μ€νΈ λμ**:
[ν
μ€νΈ μλλ¦¬μ€ μ€λͺ
]
**μ¬ν λ¨κ³**:
1. [λ¨κ³ 1]
2. [λ¨κ³ 2]
3. [λ²κ·Έ λ°μ μ§μ ]
**μμ λμ**:
[κΈ°λνλ λμ]
**μ€μ λμ**:
[μ€μ λ°μν λμ]
---
## πΈ μ¦κ±°
**μ€ν¬λ¦°μ·**:
- [μ€ν¬λ¦°μ· 1]: `path/to/screenshot.png`
**μ½μ μλ¬**:
[μ½μ μλ¬ λ©μμ§ λΆμ¬λ£κΈ°]
**νμ΄μ§ μν**:
```yaml
[νμ΄μ§ μ€λ
μ· λλ κ΄λ ¨ HTML]
π₯ μν₯λ
μ¬μ©μ μν₯: [μ΅μ’ μ¬μ©μμκ² λ―ΈμΉλ μν₯]
μ¬κ°λ: [μ΄ μ°μ μμ λ λ²¨μΈ μ΄μ ]
π λ€μ λ¨κ³
- μ¬μ©μκ° λ²κ·Έ 리ν¬νΈ κ²ν
- κ°λ°μκ° λ²κ·Έ μμ
- μμ ν
/e2e-ui:execute NμΌλ‘ μ΄ ν μ€νΈλΆν° μ¬κ° κ°λ₯
### English Version Template
```markdown
# π Bug Report: Test N
> **Discovered**: [YYYY-MM-DD HH:mm]
> **Test**: Test N: [scenario name]
> **Priority**: [Critical/High/Medium]
---
## π Bug Summary
[one sentence description of bug]
---
## π Details
**What Was Being Tested**:
[test scenario description]
**Reproduction Steps**:
1. [step 1]
2. [step 2]
3. [bug occurs here]
**Expected Behavior**:
[what should happen]
**Actual Behavior**:
[what actually happened]
---
## πΈ Evidence
**Screenshots**:
- [screenshot 1]: `path/to/screenshot.png`
**Console Errors**:
[paste console error messages]
**Page State**:
```yaml
[page snapshot or relevant HTML]
π₯ Impact
User Impact: [impact on end users]
Severity: [why this priority level]
π Next Steps
- User reviews this bug report
- Developer fixes the bug
- After fix, resume:
/e2e-ui:execute Nto continue from this test
**Important**: After creating bug report, continue to next test instead of stopping.
---
## Execution Flow
### Initialization
1. **Read project configuration files**:
- `playwright.config.ts`: Extract test directory, base URL, naming convention from testMatch
- `package.json`: Detect framework from dependencies (next, react, vue, etc.)
- **Fallback**: If config not found, ask user for test directory and base URL
2. Load test targets document (docs/e2e-ui/test-targets.md - English version, for AI)
3. Determine which tests to run
4. Check existing summaries (resume capability)
### For Each Test
1. **Announce**: "Starting Test N: [name]"
2. **Manual Testing**:
- Use Playwright MCP tools
- Navigate, interact, verify
- Take screenshots
- Check console
3. **Evaluate**:
- Is behavior correct?
- Any errors?
4. **Decide**:
- If bug: Generate bilingual bug report (ko.md + md), continue to next
- If pass: Continue to code writing
5. **Write Code** (only if passed):
- Create test file in directory from playwright.config.ts
- Implement test logic
- Follow coding standards
- Follow naming convention from testMatch pattern
6. **Document**:
- Generate summary (if passed)
- Generate bug report (if bug found)
- Record findings
7. **Progress**: "Test N complete. Moving to Test N+1..."
### Completion
- Provide comprehensive summary:
- List of tests passed with generated code
- List of bugs found with report links
- Overall coverage achieved
- Recommendations for next steps
---
## Execute
Start working according to the guidelines above.
Recommended Agent Skills
Expand your agent's capabilities with these related and highly-rated skills.
agent-ops-spec
Manage specification documents in .agent/specs/. Use when user provides requirements, acceptance criteria, or feature descriptions that need to be tracked and validated against implementation.
agent-ops-state
Maintain .agent state files. Use at session start, after meaningful steps, and before concluding: read/update constitution/memory/focus/issues/baseline consistently.
agent-ops-spec
Manage specification documents in .agent/specs/. Use when user provides requirements, acceptance criteria, or feature descriptions that need to be tracked and validated against implementation.
agent-ops-testing
Test strategy, execution, and coverage analysis. Use when designing tests, running test suites, or analyzing test results beyond baseline checks.
agent-ops-testing
Test strategy, execution, and coverage analysis. Use when designing tests, running test suites, or analyzing test results beyond baseline checks.
agent-ops-state
Maintain .agent state files. Use at session start, after meaningful steps, and before concluding: read/update constitution/memory/focus/issues/baseline consistently.
Didn't find tool you were looking for?