Install
$ agentstack add skill-varnan-tech-opendirectory-explain-this-pr ✓ 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.
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
Explain This PR
Read a GitHub pull request, understand what it changes, and write a plain-English explanation. Post it as a PR comment so reviewers have instant context.
Step 1: Check Setup
Confirm gh is authenticated:
gh auth status
If not authenticated: gh auth login and follow the prompts.
Confirm input. The user must provide one of:
- A GitHub PR URL (e.g.
https://github.com/owner/repo/pull/123) - A PR number in the current repo (e.g.
#123) - The keyword "current" to use the PR for the current branch
If no input, ask: "Which PR should I explain? Share the URL, PR number, or say 'current' for the active branch."
Step 2: Fetch PR Context
Get PR metadata:
gh pr view PR_URL_OR_NUMBER --json number,url,title,body,author,baseRefName,headRefName,additions,deletions,changedFiles,commits,labels,state,isDraft
If isDraft is true, note this to the user: "This PR is still in draft. The explanation is based on its current state."
Get the diff:
gh pr diff PR_URL_OR_NUMBER
If the diff is over 400 lines, read the --stat summary and the first 200 lines of the diff:
gh pr view PR_URL_OR_NUMBER --json files
gh pr diff PR_URL_OR_NUMBER | head -200
Get existing comments (to avoid repeating what is already there):
gh pr view PR_URL_OR_NUMBER --json comments --jq '.comments[].body' 2>/dev/null | head -20
Step 3: Write the Explanation
Write two paragraphs. Read each rule before writing.
Paragraph 1: What it does (technical)
- One sentence per major change
- Name the specific files, functions, or systems that changed
- State the before/after if the diff makes it clear
- Include concrete numbers if present in the diff (lines removed, tables dropped, endpoints added)
- Active voice, present tense
Example:
Replaces the in-memory session cache in auth.middleware.ts with a Redis-backed cache (src/cache/redis.ts). Adds get, set, and invalidate methods to the new Redis module and wraps UserService.getById() with a 5-minute TTL. Removes the Map-based cache that was limited to a single process and caused session drift across multiple instances.
Paragraph 2: Why it matters (business/product impact)
- Who benefits and how
- What problem this solves or what risk it reduces
- If the commit messages contain a "why", use that context
- If there is no clear "why" in the diff or commits, omit this paragraph rather than guessing
Example:
Users hitting the /api/me endpoint under load were getting inconsistent session data across server instances, causing intermittent 401 errors. This change makes session state consistent across all instances and reduces database load by eliminating one query per authenticated request.
Rules for both paragraphs:
- No em dashes — use a comma or period
- No filler: "this PR", "this change", "as you can see"
- No invented outcomes. Only state impacts that are directly visible in the diff or commit messages
- If the PR is a pure refactor with no behavior change, say that explicitly: "Refactors X to Y with no change in observable behavior."
- Under 150 words total
Step 4: Self-QA
Before posting, check:
- [ ] Paragraph 1 names specific files or functions from the diff
- [ ] No invented metrics or outcomes
- [ ] No em dashes
- [ ] No filler phrases
- [ ] Under 150 words total
- [ ] If no clear "why" exists, paragraph 2 is omitted rather than guessing
Fix any violation before posting.
Step 5: Post as PR Comment
Present the explanation to the user. Ask: "Ready to post this as a PR comment, or would you like to edit it first?"
On confirmation, pass the body via stdin to handle backticks, quotes, and newlines safely:
gh pr comment PR_URL_OR_NUMBER --body-file - << 'EOF'
EXPLANATION_HERE
EOF
After posting: "Comment added. View it at: [url from Step 2]"
If the user says "output only", present the explanation in a code block for manual copy-paste without posting.
Source & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- Author: Varnan-Tech
- Source: Varnan-Tech/opendirectory
- License: MIT
- Homepage: https://www.opendirectory.dev
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.