agentleFS
Sign inStart free
saffron-healthsaffron-health/opencode-gui/.agents/skills/address-review/SKILL.md

address-review

Skill59 starsChanged 9 months agoMITView on GitHub

Address PR review comments systematically. Use when responding to code review feedback on a pull request.

We split this skill into the rules it gives an agent

9 rules. 0 are common, 8 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 18 edited versions we read keep these.

  • 8

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Get review comments: Use gh api graphql to fetch all review threads and comments for the PR.

    line 10
  2. Distinctive:

    Verify the changes fix the issue raised

    line 16
  3. Distinctive:

    Add explanatory comments if the reviewer requested clarification

    line 17
  4. Distinctive:

    Test changes to ensure they don't break existing functionality

    line 18
  5. Distinctive:

    Quality assurance: Run type-check, build, and lint to ensure all changes are correct

    line 20
  6. Distinctive:

    Only address reviews from human users.

    line 38
  7. Distinctive:

    Use sub-agents to handle independent review comments in parallel when possible

    line 39
  8. Distinctive:

    Always verify changes don't introduce new issues

    line 40
  9. Distinctive:

    If a review comment requires clarification, document the approach taken

    line 41

“Common” is measured: kept by at least 6 in 10 of the 18 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Address PR review comments systematically.

Process

  1. Get review comments: Use gh api graphql to fetch all review threads and comments for the PR. (If a PR number is not provided in the input, look up the PR for the current branch).
  2. Analyze comments: Review all the feedback to understand what changes are needed
  3. Address each comment systematically: For each review comment:
    • Make the requested code changes
    • Verify the changes fix the issue raised
    • Add explanatory comments if the reviewer requested clarification
    • Test changes to ensure they don't break existing functionality
  4. Quality assurance: Run type-check, build, and lint to ensure all changes are correct
  5. Commit and push: Stage and commit all changes with an appropriate message and push.
  6. Mark comments resolved: Query PR review threads with gh api graphql to get thread IDs and outdated status. Resolve all addressed threads using mutation { resolveReviewThread(input: {threadId: "THREAD_ID"}) { thread { isResolved } } }. Always resolve outdated threads.

Implementation Pattern

// Query review threads:
gh api graphql -f query='query { repository(owner: "owner", name: "repo") { pullRequest(number: N) { reviewThreads(first: 100) { nodes { id isResolved isOutdated comments { nodes { body } } } } } } }'

// Resolve thread:
gh api graphql -f query='mutation { resolveReviewThread(input: {threadId: "THREAD_ID"}) { thread { isResolved } } }'

Notes

  • Only address reviews from human users; ignore bot reviews (e.g., Claude) unless explicitly requested
  • Use sub-agents to handle independent review comments in parallel when possible
  • Always verify changes don't introduce new issues
  • If a review comment requires clarification, document the approach taken
  • Focus on the specific issues raised rather than making additional changes
  • Mark outdated comments as resolved automatically since they no longer apply to current code

Download now (ZIP)

  • Other versions20 projects use a version of this.

    Word for word · 2

    1. cashew-labs/libretto★ 898100% same
    2. saffron-health/libretto★ 883100% same

    Edited · 0

    None found.

    Wrote their own version · 18

    1. oxcaml/oxcaml★ 909same name
    2. gittower/git-flow-next★ 458same name
    3. finos/git-proxy★ 257same name
    4. fpindej/netrock★ 234same name
    5. michaelegner/architecture-intelligence-platform★ 9same name
    6. fedemelo/agent-config★ 4same name
    7. lestrrat/claude-code★ 4same name
    8. magnusrodseth/dotfiles★ 2same name
    9. angusfretwell/skills★ 1same name
    10. enocgit/sdlc-kit★ 1same name

    8 more not listed

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • Used alongsideProjects with it also use open-pr, review-pr and 3 more.

    Other files people use alongside this one.

    Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
    • CloudflareSkill

      open-pr

      Take a cloudflare/agents GitHub issue plus any repro findings and one-shot a fix PR — branch, change, test, push, and open the PR linked to the issue.

      Also in 3 projects that use this

    • DockerSkill

      review-pr

      Review one or more incoming Docker documentation pull requests as a maintainer. Independently validate technical claims, assess editorial fit and information architecture, choose a verdict, and draft exact inline or PR-wide feedback behind a confirmation gate. Use for requests such as "review PR 123", "is this PR correct?", "does this information belong here?", "validate this PR", or "help review backlog PRs". Do not use to maintain or fix a PR you own; use maintain-pr for that.

      Also in 3 projects that use this

    • Hugging FaceSkill

      implement

      Make tests pass. Invoke after /write-tests produces failing tests.

      Also in 3 projects that use this

    • GoogleSkill

      improve-codebase-architecture

      Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.

      Also in 3 projects that use this

    • MicrosoftSkill

      handoff

      Compact the current conversation into a handoff document for another agent to pick up.

      Also in 3 projects that use this

  • In this repository15 other files it gives its agents.

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

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.

Check your setup, free