Pr Description
Write a clear, useful PR description — a tight Why / How / Decisions / Callouts structure that tells a reviewer what changed and why, with no filler. Use whenever you open or rewrite a pull request.
Install
$ agentstack add skill-shivaedev-pardes-pr-description ✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.
Security review
✓ PassedNo issues found. Passed automated security review. · v0.1.0 How review works →
- ✓ Prompt-injection patterns
- ✓ Secret / credential exfiltration
- ✓ Dangerous shell & filesystem operations
- ✓ Untrusted network calls
- ✓ Known-malicious package signatures
What it can access
- ✓ Network access No
- ✓ Filesystem access No
- ✓ Shell / process execution No
- ✓ Environment & secrets No
- ✓ Dynamic code execution No
From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.
Verified badge
Passed review? Show it. Paste this badge into your README, it links to the public security report.
Links to your public security report.[](https://agentstack.voostack.com/security/report/skill-shivaedev-pardes-pr-description) Reliability & compatibility
Declared compatibility
Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.
We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.
How agent discovery & health will work →About
pr-description
A good PR description answers three things fast: why does this exist, what did it do, and what should I look at? Use this exact structure, and keep every section short — a reviewer should grasp the change in under a minute.
Title
Meaningful, and about impact — what the change does for the product or system, not how it's implemented. Never a branch name, a file path, or "fix stuff".
Body
Why?
1–3 sentences: the actual problem or motivation. Pull it from the real context; don't invent one. If you genuinely don't know why, find out before opening the PR.
How?
1–2 sentences: a short technical summary for a technical reader — the approach, not a file-by-file walkthrough.
Decisions
One bullet per meaningful tradeoff, abandoned alternative, or scope choice — each with the reason. N/A if there were none.
Callouts
One bullet per spot a reviewer should look harder at — risky surfaces, things that look innocuous but have knock-on effects, one-way doors. Callouts — N/A if everything is straightforward.
Never include
- Files-changed lists — the diff already shows them.
- Test plans or "how I tested" narration.
- Risk speculation and hedging.
- Diff narration — restating the code change in prose.
That's it: an honest title, four short sections, and nothing the diff already says.
Source & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- Author: ShivaeDev
- Source: ShivaeDev/pardes
- License: MIT
Install and usage instructions live in the source repository linked above.
Reviews
No reviews yet, be the first.
Write a review
Versions
- v0.1.0 Imported from the upstream source.