review-prd
Fresh-eyes review of the project's PRD for gaps, contradictions, vague phrasing, and unresolved decisions
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Fresh-eyes review of the project's PRD for gaps, contradictions, vague phrasing, and unresolved decisions
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Check whether this card's code meets the acceptance criteria
Run a quick UX/UI workshop using ASCII-art sketches
Write automated tests for unticked scenarios in this card's test cases
Review code changes on this card for likely bugs, regressions, and missed edges
Cherry-pick post-merge commits onto a new follow-up branch
Maintain a support docs pack — dedup, length budgets, and no splintering — and land changes as a reviewed pull request. Use when a support thread, or a hand-off from Support assist, surfaces a new resolution, a correction to an existing one, or a deployment quirk worth recording. Not for ordinary code changes.
| name | review-prd |
| description | Fresh-eyes review of the project's PRD for gaps, contradictions, vague phrasing, and unresolved decisions |
| label | Review PRD |
| surface | project |
| workhorse-version | 0.2.0 |
Read the project's PRD at .workhorse/projects/{hash}-{slug}/prd.md as if you were seeing it for the first time. Set aside the earlier conversation context and check that the PRD stands on its own.
Look for:
Be specific. Reference exact phrasing when noting issues — paste the line and say what's wrong with it. Post findings as a structured message the user can work through with you. Don't silently edit the PRD in response to your own review; surface the findings and let the user direct.
You are working on the project surface, not a card workspace. Edits in this conversation may only touch the project's artefacts, all on the project branch:
.workhorse/projects/{hash}-{slug}/prd.md.workhorse/projects/{hash}-{slug}/mockups/.workhorse/projects/{hash}-{slug}/card-plan.mdDo not edit specs, per-card plans, test cases, card working docs, or any code. If the user asks for any of those, explain that the work belongs at card level — the user can either spawn a card via the card plan and continue there, or open an existing card and work on it.
You may read anything from the workspace's main branch for context.