leaving-gh-comments
Skill1 starsChanged 14 days agoMITView on GitHub
Formats comments an agent posts on GitHub on the user's behalf, with attribution and a secrets check. Use when posting, replying to, or resolving GitHub issue, PR, or review comments.
In this repository27 other files it gives its agents.
- AGENTS.mdAGENTS.md
- golang-tui-update-examplesSkill
- upstream-syncSkill
- apply-worktreeSkill
- babysit-prSkill
- documentation-writerSkill
- file-prSkill
- frontend-designSkill
- golang-packagesSkill
- golangSkill
- golang-tuiSkill
- grill-meSkill
- karpathy-guidelinesSkill
- kubernetes-specialistSkill
- kubernetes-upgrade-analysisSkill
- mermaid-diagramsSkill
- modernizeSkill
- nuclear-reviewSkill
- remotion-best-practicesSkill
- reviewSkill
- security-auditSkill
- shadcn-vueSkill
- sharpenSkill
- simplifySkill
- tui-designSkill
- unslopSkill
- writing-for-agentsSkill
The file
We split this skill into the rules it gives an agent
3 rules. About 0 are common, 3 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 27
Start every comment with exactly one attribution line, then a blank line, then the comment:
- Distinctive: line 46
Keep it to the substance, without thanks or status narration.
- Distinctive: line 51
Check the whole comment, including quoted text and attachments, for secrets and private details.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Leaving GitHub Comments
Scope
Applies to top-level issue and PR comments, inline review comments, replies to bots or reviewers, and written explanations posted before resolving or dismissing feedback. PR descriptions, commit messages, and text the user asked to post verbatim without attribution are out of scope.
Attribution line
Start every comment with exactly one attribution line, then a blank line, then the comment:
🤖 *<model> responding on behalf of <user>*
Actual comment starts here.<model>is the verified public name of the model that wrote the comment. If the harness exposes none, use the harness name instead of guessing.<user>is the user's name or GitHub login.- The attribution line is the comment's only header and only signature: plain text after it, with no heading, horizontal rule, Setext underline, or footer.
Body
- Lead with the conclusion.
- Cite the relevant code, behavior, check, or reproduction.
- Keep it to the substance, without thanks or status narration.
- Mark which statements are verified and which are judgment.
Posting
- Check the whole comment, including quoted text and attachments, for secrets and private details. The comment itself says nothing about this check.
- Reread the final Markdown so quoting and blank lines render as intended.
- Post it. Done when GitHub returns the comment or review URL.
- Resolve a review thread only after its reply has posted.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.