critical-review

星标1

分支0

更新时间2026年5月17日 05:07

Review code for correctness risks, maintainability, security, and lifecycle issues with severity-tagged findings.

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

来源

bichikim

bichikim/create-vibe-start

打开 GitHub 仓库查看创作者相关仓库

下载

Critical Review

Review the target code for correctness risks and maintainability. When relevant, evaluate security, accessibility, and performance trade-offs using the same standards.

Scope

Perform the review within the explicit scope (files, PR diff, functions/modules, etc.). If a scope is provided, go deep only within that boundary.
If the scope is empty or unclear, do not start reviewing. Ask once more which files, commits, or features should be included.

Review Rules

Minimize praise and formal agreement; focus on observations, risks, and actionable alternatives. If you judge that “this does not need to be fixed immediately,” include the rationale.
Critique should be evidence-based rigor, not a harsh tone. For each claim, include at least one of: code citation, reproduction path, or assumption.
Assign a severity to each issue. Example: P0 (release/correctness/security blocker), P1 (maintainability, bug risk, fix after alignment).
Review from the perspective of a developer who uses this code. Evaluate API surface (names, types, props), misuse risk, and whether it is understandable without extra context.
Check whether logic can be decomposed and composed. Call out mixed responsibilities and coupling that blocks testing or reuse.
Inspect cleanup and lifecycle handling thoroughly: missing post-processing/cleanup, race conditions, and unmount scenarios around useEffect subscriptions, timers, event listeners, AbortController, etc.
Include example code in improvement suggestions. Prefer unified diffs when possible, and group same-theme changes in one diff. For trivial one-line edits, an inline code block is enough.

同仓库更多 Skills

同仓库

skill-diet

bichikim/create-vibe-start

Reduce an existing Codex skill to its minimum useful form, extract on-demand context into linked sibling files, or decide that the skill should be deleted. Use when the user asks to diet, slim, trim, simplify, minimize, reevaluate, or remove bloat from a skill while preserving its trigger behavior, tone, safety constraints, and practical usefulness.

2026-08-021

new-pr

bichikim/create-vibe-start

Create a GitHub pull request from the current branch—commit uncommitted changes, push, and open a PR against main with an auto-generated title and Summary/Testing body sections.

2026-08-021

unit-test

bichikim/create-vibe-start

Use when adding or updating unit tests for create-vibe-start CLI modules, especially Vitest tests that must isolate prompts, shell commands, platform detection, and package imports from real external resources.

2026-08-021

update-pr

bichikim/create-vibe-start

Update an existing GitHub pull request for the current branch—commit and push latest changes, then refresh the PR title and body from the full diff against main.

2026-05-171

deep-interview

bichikim/create-vibe-start

Interview the user with Socratic questions to turn an ambiguous request into actionable requirements. Use when the user asks for a deep-interview, requirement clarification, or help organizing their thoughts, or when the goal, scope, constraints, or definition of done are unclear. Do not use when the request is already concrete, or for low-value work like typo fixes, small config tweaks, or test top-ups.

2026-05-131

project-skill-generating

bichikim/create-vibe-start

Use when creating or updating project-specific Codex skills for create-vibe-start, especially skills stored under .agents/skills with concise SKILL.md instructions and progressively loaded reference files.

2026-05-041

name	critical-review
description	Review code for correctness risks, maintainability, security, and lifecycle issues with severity-tagged findings.
disable-model-invocation	true

Critical Review

Review the target code for correctness risks and maintainability. When relevant, evaluate security, accessibility, and performance trade-offs using the same standards.

Scope

Perform the review within the explicit scope (files, PR diff, functions/modules, etc.). If a scope is provided, go deep only within that boundary.
If the scope is empty or unclear, do not start reviewing. Ask once more which files, commits, or features should be included.

Review Rules

Minimize praise and formal agreement; focus on observations, risks, and actionable alternatives. If you judge that “this does not need to be fixed immediately,” include the rationale.
Critique should be evidence-based rigor, not a harsh tone. For each claim, include at least one of: code citation, reproduction path, or assumption.
Assign a severity to each issue. Example: P0 (release/correctness/security blocker), P1 (maintainability, bug risk, fix after alignment).
Review from the perspective of a developer who uses this code. Evaluate API surface (names, types, props), misuse risk, and whether it is understandable without extra context.
Check whether logic can be decomposed and composed. Call out mixed responsibilities and coupling that blocks testing or reuse.
Inspect cleanup and lifecycle handling thoroughly: missing post-processing/cleanup, race conditions, and unmount scenarios around useEffect subscriptions, timers, event listeners, AbortController, etc.
Include example code in improvement suggestions. Prefer unified diffs when possible, and group same-theme changes in one diff. For trivial one-line edits, an inline code block is enough.