用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/bobmatnyc/claude-mpm-skills --skill code-review-standards命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
正在显示 SKILL.md
LinkedIn automation via the Linked API CLI - fetch profiles, search people and companies, send messages, manage connections, create posts, react, comment, and run Sales Navigator and custom workflows. Use when the user wants to interact with LinkedIn.
Xquik X data automation API - Use REST or MCP for tweet search, user lookup, follower exports, media downloads, monitors, webhooks, giveaway draws, and confirmation-gated X actions.
MCP (Model Context Protocol) - Build AI-native servers with tools, resources, and prompts. TypeScript/Python SDKs for Claude Desktop integration.
基于 SOC 职业分类
| name | code-review-standards |
| description | Severity-tagged code review checklist (CRITICAL/HIGH/MEDIUM/LOW) used by code-critic agent |
| user-invocable | false |
| disable-model-invocation | true |
| license | Apache-2.0 |
| compatibility | claude-code |
| progressive_disclosure | {"entry_point":{"summary":"Severity-tagged checklist for code review. CRITICAL/HIGH block delivery; MEDIUM is flagged; LOW is noted. Critic outputs APPROVE (zero CRITICAL/HIGH), WARN (some HIGH, no CRITICAL), or BLOCK (any CRITICAL). 80% confidence filter — don't manufacture findings.","when_to_use":"Loaded by code-critic agent to apply structured review criteria. Also loaded by engineers to self-check before requesting review.","quick_start":"Apply checklist top-to-bottom: CRITICAL first, then HIGH, MEDIUM, LOW. For each finding: cite file+line, explain why it's a problem, provide the fix. Filter to >80% confidence. Output verdict with finding table."},"references":["criteria-critical.md","criteria-high.md","criteria-medium.md","criteria-low.md","criteria-efficiency.md","criteria-transferability.md","verdict-protocol.md"]} |
This skill defines the structured checklist that the code-critic agent applies during
Stage 4 of the code production pipeline. The checklist is severity-tagged so that PM
and engineer both know exactly which findings block delivery and which are advisory.
Engineers may load this skill for self-review before requesting a critic pass.
The checklist exists because unstructured code review in multi-agent systems produces inconsistent signal: one critic dispatch flags naming; another flags security; neither flags the same things. Severity tagging makes the review deterministic across dispatches.
eval, exec, unrestricted pickle.loads)Efficiency (see criteria-efficiency.md):
+=SELECT * / over-fetching in production query pathsTransferability (see criteria-transferability.md):
if/else if chains (3+ branches on one key) replaced by switch/match or dispatch mapswitch/match — extract inner switch to a named functionCritic output MUST begin with the verdict on the first line, followed by the finding table, followed by a summary paragraph.
First line format:
VERDICT: APPROVE
or
VERDICT: WARN
or
VERDICT: BLOCK
Finding table format:
| Severity | File | Line | Issue | Required Fix |
|---|---|---|---|---|
| CRITICAL | auth.py | 47 | Hardcoded API key sk-... | Move to env var; add to .env.example |
| HIGH | fetcher.py | 23 | requests.get() called inside async def | Replace with await httpx.AsyncClient().get() |
| MEDIUM | parser.py | 88 | Function is 34 lines | Extract _parse_headers() helper |
Verdict definitions:
| Verdict | Condition | PM Action |
|---|---|---|
| APPROVE | Zero CRITICAL, zero HIGH findings | Proceed to Stage 5 (Security) |
| WARN | Zero CRITICAL, one or more HIGH findings | Proceed to Stage 5 with findings logged to docs handoff |
| BLOCK | Any CRITICAL finding (one or more) | Halt pipeline; surface findings to user; await user direction |
APPROVE means the implementation is ready for security review. MEDIUM and LOW findings in an APPROVE review are passed to the Documentation agent as notes — they do not block delivery but are preserved for future reference.
WARN means the implementation has structural issues that should be fixed but do not represent exploitable defects or correctness failures. PM proceeds to security review and appends the WARN finding table to the documentation handoff message. PM also logs the findings (KB entry or todo) so they are not silently dropped.
BLOCK means the implementation has at least one defect that, if shipped, creates a security vulnerability, data loss risk, or silent failure mode. PM halts the pipeline immediately, presents the critic finding table verbatim to the user, and awaits explicit direction. PM MUST NOT auto-retry the engineer without user input.
A clean review is a valid review. Do not manufacture findings.
Only report issues with >80% confidence they are real problems. Do not flag:
When confidence is below 80%, note the concern as a question in the summary paragraph
rather than as a finding in the table. Example: "The process_batch() function did not
appear to handle empty input — verify whether the caller guarantees non-empty batches."
This filter prevents the critic from becoming a noise generator that trains PM to ignore findings. Each finding in the table should be actionable: engineer reads it, knows exactly what to fix, and can do so without asking for clarification.
For detailed criteria with examples:
The Efficiency and Transferability criteria are derived from CAST Highlight code quality indicators (https://doc.casthighlight.com/), paraphrased with original examples.