一键导入
browser-qa
Manual browser QA via Chrome DevTools MCP. Use when acceptance criteria include manual verification or UI changes need visual confirmation.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Manual browser QA via Chrome DevTools MCP. Use when acceptance criteria include manual verification or UI changes need visual confirmation.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | browser-qa |
| description | Manual browser QA via Chrome DevTools MCP. Use when acceptance criteria include manual verification or UI changes need visual confirmation. |
Manual browser verification procedure for UI changes using Chrome DevTools MCP.
manual verificationpackages/client/src/components/cd <repository-root>
bun run dev
Check the startup log for the actual port — Vite may auto-increment if the default port (5173) is in use:
Port 5173 is in use, trying another one...
➜ Local: http://localhost:5174/
Also check .env for custom port configuration (CLIENT_PORT, PORT).
mcp: navigate_page → http://localhost:<port>
mcp: take_screenshot → confirm page loaded
For specific pages, navigate directly via client route (SPA routing works):
mcp: navigate_page → http://localhost:<port>/sessions/<id>
Use Chrome DevTools MCP tools:
| Action | Tool | Tips |
|---|---|---|
| Click element | click | Use take_snapshot first to get element UIDs |
| Type text | type_text | Click the input first to focus |
| Fill form field | fill | Target by UID from snapshot |
| Wait for async | wait_for | Wait for selector to appear |
| Check errors | list_console_messages | Look for JS errors |
| Screenshot | take_screenshot | Capture before/after states |
For each manual verification criterion:
list_console_messages for unexpected errorsStop the dev server when done (kill the background process or Ctrl+C).
All screenshots should be saved to disk for later upload to the PR.
Before starting QA, prepare the screenshot directory:
rm -rf .qa-screenshots && mkdir -p .qa-screenshots
Always use filePath to save to .qa-screenshots/:
take_screenshot with filePath: ".qa-screenshots/{descriptive-name}.png"
Use descriptive, hyphenated names:
restart-all-button.png, restart-result-toast.pngerror-{description}.png (for error states)Only take screenshots for areas relevant to the PR's change scope:
After QA, upload screenshots to the PR:
./scripts/upload-qa-screenshots.sh <PR_NUMBER>
This script:
git remote (override with GITHUB_REPOSITORY env var)qa-screenshots GitHub Release if it doesn't exist (one-time, used as image hosting).png files from .qa-screenshots/ with unique names<details>Note: GitHub Release assets are served with Content-Disposition: attachment, so <a href> links trigger downloads instead of displaying images. The script uses <details><summary> to work around this.
If the PR number is not known, detect it:
gh pr view --json number -q '.number'
When re-taking screenshots (e.g., after implementation changes), minimize the previous screenshot comment on the PR before uploading new ones. This prevents reviewers from seeing outdated screenshots.
# 1. Find the previous screenshot comment's node ID
gh api graphql -f query='query { repository(owner: "OWNER", name: "REPO") { pullRequest(number: PR_NUM) { comments(first: 50) { nodes { id body createdAt } } } } }' \
--jq '.data.repository.pullRequest.comments.nodes[] | select(.body | test("qa-screenshots")) | .id'
# 2. Minimize it as OUTDATED
gh api graphql -f query='mutation { minimizeComment(input: {subjectId: "NODE_ID", classifier: OUTDATED}) { minimizedComment { isMinimized } } }'
# 3. Upload new screenshots
./scripts/upload-qa-screenshots.sh <PR_NUMBER>
bun run --filter '@agent-console/shared' build first — client depends on shared types.Orchestrator role for strategic decision-making, task prioritization, parallel task coordination via worktree delegation, and first-responder for dev agent questions. Use when managing multiple development agents or making prioritization decisions.
Non-obvious operational details of the local dev environments (single-user `dev.sh`, multi-user `dev-multiuser.sh`, Docker dev stack `docker/docker-compose.yml`) — port layout, source-code propagation, sudo boundaries, multi-repo coexistence. Read when a delegated agent or the Orchestrator first needs to interact with the running dev instance, especially for Browser QA, log inspection, or restart workflows.
Development workflow procedures including conflict assessment, re-implementation proposals, and TDD steps. Use when you need step-by-step workflow guidance beyond what the auto-loaded workflow rules provide.
CodeRabbit code review operations playbook + troubleshooting / FAQ. Use when creating a PR, before merge, when handling CodeRabbit issues (rate-limit fallback, GitHub-side bot unresponsive, both layers simultaneously rate-limited), or when interpreting the 3-layer clean verdict (Pre-merge checks / reviewDecision / inline comments). Covers local CLI invocation, GitHub-side bot interpretation, and case-by-case dispositions.
Detailed test patterns and code examples. Use when you need step-by-step testing guidance, Server Bridge Pattern, or concrete code patterns beyond what the auto-loaded testing rules provide.
Catalog of cross-cutting architectural invariants that code must respect. Use when designing, implementing, or reviewing features that involve shared resources, persistence, or I/O symmetry. Ask each catalog question against the change.