prose-review

Review added comments, docstrings, and changelog entries for change-narration instead of code documentation.

15.1k|2.6k|Updated Dec 27, 2023
One-click install
npx skills add https://github.com/pipecat-ai/pipecat --skill prose-review
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: prose-review
Source: https://github.com/pipecat-ai/pipecat/tree/main/.claude/skills/prose-review
Command: npx skills add https://github.com/pipecat-ai/pipecat --skill prose-review

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Code comments and docstrings often narrate the change that produced them — what the code used to do, which alternatives were rejected, or that a fix was verified — which is invisible or misleading context for future readers who only see the code as it stands.

Core Features & Use Cases

  • Scoped Diff Review: Reviews only added lines (^\+) in comments, docstrings, and changelog content, with selectable scopes: staged changes, the full branch against the merge base, or a specific path.
  • Narration Detection: Flags prose that describes old behavior, argues correctness, records verification, names rejected alternatives, or merely restates what the adjacent code already shows.
  • Guided Remediation: Provides concrete rewrite examples and a remediation table covering amending commits, squashing, force-pushing, and editing PR descriptions depending on commit state.
  • Use Case: Before opening a pull request, run the review on your branch to catch comments like "We used to buffer here, but that broke interruptions" and rewrite them to describe the code as it now stands.

Quick Start

Ask the assistant to run the prose review on the current branch to check that all added comments and docstrings document the code rather than narrate the change.

Frequently Asked Questions about prose-review

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

FAQPage Schema
How do I review code comments before opening a pull request?

Run the prose review on your branch scope, which diffs against the merge base with main and covers both committed and uncommitted work. It checks only added comment, docstring, and changelog lines and reports each violation as file:line with a suggested rewrite.

What kinds of comments should be removed from code?

Remove comments that describe what the code used to do, argue the change is correct, record that it was tested, name rejected alternatives, or restate what the adjacent code already shows. Keep rationale only when its absence would puzzle a future reader.

Does the review check existing comments or only new ones?

Only added lines in the diff are reviewed; untouched prose is explicitly out of scope. The branch and path scopes diff against the merge base, so prose written moments ago in uncommitted work is still covered.

Are words like 'previously' or 'no longer' always flagged?

No, the review does not pattern-match on those words since they appear constantly in correct prose. It judges the sentence's subject: legitimate prose describes the code as it stands, while violations narrate the change that produced it.

How do I fix flagged comments that are already committed?

If commits are unpushed, edit the files and amend a single commit or squash several commits. If already pushed without a PR, fix and force-push with --force-with-lease; if the PR is under review, use a follow-up commit instead of rewriting history.