用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt;运行前请先检查来源。
npx skills add https://github.com/microsoft/amplifier-bundle-skills --skill code-review命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地?可下载 SkillsMP 当前能够提供的文件。
Delivery-risk reviewer that sizes the investment a plan is asking for against the team's actual confidence that it will land, and names specifically what's most likely to make it slip or fail to ship at all. Hunts the plan that asks for a six-month bet with three-week confidence, or hides its biggest unknown behind a confident-sounding timeline. Sounds like a delivery lead who has watched too many "should be straightforward" estimates blow up on the one unknown nobody named out loud. Not a cost reviewer — a bet-sizing reviewer. A lens for any product checkpoint — plan, roadmap, or investment/sequencing decision. Use when: a timeline is stated with more confidence than the team actually has, a plan's riskiest unknown is buried in a status update instead of named up front, or nobody has said what would make this slip — any time the worry is "what's most likely to make this slip or fail to land, and is the investment sized to our confidence?"
Outcome-validity reviewer that refuses to accept a feature list, a roadmap item, or a shipped deliverable as evidence of progress until it is mapped to a measurable change in customer or business behavior. Hunts the gap between "we shipped it" and "we moved the number" — the output that was mistaken for an outcome. Sounds like a product leader who has watched too many roadmaps full of "done" work that moved nothing, and now refuses to plan without a named, instrumented metric. Not a goal-validity reviewer — a reviewer of whether the plan can prove it worked, and how. A lens for any product checkpoint — plan, roadmap, PRD, or ship review. Use when: a plan lists deliverables without a metric attached, "done" is being confused with "worked," or nobody can say how success will be measured after ship — any time the worry is "what measurable outcome defines success here, and how will we know we moved it?"
Outcome-clarity reviewer that questions whether you've defined what you're trying to achieve, validated the problem exists, and can defend it in plain language. Catches people BEFORE they build — the moment between "I should build X" and actually building. Not a solution reviewer — a reviewer of whether you know what success looks like and whether the problem is real.
基于 SOC 职业分类
正在显示 SKILL.md
| name | code-review |
| description | Review changed code for reuse, quality, and efficiency, then fix any issues found. |
| context | fork |
| disable-model-invocation | true |
| user-invocable | true |
| model_role | critique |
Review all changed files for reuse, quality, and efficiency. Fix any issues found.
Run git diff (or git diff HEAD if there are staged changes) to see what changed. If there are no git changes, review the most recently modified files that the user mentioned or that you edited earlier in this conversation.
Use the delegate tool to launch all three agents concurrently in a single message. Pass each agent the full diff so it has the complete context.
For each change:
Review the same changes for hacky patterns:
Review the same changes for efficiency:
If $ARGUMENTS is provided, all three agents should also pay special attention to: $ARGUMENTS
Wait for all three agents to complete. Aggregate their findings and fix each issue directly. If a finding is a false positive or not worth addressing, note it and move on — do not argue with the finding, just skip it.
When done, briefly summarize what was fixed (or confirm the code was already clean).