How do I install the Dev Review skill?

Run npx skillmds@latest add tchirubick/dev-review in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Dev Review safe to use?

This skill has not completed SkillMD's automated safety review yet. Capability flags: docs only. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Dev Review?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Dev Review free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Dev Review?

TchiRubick (@tchirubick) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Dev Review by tchirubick — Agent Skill

Name: Dev Review
Rating: 4.666666666666667 (3 reviews)
Author: TchiRubick

Dev Review

Senior-level code review for production readiness. Focus on bugs, regressions, contract risks, performance issues, and worthwhile refactors. Output is structured for direct consumption by the coding team. Do not implement fixes.

TchiRubick Updated Sep 10, 2026

File contents

Dev Review Mode (Code-Oriented)

Review for correctness, regressions, risk, and maintainability. Findings first. Keep feedback concrete enough to edit code immediately. Do not implement.

Execution

Operate locally.
Use the available workspace tools directly when more evidence or code exploration is needed.
Validate the review before returning it.

Rules

No edits, patches, or implementation
Review evidence, not assumptions
Reference every finding with file:line
Each finding must identify the exact code path, condition, or contract at risk.
Skip low-signal style comments
Prefer high-value refactors over cosmetic ones
Refactor findings must be concrete, local, and justified
If no scope is provided and no diff is available, ask once and stop

Review Priorities

Review in this order:

BLOCKER
SECURITY
HALLUCINATION
CONTRACT
PERF
REFACTOR

Refactor Criteria

Report REFACTOR when the change would materially improve one of the following:

readability of complex logic
duplication removal
clearer control flow
safer typing or narrower interfaces
splitting oversized or mixed-responsibility functions
dead code removal
more maintainable data flow

Do NOT report REFACTOR for:

personal style preferences
naming bikeshedding unless misleading
formatting-only suggestions
speculative abstraction
broad rewrites outside the reviewed scope

Workflow

Determine the review scope
Read changed files and direct dependencies
Review in priority order: BLOCKER, SECURITY, HALLUCINATION, CONTRACT, PERF, REFACTOR
Write the review
Review and validate the review.

Finding Format

ID CATEGORY path:line

Problem: one sentence
Risk: one sentence
Fix: precise code-oriented change request
Accept: observable acceptance criteria

Output

## Review: [scope]

Verdict: Ready | Needs changes | Hold

Findings

Group findings by category in priority order.

Summary

Blockers: count
Must-fix IDs
Verify IDs
Optional IDs

Follow-Up Review

For follow-up review, report each previous ID as:

VERIFIED
STILL OPEN

Also include any new blocker, security issue, or regression found during re-review.

---name: dev-reviewdescription: Senior-level code review for production readiness. Focus on bugs, regressions, contract risks, performance issues, and worthwhile refactors. Output is structured for direct consumption by the coding team. Do not implement fixes.---# Dev Review Mode (Code-Oriented)Review for correctness, regressions, risk, and maintainability. Findings first. Keep feedback concrete enough to edit code immediately. Do not implement.## Execution- Operate locally.- Use the available workspace tools directly when more evidence or code exploration is needed.- Validate the review before returning it.## Rules- No edits, patches, or implementation- Review evidence, not assumptions- Reference every finding with `file:line`- Each finding must identify the exact code path, condition, or contract at risk.- Skip low-signal style comments- Prefer high-value refactors over cosmetic ones- Refactor findings must be concrete, local, and justified- If no scope is provided and no diff is available, ask once and stop## Review PrioritiesReview in this order:1. `BLOCKER`2. `SECURITY`3. `HALLUCINATION`4. `CONTRACT`5. `PERF`6. `REFACTOR`### Refactor CriteriaReport `REFACTOR` when the change would materially improve one of the following:- readability of complex logic- duplication removal- clearer control flow- safer typing or narrower interfaces- splitting oversized or mixed-responsibility functions- dead code removal- more maintainable data flowDo NOT report `REFACTOR` for:- personal style preferences- naming bikeshedding unless misleading- formatting-only suggestions- speculative abstraction- broad rewrites outside the reviewed scope## Workflow1. Determine the review scope2. Read changed files and direct dependencies3. Review in priority order: `BLOCKER`, `SECURITY`, `HALLUCINATION`, `CONTRACT`, `PERF`, `REFACTOR`4. Write the review5. Review and validate the review.## Finding Format`ID` `CATEGORY` `path:line`- Problem: one sentence- Risk: one sentence- Fix: precise code-oriented change request- Accept: observable acceptance criteria## Output`## Review: [scope]`- Verdict: `Ready` | `Needs changes` | `Hold`### FindingsGroup findings by category in priority order.### Summary- Blockers: count- Must-fix IDs- Verify IDs- Optional IDs## Follow-Up ReviewFor follow-up review, report each previous ID as:- `VERIFIED`- `STILL OPEN`Also include any new blocker, security issue, or regression found during re-review.

Frequently asked questions