菜单
Verify frontend work visually in Chrome. Use after implementing or modifying UI to take headless screenshots at multiple viewports, read them to analyze visual correctness, and catch issues before the user has to.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Implement features from design docs. Use when (1) user references a design doc from docs/design_docs/, (2) user says "build feature" or "implement feature", (3) user references an existing impl plan from docs/for_ai/plans/. Creates implementation plan from design doc if none exists, then builds.
Bug fixing workflow. Use when (1) user reports a bug, (2) user says "fix bug" or "/fix-bug", (3) debugging failing behavior. Reproduce, fix at the right layer, run tests, open PR, resolve comments, log the task. Add a test only when it captures the bug through observable behavior.
Grade shipped product bets against what their discoveries predicted — pull each registered metric from its source of truth, walk the watch items, verdict every falsification line. Use when (1) user says "/outcome-review", "did it work", "grade our bets", "outcome review", (2) a month has passed since the last review, (3) any outcomes-register row's first check date has passed.
Interview a team member to produce a problem-first proposal — the intake artifact for /sdlc and /adhoc-fullstack-feature. Use when (1) user says "/proposal", "write a proposal", or "pitch", (2) a feature request arrives as a sentence and needs shaping before discovery, (3) someone wants to raise a problem or opportunity for the product pipeline.
Triage and resolve PR review comments — from the /ship-pr review agents (security, design, conventions, bug-hunter, data-migration), from humans, or both. Verify each finding, fix or push back, reply on every thread. Use when user says "/resolve-pr-comments" or asks to resolve PR comments.
Ship a finished slice of work as a PR — open a draft PR, run the review-agent sweep (agents comment inline on the PR), triage every finding, then mark ready. The agents replace the external review bot as the review authority. Use when (1) a workflow skill says "ship with /ship-pr", (2) user asks to open a PR for completed work, (3) work on a branch is built + tested and needs review.
基于 SOC 职业分类
| name | chrome-verify |
| description | Verify frontend work visually in Chrome. Use after implementing or modifying UI to take headless screenshots at multiple viewports, read them to analyze visual correctness, and catch issues before the user has to. |
Two tools — pick based on need:
| Need | Tool | Context cost |
|---|---|---|
| Verify pages look right (default) | Playwright library script | Low — just screenshots |
| Interactive debugging / exploring | Playwright MCP tools | High — use sparingly |
Default to library scripts. Only use MCP when you need a real-time see-think-act loop (e.g. debugging why a dropdown doesn't open, testing a multi-step flow where you need to react to results).
CRITICAL: if you're using the npm package, run inline Playwright via Bash — write the script to a scratch dir and run it with node.
Customize for your project:
- Dev server: `{{YOUR_DEV_SERVER}}` (e.g., localhost:3000)
- Check: `lsof -i :{{PORT}} -sTCP:LISTEN`
- Login: {{YOUR_LOGIN_FLOW}} (auto-submit via URL params keeps scripts simple)
- Playwright installed as a dev dep with Chromium. `import { chromium } from 'playwright'`
Ensure data is seeded. Based on the API/data layer you're verifying, check the dev DB. If there isn't enough data to exercise the cases you need (empty, few, many, edge), it's your responsibility to seed it per scenario before screenshotting.
Focus on what's relevant to your change — not everything every time.
Always check:
If touching layout/styling:
If touching RTL/i18n (if applicable):
If touching data displays (tables, cards, charts):
If touching interactive elements:
Common gotchas: