Feat Review

Name: Feat Review
Author: pwdev-solucoes

ASecurity

Use when the user wants a code review of an explicit range or set of files — correctness, security, performance, conventions, tests — with stable findings (CR-nnn, BLOCKER..INFO) and rule citations — 'revisar os últimos commits', 'code review da feature X', 'review base..HEAD'. Plans a REPORT-mode review (no code changes, no commit). Do NOT use to fix code (feat-feature / feat-quick), to write tests (feat-test) or for UI/UX design critique.

3 stars

0 votes

0 copies

0 views

Added 9/28/2026

code-qualitygitsecurityperformance

Security Analysis

A100/100

Pro scans all 2 files and shows the line behind each finding

Scanned 9/28/2026

$npx -y skills add pwdev-solucoes/pwdev-claude-marketplace --skill feat-review --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Feat Review?

Add the live security badge to your README — it updates automatically with every re-scan.

[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/pwdev-solucoes-feat-review/badge)](https://www.skillsdirectory.com/skills/pwdev-solucoes-feat-review)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro

Files

SKILL.md

---
name: feat-review
description: >
  Use when the user wants a code review of an explicit range or set of files — correctness,
  security, performance, conventions, tests — with stable findings (CR-nnn, BLOCKER..INFO) and
  rule citations — 'revisar os últimos commits', 'code review da feature X', 'review
  base..HEAD'. Plans a REPORT-mode review (no code changes, no commit). Do NOT use to fix code
  (feat-feature / feat-quick), to write tests (feat-test) or for UI/UX design critique.
metadata:
  version: 3.2.1
---

# Review plan

Plan type **review** — always executed in **REPORT** mode: findings only, no code change, no
commit. The review contract (scope, finding fields, severities, dimensions, verdict) is
`references/review.md`; read it before planning.

## Procedure

1. **Language** — resolve `lang` (`references/language.md`).
2. **Fix the scope** — resolve the argument into an explicit `BASE..TARGET` range:
   - a feature slug → `base_commit` from its `progress.md`/`plan.done.md` to `HEAD`;
   - "last N commits" → `HEAD~N..HEAD`; a branch → `$(git merge-base main <branch>)..<branch>`;
   - paths only → the range that last touched them, confirmed with the human.
   Record (audit on): `sh "<plugin-root>/scripts/audit-log.sh" event review "" scope <base>..<target>`.
   Build the package: `sh "<plugin-root>/scripts/review_package.sh" <base> <target>
   .planning/feat/features/{slug}/review [-- <paths>]`. Exit 2/3 (bad or empty range) → stop
   and ask; never widen the scope silently.
3. **Method** — follow `references/pwdevia-method.md` with `plan_type: review`:
   - Persona: senior code reviewer for the stack in `context/architecture.md`.
   - §3 lists the package files, the project instructions file, `context/conventions.md`,
     `context/concerns.md` and, when reviewing a feature, its `plan.md`.
   - §4 lists ONLY `.planning/feat/features/{slug}/review.md` (rendered from
     `templates/review-report.md`) — this is what puts the executor in REPORT mode. Do not name it
     `report.md`: some runtimes refuse subagent writes to report-like names.
   - §5: every finding has id, severity, `path:line`, rule citation, evidence and suggestion;
     the five dimensions are covered; lint/test commands run on the target and recorded.
4. After execution, when the verdict is `CHANGES_REQUESTED`, offer to turn the report's fix
   scope into a fix plan (`feat-feature` or `feat-quick`), citing the report in §3.

## Prohibitions

- Never fix code in a review plan, and never list project files in §4.
- Never skip the security dimension.
- Never rate a cosmetic issue above LOW, or a finding without a rule citation above LOW.
- Never move HEAD in the working checkout — use a temporary worktree to inspect other states.

Language: resolve `lang` per `references/language.md` before any human-facing output. Safety: never read or expose `.env*` (except `.env.example`/`.template`/`.sample`), keys, certificates or credentials — `references/safety.md`. Paths `references/`, `scripts/`, `templates/`, `schemas/` are relative to the plugin root (`references/runtime.md`).

Attribution

pwdev-solucoes

View source See grades on GitHub More from pwdev-solucoes →

SSkills DirectorySkills Directory

Ship a skill? Prove it's safe.

Free 120-pattern security scan, letter grade, and an embeddable README badge.

Submit a skill

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments (0)

No comments yet. Be the first to comment!

--- name: feat-review description: > Use when the user wants a code review of an explicit range or set of files — correctness, security, performance, conventions, tests — with stable findings (CR-nnn, BLOCKER..INFO) and rule citations — 'revisar os últimos commits', 'code review da feature X', 'review base..HEAD'. Plans a REPORT-mode review (no code changes, no commit). Do NOT use to fix code (feat-feature / feat-quick), to write tests (feat-test) or for UI/UX design critique. metadata: version: 3.2.1 --- # Review plan Plan type **review** — always executed in **REPORT** mode: findings only, no code change, no commit. The review contract (scope, finding fields, severities, dimensions, verdict) is `references/review.md`; read it before planning. ## Procedure 1. **Language** — resolve `lang` (`references/language.md`). 2. **Fix the scope** — resolve the argument into an explicit `BASE..TARGET` range: - a feature slug → `base_commit` from its `progress.md`/`plan.done.md` to `HEAD`; - "last N commits" → `HEAD~N..HEAD`; a branch → `$(git merge-base main <branch>)..<branch>`; - paths only → the range that last touched them, confirmed with the human. Record (audit on): `sh "<plugin-root>/scripts/audit-log.sh" event review "" scope <base>..<target>`. Build the package: `sh "<plugin-root>/scripts/review_package.sh" <base> <target> .planning/feat/features/{slug}/review [-- <paths>]`. Exit 2/3 (bad or empty range) → stop and ask; never widen the scope silently. 3. **Method** — follow `references/pwdevia-method.md` with `plan_type: review`: - Persona: senior code reviewer for the stack in `context/architecture.md`. - §3 lists the package files, the project instructions file, `context/conventions.md`, `context/concerns.md` and, when reviewing a feature, its `plan.md`. - §4 lists ONLY `.planning/feat/features/{slug}/review.md` (rendered from `templates/review-report.md`) — this is what puts the executor in REPORT mode. Do not name it `report.md`: some runtimes refuse subagent writes to report-like names. - §5: every finding has id, severity, `path:line`, rule citation, evidence and suggestion; the five dimensions are covered; lint/test commands run on the target and recorded. 4. After execution, when the verdict is `CHANGES_REQUESTED`, offer to turn the report's fix scope into a fix plan (`feat-feature` or `feat-quick`), citing the report in §3. ## Prohibitions - Never fix code in a review plan, and never list project files in §4. - Never skip the security dimension. - Never rate a cosmetic issue above LOW, or a finding without a rule citation above LOW. - Never move HEAD in the working checkout — use a temporary worktree to inspect other states. Language: resolve `lang` per `references/language.md` before any human-facing output. Safety: never read or expose `.env*` (except `.env.example`/`.template`/`.sample`), keys, certificates or credentials — `references/safety.md`. Paths `references/`, `scripts/`, `templates/`, `schemas/` are relative to the plugin root (`references/runtime.md`).