القائمة
High-precision review of code changes for real bugs, security regressions, and explicit project-guideline violations, with independent verification before reporting.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
Build a threat model for a codebase — map assets, entry points, trust boundaries, and the threats that matter — and write THREAT_MODEL.md to focus later scanning and triage.
Explore an existing codebase, design a concrete feature architecture, implement in small phases, and verify with focused tests.
Behavior-preserving cleanup of recently changed code for reuse, clarity, consistency, and efficiency.
Verify, deduplicate, rank, and route raw security findings from VULN-FINDINGS.json, scanner output, or a markdown report, then write TRIAGE.json and TRIAGE.md.
Static source-code vulnerability scan that maps focus areas, fans out read-only security agents, and writes VULN-FINDINGS.json plus VULN-FINDINGS.md for triage.
Generate minimal, behavior-preserving fixes for verified security findings, then verify each fix builds, passes tests, and closes the root cause.
استنادا إلى تصنيف SOC المهني
| name | code-review |
| description | High-precision review of code changes for real bugs, security regressions, and explicit project-guideline violations, with independent verification before reporting. |
| when-to-use | When the user wants feedback on local changes, a branch diff, or a PR before committing or merging. |
| arguments | ["ref"] |
Review the requested changes and report only findings you have verified are real. The goal is a short, trustworthy list a senior engineer would stand behind, not an exhaustive dump. A false positive costs more trust than a missed nitpick.
git diff for unstaged and git diff --cached for staged changes. If a ref was provided: git diff ${ref}.git status --short to understand whether staged and unstaged changes are mixed.git log --oneline -5 to learn commit and change conventions.AGENTS.md/CLAUDE.md (if present) and any such files in directories the diff touches. These encode project-specific rules the review must check against.If the diff is empty, say so and stop.
Launch these as read-only agents concurrently in a single message. Give each the full diff, changed-file list, and relevant guideline files. Each agent returns candidate findings only: file:line, a one-line claim, and why it flagged it. Tell each: report anything with a plausible problem, but skip pure style nitpicks and pre-existing issues on lines this diff did not touch.
code-reviewer)Logic errors (inverted conditions, off-by-one, wrong operator); edge cases (nil/empty, boundaries, concurrency); error handling (swallowed errors, missing cleanup on error paths); resource leaks (files, connections, goroutines); race conditions on shared mutable state; API-contract violations (wrong types, ignored return values).
code-reviewer)Does the change follow the patterns in the surrounding code? Naming clarity; functions doing too much; inconsistent abstraction level; dead code (unused imports, unreachable branches, commented-out code); duplication that should reuse an existing helper.
security)Input validation at trust boundaries; injection (SQL, command, XSS, template); secrets or PII in logs/responses; auth/authz gaps introduced by the change. Flag with a concrete data-flow story, not a category name. This is a light pass over the diff only. For a full audit with scan and triage artifacts, point the user to /vuln-scan then /triage.
code-reviewer)For each rule in the gathered AGENTS.md/CLAUDE.md, check the diff complies. A finding here must quote the specific rule it violates. Skip rules that are guidance for writing code rather than reviewable invariants.
code-explorer)Read git history and nearby comments for the changed files. Flag only issues where history or local comments reveal a concrete contract the diff violates.
Collapse duplicates (same file:line + same issue). Then, for each remaining candidate, launch a skeptical code-reviewer verifier in parallel, one per candidate, with this brief:
Your default assumption is that this finding is WRONG. Re-read the cited code yourself; don't trust the summary. Confirm the problem is real, is reachable, and is on a line THIS diff introduced or changed. Reject it if: it's pre-existing, a linter/compiler/type-checker would catch it, it's intended behavior, it's a nitpick a senior engineer wouldn't raise, or a guideline finding doesn't map to an actual rule. End with exactly:
VERDICT: real | false-positiveCONFIDENCE: 0-100WHY: <one line citing file:line evidence>
Keep only findings with VERDICT: real and CONFIDENCE >= 80. Be willing to drop a plausible-but-unconfirmed finding rather than ship noise.
Organize survivors by file with file:line references. For each:
End with a one-line verdict: ready to merge, or needs work. If nothing survived verification, say so plainly — "No high-confidence issues found" is a valid and valuable result.