agentleFS
Sign inStart free
lyh843lyh843/AgentSkills/skills/review-agent/SKILL.md

review-agent

Skill1 starsChanged 5 months agoMITView on GitHub

Perform a read-only, defect-first review of a specified code change and return every actionable finding. Use when another agent delegates review of uncommitted changes, a base-branch diff, a commit, or custom review instructions.

We split this skill into the rules it gives an agent

7 rules. 0 are common, 6 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 8 edited versions we read keep these.

  • 6

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Do not modify files, create commits, push branches, post review comments, or delegate the review to another agent.

    line 9
  2. Distinctive:

    Read the applicable AGENTS.md instructions.

    line 14
  3. Distinctive:

    Check the relevant tests and call sites to confirm that each finding is real and actionable.

    line 19
  4. Distinctive:

    Do not flag speculative concerns, pre-existing problems, intentional behavior changes, or style nits that do not obscure the code.

    line 36
  5. Distinctive:

    Follow the title with one short paragraph explaining the affected scenario and why the behavior is wrong.

    line 45
  6. Very specific:

    If there are no qualifying findings, say No findings.

    line 55
  7. Distinctive:

    After the findings, add a brief overall assessment and mention any material test gaps or residual risks.

    line 56

“Common” is measured: kept by at least 6 in 10 of the 8 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Review Agent

Inspect the requested target directly and return every finding that the author would likely fix. Do not modify files, create commits, push branches, post review comments, or delegate the review to another agent.

Review the change

  1. Read the applicable AGENTS.md instructions.
  2. Inspect the complete diff for the requested target and enough surrounding code to understand each changed path.
  3. Identify concrete regressions introduced by the change. Continue through the whole diff after finding the first issue.
  4. Check the relevant tests and call sites to confirm that each finding is real and actionable.

For a base-branch review, compare the changes that would actually merge rather than diffing directly against the branch tip. Resolve the comparison ref to the branch's upstream when that upstream exists and is ahead of the local branch; otherwise use the local branch. Run git merge-base HEAD <comparison-ref>, then inspect git diff <merge-base-sha>. If the local branch cannot be resolved, try its configured upstream explicitly before reporting that the target is unavailable.

Flag an issue only when all of these are true:

  • It affects correctness, security, performance, or maintainability in a meaningful way.
  • It is discrete and actionable.
  • It was introduced by the reviewed change.
  • The affected scenario or call path can be demonstrated from the code.
  • The author would probably fix it if they knew about it.

Do not flag speculative concerns, pre-existing problems, intentional behavior changes, or style nits that do not obscure the code.

Write the result

Present findings first, ordered by severity. Use one entry per issue in this form:

[P1] Imperative finding title — path/to/file.rs:line

Follow the title with one short paragraph explaining the affected scenario and why the behavior is wrong. Keep the cited range as small as possible and make sure it overlaps the reviewed diff.

Use these priorities:

  • P0: universal release blocker or critical failure.
  • P1: urgent defect that should be fixed next.
  • P2: ordinary defect that should be fixed.
  • P3: low-impact issue that is still worth fixing.

If there are no qualifying findings, say No findings. Do not invent a finding to fill the result. After the findings, add a brief overall assessment and mention any material test gaps or residual risks.

Download now (ZIP)

Trending

Steady: 0 new projects took it in the last 4 weeks, none the 4 weeks before.thin data

Week of Aug 30: 0 new projectsWeek of Sep 6: 0 new projectsWeek of Sep 13: 0 new projectsWeek of Sep 20: 0 new projectsWeek of Sep 27: 0 new projectsWeek of Oct 4: 0 new projectsWeek of Oct 11: 0 new projectsWeek of Oct 18: 0 new projects
Aug 2026Sep 2026Oct 2026
New projects taking a version of this file each week, over the 8 weeks our latest run read: only 0 in all, so this is a hint, not a trend.

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free