leaving-pr-comments
Write actionable GitHub comments
Leave clear, readable GitHub comments with enough context to act on.
Ask your agent
leave a PR commentStart a new session after installing, then use this command in your project.
How it works
- Read the context
- explain the finding
- post a useful comment
Install leaving-pr-comments
Pick your harness and how you want to install. Copy the commands, then ask for a skill by name.
Claude Code / all projects
npx skills add 0libote/ostack --agent claude-code --global --skill leaving-pr-commentsUses the skills CLI. Requires Node.js and npm; installs the skills listed in the command.
Available across your projects. Start a new agent session after installing.
Read the skill instructions
The full SKILL.md, as shipped in this collection. Supporting files are in the source repository.
---
name: leaving-pr-comments
description: Use whenever leaving comments on GitHub.
---
# Leaving PR Comments
Prefix every agent-authored comment left on the user's behalf with this GitHub
note callout:
```md
> [!NOTE]
> 🤖 **<model> responding on behalf of <user>**
Actual comment starts here.
```
Use the verified public name of the model that wrote the comment, and the
user's name or GitHub login.
If the harness does not expose a model name, use the harness name. Do not guess.
Before posting, check the entire comment, including quoted text and
attachments, for secrets and private details.
Keep the attribution inside the note and the actual reply outside it. The
context line must start with the robot emoji. Do not add a horizontal rule,
Setext underline, heading, signature footer, or a second attribution.
Apply this format to top-level PR comments, inline review comments, replies to
bots or reviewers, and written explanations used before resolving or
dismissing feedback. Do not add it to PR descriptions, commit messages, or text
the user explicitly asked to post verbatim without attribution.
Write the comment itself in a direct style:
- Lead with the conclusion.
- Cite the relevant code, behavior, check, or reproduction.
- Keep it concise and avoid filler, canned thanks, or status narration.
- Distinguish verified facts from judgment.
Preview the final Markdown before posting so quoting and blank lines render as
shown. After posting, verify that GitHub returned the comment or review URL.
Resolve a review thread only after its response was posted successfully.