agentsclimarketplace

Code review

Skill aman-bhandari/claude-code-agent-skills-framework/.claude/skills/code-review

Research scaffold for AI engineering with Claude Code. 15 rule files (4 WHY-tagged pilot), 21 skills, concentric-loop pedagogy, rule-obsolescence audit framework.

Install
npx -y skills add aman-bhandari/claude-code-agent-skills-framework --skill code-review

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

Deep coach-style code review of code the student wrote. Triggers on /review or REVIEW prefix. Checks understanding first (why decisions were made), then correctness, then all standards (type hints, error handling, no print, meaningful names, docstrings, edge cases), then production thinking. Never rewrites code -- points to problems, the student fixes them.

SKILL.md

2.4 KB, as published. Nobody here has run it

Code Review -- Coach Mode

Not just correctness. Understanding, production-readiness, and growth.

Trigger

  • /review or REVIEW: prefix
  • After the student says they're done with an exercise

Execution

  1. Read the file the student wants reviewed.

  2. Understanding check (always first -- before looking at code quality):

    • "Walk me through what this code does, line by line."
    • "Why did you choose [specific pattern]?"
    • "What happens if [edge case]?"
    • If the student can't explain their own code → stop. Understanding first, review second.

  3. TDD compliance:

    • Does test_*.py exist? Were tests written FIRST?
    • Do tests cover happy path, edge case, and error case?
    • Do all tests pass?

  4. Correctness:

    • Does it run? Expected output?
    • Edge cases handled?
    • Error paths covered?

  5. Standards compliance (ALL enforced, always):

    • Type hints on every function signature
    • Proper error handling (never bare except, catch specific exceptions)
    • No print() statements (use logging or structlog)
    • Meaningful variable names (not x, data, result, temp)
    • Docstrings on public functions
    • Edge cases considered and handled

  6. Production thinking:

    • "What breaks if the input is 10x larger?"
    • "What happens when the network/filesystem is unavailable?"
    • "How would you test this?"
    • "Where would you add monitoring?"

  7. Feedback format:

    • 1-2 things done well (specific, not generic praise)
    • 1-2 things to improve (specific line references)
    • 1 challenge question (pushes thinking deeper)
    • Concepts to add to spaced review deck
    • If a concept or pattern emerged worth preserving → suggest brainstorm into wiki

Rules

  • Never rewrite code. Point to the problem, the student fixes it.
  • Ask WHY before saying WHAT's wrong. Understanding > correctness.
  • If the same mistake appears twice across sessions, escalate: "This is a pattern. What's the root cause?"
  • Connect feedback to production and market: "An interviewer would flag this."

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.