菜单
Run a design-review session on an existing page — create the branch, invoke frontend-design, build incrementally with screenshots, then PR into develop. Use when visually overhauling an existing page or section.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | design-review |
| description | Run a design-review session on an existing page — create the branch, invoke frontend-design, build incrementally with screenshots, then PR into develop. Use when visually overhauling an existing page or section. |
| disable-model-invocation | true |
Wraps the frontend-design skill with the correct lifecycle for visual overhaul sessions. Five steps, in order.
Before any critique or code, branch off develop:
git checkout develop && git pull
git checkout -b design-review/<page>-<YYYY-MM-DD>
Example: design-review/landing-page-2026-06-17. Do not start the session on develop or an existing feature branch.
Invoke the frontend-design skill. This skill drives the critique and build loop — follow its instructions. A few constraints that apply on top of it:
Closes #N in the PR.Before marking any section done, screenshot it. This catches real issues (wrong component used, layout off, visual regressions) that a code read won't catch. If the project supports multiple colour modes or themes, capture each.
Once the pass is complete, run type-check and lint, then open the PR:
gh pr create --base develop --title "design-review: <page>" --body "Visual overhaul of <page>. No issue — design-review sessions are exempt from the issues-first workflow."
No Closes #N, no awaiting-promotion label — the normal issue lifecycle does not apply here.
After the PR merges, invoke /post-merge for the doc update and develop pull — but skip the awaiting-promotion label step (there's no issue to label).
Pick up a GitHub issue by number and drive it from clarification through implementation, PR, a single automated review pass, and fixing the resulting remarks. Use when the user gives a bare ticket/issue number and asks to implement, pick up, or ship it (e.g. "/implement-ticket 123", "pick up ticket 123", "implement issue
Kick off a new feature — stress-test the plan with grill-with-docs, break it into tickets with to-issues, then commit any doc changes to develop. Use when you have a feature idea or rough plan and want to go from concept to a clean set of GitHub issues.
Run the post-merge checklist after a feature PR lands on develop — pull latest, add awaiting-promotion label to the issue, update CLAUDE.md/CONTEXT.md if stale, and commit docs directly to develop. Use when a feature PR has just merged into develop and you want to run the standard follow-up steps.
Promote develop to main — apply any pending migrations, open the develop→main PR with Closes