菜单
Use when a feature has been built and needs browser-based UI testing. Plans test scenarios, groups them into parallel batches, and dispatches multiple browser-tester agents simultaneously.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | browser-test |
| description | Use when a feature has been built and needs browser-based UI testing. Plans test scenarios, groups them into parallel batches, and dispatches multiple browser-tester agents simultaneously. |
Plan and execute browser-based UI testing in parallel using multiple agents.
The user input is: $ARGUMENTS
.claude/plans/specs/ or plan from .claude/plans/If no spec or plan is found, ask the user what feature to test.
http://localhost:3000)Analyze the feature and group scenarios by independence:
For each feature area, create test scenarios covering:
Group into parallel batches — different pages or scenarios that can each start from a fresh page load.
Present the test plan:
Test Plan: [Feature Name]
Batch 1 (Agent 1): [Description]
- Scenario 1.1: ...
- Scenario 1.2: ...
Batch 2 (Agent 2): [Description]
- Scenario 2.1: ...
Wait for user approval. Max 4-5 parallel agents.
Dispatch each batch as a separate agent (haiku model). Read the agent prompt template from the tester-prompt.md file in this skill's directory and provide it as context along with the batch's specific scenarios.
Launch all batches in parallel using the Agent tool.
Why haiku: Browser test agents perform simple, mechanical work — navigate to URL, click elements, verify text content. This doesn't require deep reasoning, and haiku's speed means faster test cycles.
Compile results from all batches:
Test Results: [Feature Name]
PASSED: X/Y scenarios
FAILED: Z/Y scenarios
Batch 1: [status]
- Scenario 1.1: PASS
- Scenario 1.2: FAIL - [reason]
If tests failed, analyze whether the failure is a bug or a test environment issue. Report with specific details.
Use when the user needs to plan and architect a new feature before implementation begins. This includes analyzing requirements, asking clarifying questions, and creating a detailed implementation plan aligned with the project's architecture. Invoke BEFORE any coding work starts.
Use when implementation + verification are complete and the work needs to be integrated — commit, open a PR, merge, or clean up the branch. The final step of the craft pipeline (after develop/test/report). Works in the current checkout; no worktree assumption.
Use when starting a new feature that needs thorough design exploration. This is the most comprehensive workflow: collaborative brainstorming with the user, then planning, then parallel agent development, then browser testing. Use for complex features, unclear requirements, or when the user wants to explore approaches before committing.
Post-develop visual regression + design-contract audit. Starts the dev server, captures screenshots of changed UI routes, and dispatches a Haiku-vision agent to compare the result against .claude/aesthetic-direction.md and the feature's ux-brief.md. Flags regressions before browser-test runs. Escalates to Sonnet or Opus only when Haiku flags issues.
Use when an approved implementation plan exists and is ready to be executed. Initializes shared state, dispatches parallel developer agents, performs integration review, and runs full verification (lint, tsc, format, build).
Generate or refresh .claude/reuse-index.md — a one-page inventory of the project's shared utilities, enums, hooks, and components that downstream implementer agents must consult before writing new code. Project-agnostic scan: no framework assumptions baked in. Invoke once per project (or when the shared surface changes meaningfully).