mcpField
G
greploop

greploop

github.com/michaelshimelesTesting & quality1.4k268 installsUpdated 4d ago
Repository

About greploop

A skill for improving a change through iterative Greptile reviews of a pull request, merge request, or changelist. It guides agents to evaluate findings, apply authorized fixes, rerun checks, and report the review outcome.

Key features

  1. 01GitHub, GitLab, and Perforce review guidance
  2. 02Configurable review-cycle limit and trigger
  3. 03Fresh review results tied to the current revision
  4. 04Evaluation of summaries and unresolved threads
  5. 05Reporting of checks, scores, and remaining findings

Use cases

  1. 01Addressing actionable Greptile findings on a PR
  2. 02Reviewing changes through GitLab discussions
  3. 03Running a bounded review cycle on a changelist
  4. 04Reporting a timeout or incomplete review

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/michaelshimeles/skills --skill greploop

After installing, type/greploopin Claude Code to confirm it loaded.

Bundled files

References and scripts installed along with SKILL.md.

LICENSE
references/
github.md
gitlab-api.md
graphql-queries.md
perforce.md
scripts/
github_review.py

Details

From the project README

Greploop

Improve the requested change using Greptile feedback. Success means a fresh 5/5 review of the current revision with no unresolved actionable Greptile findings. The bot's score complements the project's checks and your judgment.

Inputs

  • PR, MR, or changelist number. Infer it from the current task when omitted.
  • --max-iterations N, a positive integer, defaults to 10 review cycles.
  • --trigger @greptile by default, or @greptile-apps for the alternate route. Use the alternate when the normal trigger reports too many changed files.
  • --vcs github|gitlab|perforce when repository context is ambiguous.

Apply the user's existing authorization and task scope. A read-only review request does not authorize code edits or posting comments. Keep your own task's worktree and branch; do not switch another task's checkout to the PR branch.

Choose the platform

Use the repository and session context, not an installed executable alone. Read only the relevant reference:

  • GitHub: the bundled helper tracks each trigger and waits for a scored review tied to the current commit.
  • GitLab: use notes and resolvable discussions; CI pipeline activity alone does not identify a Greptile review.
  • Perforce: use the configured Swarm or site adapter.

Review cycle

  1. Confirm the target revision, clean task ownership, and effective iteration cap. Run relevant checks before publishing edits and push or shelve them.
  2. Start one review attempt using the platform reference. Record its trigger and revision. Wait at most 10 minutes for fresh results; do not reuse an earlier score just because it belongs to the same commit.
  3. Read the entire fresh summary, including general-comment findings. Fetch all pages of unresolved Greptile threads. An empty inline-comment list does not prove the summary contains no remaining work. Older unresolved threads remain relevant until addressed, even after their lines become outdated.
  4. If the current review is 5/5, no actionable Greptile findings remain, and relevant checks pass, finish. Otherwise evaluate each finding in context. Fix valid issues within the task. For a false positive, record the reason and supporting evidence before resolving it. Do not change correct code merely to chase the score or resolve other reviewers' threads.
  5. Run checks for the fixes. Commit only task files, push or re-shelve, then resolve the specific threads whose fixes are published. Use explicit file paths when staging. If no code changed, skip the commit and push.
  6. Start a new attempt for the resulting revision if the cap permits it. A changed head invalidates the old attempt. Do not reuse an attempt file or retrigger merely because a poll has not returned yet.

Stop when the cap is reached, a review times out, the integration is unavailable, or the remaining findings require a scope decision. Report the actual result and remaining work. Do not raise the cap automatically or call a partial result complete. The iteration cap includes reviews that produce no edits.

Report

Give the PR/MR URL or changelist, reviewed revision, number of cycles, current score, checks run, resolved findings, and remaining findings. Distinguish a successful review from a timeout or capped run. Do not merge unless requested.

Comments

Markdown supported