ptp-receiving-code-review

Validates code review findings against current repository content before applying fixes.

Updated Jun 8, 2026
One-click install
npx skills add https://github.com/AlmogMaayan/ptp --skill ptp-receiving-code-review-almogmaayan
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: ptp-receiving-code-review
Source: https://github.com/AlmogMaayan/ptp/tree/main/skills/ptp-receiving-code-review
Command: npx skills add https://github.com/AlmogMaayan/ptp --skill ptp-receiving-code-review-almogmaayan

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Code review feedback often contains false positives, stale findings, or unverifiable claims, and acting on them blindly wastes effort and introduces regressions. This Skill enforces a disciplined verdict process so only confirmed findings lead to code changes. ## Core Features & Use Cases - Evidence-Based Verdicts: Every finding is judged as CONFIRMED or REJECTED only after reading the current content at the cited location. - Structured Rejection Reasons: Rejections carry explicit reasons such as stale, unverifiable, or yagni, preventing vague dismissals. - Minimal Targeted Fixes: Only confirmed findings are fixed, one at a time, at the cited location, followed by re-running the relevant verification. - Use Case: After an automated or peer review emits a list of findings on a pull request, use this Skill to verify each finding against the actual code, reject the false positives with reasons, and fix only what is genuinely broken. ## Quick Start Ask the assistant to evaluate the review findings emitted by the requesting-code-review step and fix only the confirmed ones.

Frequently Asked Questions about ptp-receiving-code-review

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I handle code review findings before making changes?▼

Read the current content at each cited location first, then issue a CONFIRMED or REJECTED verdict. Fix only confirmed findings, minimally and one at a time, and re-run the relevant verification after each fix.

What should I do with false positive code review findings?▼

Reject false positives with a reason naming what was checked, such as the cited content already being correct or the reviewer misreading intent. Never edit code on account of a finding that was not confirmed.

How are stale or outdated review findings handled?▼

A finding whose cited location no longer holds the cited content is rejected with the reason stale. This happens when the issue was already fixed or the code was moved before the review was processed.

What happens when a review finding cannot be verified?▼

An unverifiable finding is rejected with the reason unverifiable plus a note on what could not be checked. The process never pauses for a human partner and never confirms a finding on assumption.

When should a requested capability be rejected as unnecessary?▼

Reject a request for unused capability with the reason yagni, citing evidence that nothing in the repository uses it. This prevents adding speculative code that has no actual consumer.