Deep code review skill

Evidence-driven, risk-ranked deep code review skill for Codex and Claude Code

Install

npx -y skills add 1stIndeXR/deep-code-review-skill

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Perform evidence-driven, risk-ranked deep code reviews of repositories, subsystems, pull requests, architecture, test frameworks, CI/CD, and production readiness. Use when the user asks for a comprehensive or senior-level code audit, repository health assessment, test-gap analysis, release-readiness review, architecture review, rule-engine or calculation-engine review, or a review report without immediately changing code.

SKILL.md

11.0 KB, ~2.0k tokens by cl100k_base, as published. Nobody here has run it

Deep Code Review

Review the system as an operating whole, not as a collection of style observations. Optimize for defects, violated invariants, unsafe boundaries, untested behavior, and practical remediation.

Establish the review contract

Infer and state:

Subject: repository, subsystem, change set, or release.
Authority: review-only unless the user explicitly requests fixes.
Depth: focused, comprehensive, or release-gate.
Output: conversational findings, inline comments, or a report artifact.
Risk context: user impact, money, security, privacy, data integrity, availability, compliance, or safety.

Ask only when a missing answer would materially change scope or authorize a consequential action. Otherwise make a conservative assumption and record it.

Preserve unrelated work. Read repository instructions before commands. Do not modify source, tests, configuration, generated files, databases, external systems, or user state during a review-only task. A requested report file is the only implied write.

Route references selectively

Resolve every reference path relative to the directory containing this SKILL.md, regardless of the caller's current working directory or platform. Read referenced files with the available file-reading tool; do not assume Markdown links were opened automatically.

Read only the references relevant to the task:

Always read review-dimensions.md for a comprehensive or release-gate review.
Read testing-and-ci.md when tests, automation, build reproducibility, coverage, or release readiness are in scope.
Read domain-critical-systems.md for rule engines, recommendation/configuration systems, pricing, financial logic, authorization, multi-tenancy, persistence, workflows, or other high-consequence domain logic.
Read report-template.md when producing a formal report artifact or the user requests a findings matrix, backlog, phased plan, or final confidence rating.

Review workflow

1. Scope the subject and review budget

Choose one subject explicitly:

Whole repository: map all deployable units and critical workflows, then review risk-first across the system.
Subsystem: trace the subsystem's public boundaries, callers, dependencies, persistence, and operational blast radius without auditing unrelated areas.
Diff / pull request: establish the base and head, inspect the commit intent and changed lines, then follow affected callers, contracts, invariants, tests, schemas, configuration, and generated artifacts. Do not turn a diff review into an unsolicited whole-repository audit.
Release: review the accumulated change set plus build, migration, deployment, rollback, compatibility, and operational readiness.

For diff scope, prefer repository-native evidence such as the pull-request metadata, commit log, and git diff <base>...<head>. Confirm the comparison base instead of silently assuming it when competing bases are plausible.

Scale breadth to depth:

Focused: changed behavior and immediate blast radius.
Comprehensive: critical paths, adjacent boundaries, tests, and operational effects.
Release-gate: comprehensive review plus reproducibility, migration, deployment, rollback, security, and residual-risk assessment.

Bound discovery before opening many files. Start with repository guidance, manifests, entry points, the scoped diff or subsystem, and high-risk boundaries. Prefer targeted searches and call-path reads over directory sweeps. If repository size or available context prevents representative coverage, stop expanding breadth, complete the highest-risk paths, and report exactly what remained unreviewed.

2. Discover before judging

Inspect repository guidance, version-control state, top-level structure, manifests, lockfiles, build/test configuration, CI, deployment/release automation, schemas, migrations, and architecture documentation.

Derive rather than assume:

Languages, frameworks, runtimes, package managers, and pinned versions.
Executable entry points and deployable units.
Test levels and their commands.
Persistence and external-service boundaries.
Authentication, authorization, tenant, and trust boundaries.
Critical workflows and authoritative calculation paths.

Record dirty-worktree constraints and do not attribute pre-existing changes to the reviewed work.

3. Build a system map

Trace critical flows end to end:

input -> validation -> domain decisions -> side effects -> persistence -> output

For each stage identify:

Input and output contracts.
Owner/module and dependency direction.
Trust and transaction boundaries.
Validation and failure behavior.
Mutable state, concurrency, retries, and cancellation.
Observability and auditability.
Existing tests.

Distinguish authoritative paths from previews, caches, replicas, exports, client calculations, and duplicated implementations.

4. Extract invariants

Write the properties that must always hold before hunting line-level defects. Derive them from specifications, schemas, tests, UI promises, error models, and domain behavior.

Classify each invariant as Enforced, Partially enforced, Convention only, Violated, or Unknown. Prioritize invariants involving access control, tenant isolation, money, irreversible writes, compatibility, data loss, availability, and externally visible contracts.

5. Review from risk inward

Inspect the highest-consequence paths first. Follow each path across layers rather than finishing one directory at a time.

Use the dimensions in the selected references. In every area ask:

What assumption is being made?
Where is it enforced?
What malformed, stale, missing, duplicated, reordered, concurrent, or adversarial input breaks it?
How does failure surface to users and operators?
Which existing test would catch the regression?

Searches and static heuristics generate hypotheses, not findings. Read surrounding code and callers before reporting them.

6. Review tests as executable claims

Read tests before or alongside implementation. Determine what behavior each test proves and what it merely executes.

Check whether tests:

Assert externally meaningful behavior.
Cover negative, boundary, recovery, and concurrency paths.
Would fail under a plausible regression.
Are deterministic, isolated, and parallel-safe.
Exercise real boundaries at an appropriate test level.
Run in CI under the same assumptions used for release.

Do not equate test count or line coverage with confidence.

7. Execute safe verification

Use repository-documented commands and the narrowest useful checks first. Expand toward build, unit, integration, end-to-end, static analysis, and release checks as scope and environment permit.

Never claim a command passed unless it ran successfully.
Capture the exact command and actionable failure reason.
Separate code failures from environment limitations.
Continue static analysis when execution is blocked.
Do not install dependencies, access networks, mutate databases, launch production workflows, or use secrets without authorization.

For large suites, prefer targeted checks while reviewing, then broader verification when justified.

8. Validate every finding

A reportable finding needs:

A specific violated contract, invariant, or credible failure mode.
Exact evidence: file, symbol, and tight line range when possible.
A reachable trigger or concrete scenario.
User, business, security, or operational impact.
A remediation direction proportionate to the risk.

Trace callers and guards. Search for compensating controls. Reproduce safely or write a minimal test hypothesis when practical.

Label confidence:

Confirmed: reproduced, directly proven, or contradicted by an authoritative contract.
High: complete static path with no plausible unseen guard.
Medium: credible risk with an unresolved assumption.
Question: requires product, domain, or operational confirmation; do not present as a defect.

Do not report speculative lint, generic best practices, or personal style preferences as defects.

9. Rank severity by impact

Critical: reachable security/privacy breach, cross-tenant exposure, material financial error, irreversible data loss, broken release, or severe widespread outage.
High: likely production failure, invalid critical output, authorization bypass, serious reliability gap, or major untested workflow.
Medium: localized correctness issue, risky edge case, testability/maintainability defect with a credible failure path, or operational blind spot.
Low: bounded hardening or clarity improvement with limited immediate impact.

Severity measures impact and likelihood, not code ugliness. Keep certainty separate from severity.

10. Synthesize, do not dump

Lead with findings ordered by severity. Consolidate instances with the same root cause. Separate confirmed findings, testing gaps, architecture risks, questions, and environment limitations.

For comprehensive reviews, include an invariant map, coverage/gap matrix, concrete missing-test backlog, phased remediation plan, and explicit confidence assessment. Use report-template.md.

If no actionable defects are found, say so plainly and still report residual risks and verification limitations.

Review discipline

Prefer one deep causal finding over ten shallow symptoms.
Treat silent fallback as a product decision requiring evidence, especially in critical logic.
Treat duplicated authoritative logic as a divergence risk.
Treat ordering, time, locale, randomness, retries, caches, and shared state as possible hidden inputs.
Check that warnings and logs describe final state rather than an abandoned intermediate state.
Check that observability can distinguish invalid input, domain rejection, dependency failure, and internal defect.
Recommend abstractions only when they enforce an invariant, isolate a side effect, or unlock a valuable test.
Make remediation incremental: immediate containment, regression protection, structural correction, then long-term hardening.

Completion gate

Do not call a deep review complete until you can state:

What the system does and which paths are authoritative.
Which critical invariants are enforced, weak, violated, or unknown.
The highest-impact reachable failures and their evidence.
What was executed versus reviewed statically.
Which important failures current tests and CI would miss.
The smallest practical work that materially improves confidence.