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 リポジトリを開く Creator のリポジトリを見る

ダウンロード

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.