agentsclimarketplace

Code review judgment

Skill pinkstrokes/self-distillation/skills/code-review-judgment

Reusable agent skills for distilling narrow human capabilities into tested behavior

Install
npx -y skills add pinkstrokes/self-distillation --skill code-review-judgment

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

2 things to look at

  • 28 days oldThe repository was created 28 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
  • 1 stars1 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

Use when reviewing code, diffs, architecture, tests, security, data safety, maintainability, PRs, regressions, false positives, missing tests, or review comments where correctness and risk judgment matter.

SKILL.md

3.9 KB, as published. Nobody here has run it

Code Review Judgment

Review behavior risk, not taste. Prioritize correctness, security, data loss, regressions, and test gaps.

Workflow

  1. Identify change surface: behavior, data path, user path, API contract, tests.
  2. Find evidence-backed defects: logic, security, data loss, concurrency, migration, performance, contract, or regression-test risk.
  3. Separate findings from questions, preferences, and non-issues.
  4. Rank findings exactly P0, P1, P2, or P3.
  5. Include location, evidence, impact, and fix direction. If none exist, name residual test gaps.

Output Contract

Return findings first:

Findings:
Severity:
Location:
Evidence:
Impact:
Fix direction:
Missing tests:
Non-issues:
Open questions:
Verdict:

Verdict: complete, partial, fail, or insufficient evidence.

Exact labels: findings use only P0, P1, P2, or P3. No-finding reviews use Severity: not applicable exactly. Verdict line must contain only one lowercase verdict token, no punctuation.

Red Lines

  • Do not lead with style over correctness, security, data, or test risk.
  • Do not invent bugs or flag preference-only rewrites.
  • Do not use severity labels outside P0-P3, except not applicable for no findings.
  • Tie each missing test to a behavior risk.
  • Do not ignore tenant, auth, permission, payment, migration, or delete/update paths.
  • Do not require unrelated tests for a narrow safe change.
  • Make ambiguous external behavior an open question, not a defect.
  • Do not upgrade auth bugs to P0 without sensitive exposure, dangerous action, data loss, or outage evidence.
  • Do not erase tenant-owned write risk because ids are globally unique or hard to guess.
  • Do not treat upstream access tests as same-boundary proof after a tenant predicate is removed.
  • Do not treat unproven external contracts as safe when changed code relies on them.

Severity Rules

P0: likely data loss, security exposure, payment corruption, irreversible migration failure, or outage.

P1: high-confidence bug, auth/permission bypass, broken critical workflow, or missing test for risky change.

P2: non-critical regression, edge bug, maintainability issue with realistic failure mode, or important missing test.

P3: low-risk cleanup, clarity issue, small test gap, or non-blocking maintainability note.

Auth: inverted auth guard is P1 when protected code still expects a user. It becomes P0 only with sensitive exposure, destructive action, payment impact, or outage evidence. It is not a finding when an explicit guest-only contract and tests match.

Tenant writes: removing tenant scope from tenant-owned write/delete/update paths is a finding. Global id uniqueness can affect severity, not erase it. Downgrade to no finding only when the same write boundary or immediate wrapper enforces tenant isolation and has cross-tenant write/delete tests. Upstream access tests alone still leave at least P2/partial.

External contracts: if changed code relies on third-party retries, ordering, idempotency, auth, or consistency, missing docs/wrapper contract/tests is P2 by default. Do not claim the third party is broken without evidence.

Verdict Rules

fail: P0/P1 finding or release-blocking risk.

partial: P2/P3 finding, meaningful test gap, or bounded uncertainty.

complete: no evidence-backed findings and adequate coverage.

insufficient evidence: required context is missing and judgment would invent facts.

Before Final Answer

Check:

  • Is every finding tied to code evidence?
  • Are severity labels exact?
  • Did style stay below behavior risk?
  • Are non-issues separated from findings?
  • Are missing tests tied to specific behavior?
  • Are severity and verdict labels exact?

Gives 0 of the 12 instructions most code review skills give

Counted across 610 of the 674 authors here whose files we hold, read 2026-08-06

  • push back with technical reasoning if wrongin 60 of 610, across 24 files
  • ask for clarification on unclear itemsin 51 of 610, across 16 files
  • fix critical issues immediatelyin 45 of 610, across 29 files
  • implement one item at a timein 45 of 610, across 11 files
  • group findings by severityin 44 of 610, across 43 files
  • verify feedback against the codebasein 42 of 610, across 8 files
  • dispatch a code reviewer subagentin 39 of 610, across 23 files
  • fix important issues before proceedingin 37 of 610, across 22 files
  • test each fix individuallyin 35 of 610, across 7 files
  • reply in github comment threadsin 33 of 610, across 5 files
  • check for security vulnerabilitiesin 31 of 610, across 27 files
  • factualize corrections without over-explainingin 30 of 610, across 2 files

Said here and by no other author read

  • find evidence-backed defects
  • rank findings using p0 through p3
  • tie each missing test to a specific behavior risk
  • separate findings from non-issues
  • ensure every finding includes location, evidence, impact, and fix direction
  • assign exact verdicts using one lowercase token

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.