How do I install the Review Defect First skill?

Run npx skillmds@latest add al-janef/review-defect-first 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 Review Defect First 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 Review Defect First?

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 Review Defect First free to use?

Yes. Installing skills from SkillMD is free. This skill is licensed under MIT.

Who published Review Defect First?

AL-JANEF (@al-janef) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Review Defect First by al-janef — Agent Skill

Name: Review Defect First
Rating: 4.2 (5 reviews)
Author: AL-JANEF

Review Defect First

Independent review of a diff, PR, or file that hunts concrete defects introduced by the change: correctness, security, data loss, authorization or tenant escape, production failure, broken contracts, performance regressions, missing critical tests. Severity-ordered findings citing a real code path; no style inflation; "no qualifying defect" is valid. Use for code review and as the independent gate at high risk.

AL-JANEF Updated Sep 22, 2026

File contents

Defect-First Review

A review exists to find concrete, actionable defects introduced by the change. Style preferences, speculative concerns, and unsupported findings are noise; "no qualifying defect found" is a valid, honest result.

Method

Read applicable repository instructions and the complete relevant diff, plus enough surrounding code to trace behavior end to end.
Continue through the whole diff; do not stop at the first finding.
Prioritize: correctness, security, data loss, authorization or tenant escape, production failure, broken contracts, performance regressions, missing critical tests. Then maintainability issues that will cause defects.
Confirm each finding from a real code path, call site, invariant, or test gap. If you cannot point at it, it is not a finding.
Order by severity and cite the smallest useful path and line range.
End with residual risks and material verification gaps only.

The dimension checklist and the forbidden-pattern scan are in references/review-checklist.md.

Severity

Blocking: correctness or security defect, data loss, authorization escape, broken contract.
Should fix: real issue that is not blocking merge.
Consider: hardening or improvement with a concrete benefit.
Verified good: what is demonstrably correct; say so.

Output

## Review: <target>
### Blocking
- <file:line> — <defect> → <fix>  (evidence: <path/test/invariant>)
### Should fix
### Consider
### Verified good
### Residual risk / not verified

Reviewers report; they do not edit. Route security-class findings to vuln-audit for remediation and to variant-hunt to sweep for siblings.

---name: review-defect-firstdescription: Independent review of a diff, PR, or file that hunts concrete defects introduced by the change: correctness, security, data loss, authorization or tenant escape, production failure, broken contracts, performance regressions, missing critical tests. Severity-ordered findings citing a real code path; no style inflation; "no qualifying defect" is valid. Use for code review and as the independent gate at high risk.license: MIT---# Defect-First ReviewA review exists to find concrete, actionable defects introduced by the change. Style preferences, speculative concerns, and unsupported findings are noise; "no qualifying defect found" is a valid, honest result.## Method1. Read applicable repository instructions and the complete relevant diff, plus enough surrounding code to trace behavior end to end.2. Continue through the whole diff; do not stop at the first finding.3. Prioritize: correctness, security, data loss, authorization or tenant escape, production failure, broken contracts, performance regressions, missing critical tests. Then maintainability issues that will cause defects.4. Confirm each finding from a real code path, call site, invariant, or test gap. If you cannot point at it, it is not a finding.5. Order by severity and cite the smallest useful path and line range.6. End with residual risks and material verification gaps only.The dimension checklist and the forbidden-pattern scan are in `references/review-checklist.md`.## Severity- **Blocking**: correctness or security defect, data loss, authorization escape, broken contract.- **Should fix**: real issue that is not blocking merge.- **Consider**: hardening or improvement with a concrete benefit.- **Verified good**: what is demonstrably correct; say so.## Output```## Review: <target>### Blocking- <file:line> — <defect> → <fix> (evidence: <path/test/invariant>)### Should fix### Consider### Verified good### Residual risk / not verified```Reviewers report; they do not edit. Route security-class findings to `vuln-audit` for remediation and to `variant-hunt` to sweep for siblings.

Frequently asked questions