code-review
When: you are about to open a PR and need a description reviewers can act on · Input: {{base_branch}} (optional, default main), {{ticket}} (optional), {{notes}} (optional: why, risks) · Output: PR title + Summary / Why / What changed / How to test / Risk and rollback · keywords: pull request, PR description, changelog
0stars
UpdatedNov 1, 2026
v1
Import with the CLI:
ple import ple:zeynepaslierhan/code-review/ecefa1be22 lines
Write the pull request description for the current branch.
Gather facts first; do not write from memory.
- Base branch: {{#if base_branch}}{{base_branch}}{{else}}main (confirm with `git merge-base`){{/if}}. Run `git log --oneline <base>..HEAD` and `git diff <base>...HEAD --stat`, then read the key hunks.
{{#if ticket}}- This work is tracked as {{ticket}}; link it.
{{/if}}{{#if notes}}- Author's notes (treat as intent, verify against the diff): {{notes}}
{{/if}}
Output Markdown with exactly these parts:
**Title**: under 70 characters, imperative mood, names the behavior change and not the files.
## Summary
Two or three sentences: what changes for a user or caller.
## Why
The problem or goal, one short paragraph. If the diff does not reveal it, write "Why: <author to fill>" instead of guessing.
## What changed
Bullets grouped by area, behavior first, files second.
## How to test
The exact commands and the expected result; mention any new test. If nothing automated covers the change, give the manual steps.
## Risk and rollback
What could break, who is affected, and how to revert (feature flag, revert commit, migration down).
Rules: describe what the diff does, not what you would have done. No filler ("This PR..."). Mark anything you inferred as (inferred). Do not claim tests ran unless you ran them.Related prompts
architecture-reviewWhen: a change adds a module, dependency, abstraction or data flow and you want design trade-offs, not bugs · Input: {{diff}} (optional), {{codebase_context}} (optional conventions) · Output: fit rating 1-10 + at most 3 changes ranked by long-term payoff · keywords: architecture review, design review, coupling, abstraction@zeynepaslierhan0pr-reviewWhen: before merging a PR or committing, you want logic bugs and not style nits · Input: {{diff}} (optional, else the agent runs git diff), {{focus}} (optional) · Output: findings table (severity, file:line, failure scenario, fix) + verdict · keywords: code review, PR review, diff, bugs@zeynepaslierhan0