菜单
Use after implementation or repair work when the reviewer must judge intent realization, requirement coverage, scope consistency, and claim truth before code-review or delivery-completion can accept the work.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when a bug, failing test, regression, or unexpected behavior needs a root-cause-first debugging loop before code changes, especially when brownfield seams, recent releases, or historical defect matches make guesswork unsafe.
Use when E2E tests must go beyond shallow happy-path checks — multi-step user journeys, stateful sessions, cross-boundary state consistency, failure-mode edges — or when the suite passes but production still breaks. Platform- and framework-agnostic (web, mobile, desktop; Playwright, XCUITest, Cypress).
Use when discovery has narrowed an idea enough that the team must make a go/no-go, pivot, or scope-down decision based on technical, economic, operational, or timeline viability before requirements, architecture, or major implementation.
The mandatory gateway for all new engineering work. Triage and route new products, apps, features, migrations, tech-debt, or any 'not sure where to start' request to the correct lifecycle path. Use before starting design or implementation. Do not use for ongoing tasks, specific debugging, or PR reviews.
Use when discovery needs evidence about market demand, competitors, pricing pressure, or underserved segments for a new product or expansion idea before feasibility, user research, or requirements are finalized.
Use when intake has identified the likely lifecycle path but the problem statement, solution direction, or key trade-offs are still too fuzzy for requirements, research, or architecture work to start cleanly
| name | pc-implementation-alignment-review |
| description | Use after implementation or repair work when the reviewer must judge intent realization, requirement coverage, scope consistency, and claim truth before code-review or delivery-completion can accept the work. |
| metadata | {"phase":"05-quality","inputs":["intake-brief","source-code","test-suite","task-list","acceptance-criteria-set"],"outputs":["review-report"],"prerequisites":["pc-feature-development"],"quality_gate":"Intent, acceptance criteria, implementation behavior, tests, docs, and completion claims are aligned with explicit evidence and no silent scope substitutions","roles":["reviewer","tech-lead"],"methodologies":["all"],"effort":"medium"} |
This skill checks whether the implementation actually satisfies the user's intent and approved scope.
See context notes.
I/O contract notes define required inputs and authority.
State the intended outcome in one or two concrete sentences. Separate must-have behavior, non-targets, and later work. Do not infer extra scope from implementation shape.
Map each user requirement, acceptance criterion, and priority item to implementation evidence. Mark each row as implemented, partially implemented, deferred, contradicted, or unverifiable.
Check final messages, docs, quality reports, release notes, and test names against the actual code and runtime evidence. Flag any claim that turns simulated, fake, fixture, local-only, or partial evidence into a stronger statement.
Verify that code, tests, docs, runbooks, risk registers, and quality snapshots tell the same story. Mismatches are findings even when each file is locally coherent.
Prioritize:
Produce only declared outputs at their documented quality boundary.
