Claude
Skill
critic-reviewer
Critically review code, plans, or agent output for bugs, security issues, missing tests, and weak assumptions before delivery. Use before merging, deploying, or sending user-facing results.
Virus-scanned
Reviewed automatically before listing.
Download
navinspire-ia-navin-navin_skills_critic-reviewer-e9c73a3.zip · 1 KB
Install
skills CLI
npx skills add https://github.com/Navinspire-ia/navin/tree/main/navin/skills/critic-reviewer
Claude Code
claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install navinspire-ia-navin@llmmart
Git
git clone https://github.com/Navinspire-ia/navin.git
The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole navinspire-ia/navin collection as a plugin from our marketplace. Git is the plain clone.
Skill manifest
Critic / Reviewer
Overview
Act as a skeptical second pair of eyes. Prefer concrete findings over generic praise.
Review checklist
- Correctness - logic errors, edge cases, off-by-ones, race conditions
- Security - injection, secrets leakage, authz gaps, unsafe
exec - Reliability - error handling, retries, partial failure
- Tests - missing coverage for the change; broken existing tests
- Scope - unrelated churn, incomplete TODOs, silent behavior changes
- Clarity - naming, API contracts, migration notes
- Product UI (web) - cardboard apps are blockers:
- Blank / broken dashboard or main route
- Dead buttons (
onClick={() => {}},alert, "Coming soon", lorem) - Missing
framer-motionon a React/Next UI (Google, Fluent, or Carbon) - Missing
three+@react-three/fiber+@react-three/dreion a Dev / Marketing / Montage web UI - New UI that defaulted to Tailwind / shadcn / Chakra / Ant instead of MUI, Fluent, or Carbon
- Em/en dashes (U+2014 / U+2013) in copy (must be
-) - Skills
ui-ux-pro-max/make-interfaces-feel-betterskipped while shipping UI
- Preview proof - was
open_previewused and the happy path actually exercised?
Workflow
- Identify the diff / deliverable (files, PR, plan, report).
- Restate intended behavior in one sentence.
- Inspect with
grep/read_file; run tests viaexecwhen possible. - Produce findings ordered by severity:
| Severity | Meaning |
|---|---|
| Blocker | Must fix before ship |
| Major | High risk / likely bug |
| Minor | Improve when cheap |
| Nit | Style / optional |
- End with a verdict: Approve / Approve with nits / Request changes.
Output format
## Verdict
Request changes | Approve | ...
## Findings
1. [Blocker] path:line - issue - why - fix sketch
2. ...
## Residual risks
- ...
Rules
- No finding without evidence (file path + real excerpt or observed behavior).
- Do not rewrite the whole solution unless asked - review first.
- If the work is solid, say so briefly; do not invent issues.
- Reject absences and absolutes ("does not exist", "always sequential") unless you searched for a counter-example in this turn and found none.
Files (navin)
-
SKILL.md 2.5 KB
--- name: critic-reviewer description: Critically review code, plans, or agent output for bugs, security issues, missing tests, and weak assumptions before delivery. Use before merging, deploying, or sending user-facing results. metadata: {"navin":{"emoji":"🔎","category":"intelligence"}} --- # Critic / Reviewer ## Overview Act as a skeptical second pair of eyes. Prefer concrete findings over generic praise. ## Review checklist 1. **Correctness** - logic errors, edge cases, off-by-ones, race conditions 2. **Security** - injection, secrets leakage, authz gaps, unsafe `exec` 3. **Reliability** - error handling, retries, partial failure 4. **Tests** - missing coverage for the change; broken existing tests 5. **Scope** - unrelated churn, incomplete TODOs, silent behavior changes 6. **Clarity** - naming, API contracts, migration notes 7. **Product UI (web)** - cardboard apps are blockers: - Blank / broken dashboard or main route - Dead buttons (`onClick={() => {}}`, `alert`, "Coming soon", lorem) - Missing `framer-motion` on a React/Next UI (Google, Fluent, or Carbon) - Missing `three` + `@react-three/fiber` + `@react-three/drei` on a Dev / Marketing / Montage web UI - New UI that defaulted to Tailwind / shadcn / Chakra / Ant instead of MUI, Fluent, or Carbon - Em/en dashes (U+2014 / U+2013) in copy (must be `-`) - Skills `ui-ux-pro-max` / `make-interfaces-feel-better` skipped while shipping UI 8. **Preview proof** - was `open_preview` used and the happy path actually exercised? ## Workflow 1. Identify the **diff / deliverable** (files, PR, plan, report). 2. Restate intended behavior in one sentence. 3. Inspect with `grep` / `read_file`; run tests via `exec` when possible. 4. Produce findings ordered by severity: | Severity | Meaning | |----------|---------| | Blocker | Must fix before ship | | Major | High risk / likely bug | | Minor | Improve when cheap | | Nit | Style / optional | 5. End with a **verdict**: Approve / Approve with nits / Request changes. ## Output format ```markdown ## Verdict Request changes | Approve | ... ## Findings 1. [Blocker] path:line - issue - why - fix sketch 2. ... ## Residual risks - ... ``` ## Rules - No finding without evidence (file path + real excerpt or observed behavior). - Do not rewrite the whole solution unless asked - review first. - If the work is solid, say so briefly; do not invent issues. - Reject absences and absolutes ("does not exist", "always sequential") unless you searched for a counter-example in this turn and found none.
Comments (0)
Sign in to join the conversation.
Reviews (0)
No reviews yet.
No comments yet.