name	review-greptile
description	Review Greptile bot review comments on a PR, decide which to action, apply the actioned ones, reply to each thread, and resolve it. Use when the user wants to triage, address, action, or resolve Greptile comments/reviews on a pull request, or says "review greptile", "handle greptile comments", or "resolve greptile".

Review Greptile comments

Triage the unresolved Greptile review threads on a PR: decide which to action, apply the changes, reply to every thread explaining the outcome, and resolve it.

scripts/greptile.sh wraps the GitHub API (Greptile posts as the greptile-apps bot; threads resolve via GraphQL, replies via the REST in_reply_to endpoint).

Workflow

Find the PR. Default to the current branch: gh pr view --json number,title. If there's no PR for the branch, ask the user which PR number.
Read the comments. scripts/greptile.sh list <pr> returns JSON of unresolved Greptile threads: {threadId, isOutdated, commentId, path, line, body}. The body is HTML-ish — the priority is a P1/P2/P3 badge, followed by a bold title, the rationale, and sometimes a suggestion block or "Context Used" footer.
Decide, per thread (action or skip) with a one-line reason. Heuristics:
- P1 and security-badged comments: action unless clearly wrong or already handled.
- suggestion blocks: evaluate the diff on merits; apply if correct.
- Nits / style: skip if they conflict with this repo's conventions. Read CONTEXT.md, docs/adr/, and (for any UI/visual comment) DESIGN.md before deciding — repo conventions win over the bot.
- isOutdated: true: usually skip (the code moved on) — reply noting it's outdated.
- Anything you genuinely disagree with: skip with a clear reason.
Present a decision table and STOP for approval. Columns: path:line · priority · title · decision · reason. Do not edit code until the user approves. The user may flip any decision.
Apply the actioned changes. Make the edits (honour DESIGN.md for anything visual — flag mismatches rather than introducing them). Run the repo's tests/build for touched areas if quick. Then commit and push:
- Group related fixes into sensible commits (one per concern is fine), referencing the comment, e.g. fix(frontend): validate ACE_BACKEND_URL before rendering nginx config.
- Co-author the commit per repo convention, then git push.
Reply + resolve every thread (both actioned and skipped):
- scripts/greptile.sh reply <pr> <commentId> "<body>"
- scripts/greptile.sh resolve <threadId>
- Actioned reply: what changed and the commit sha, e.g. Done in <sha> — added an upstream-URL validation guard before the config is rendered.
- Skipped reply: the reason, e.g. Skipping — \location /api` already sits behind an exact-match block, so the prefix concern doesn't apply here.`
Report a summary: counts actioned/skipped, the commit(s) pushed, and any thread that failed to reply/resolve.

Notes

Run from inside the repo clone — gh infers aceobservability/ace automatically.
The script only ever lists unresolved threads, so re-running after a partial pass is safe.
If list returns [], there's nothing to do — say so and stop.
Never resolve a thread without first leaving a reply.

Review Greptile comments

Triage the unresolved Greptile review threads on a PR: decide which to action, apply the changes, reply to every thread explaining the outcome, and resolve it.

scripts/greptile.sh wraps the GitHub API (Greptile posts as the greptile-apps bot; threads resolve via GraphQL, replies via the REST in_reply_to endpoint).

Workflow

Find the PR. Default to the current branch: gh pr view --json number,title. If there's no PR for the branch, ask the user which PR number.

Read the comments. scripts/greptile.sh list <pr> returns JSON of unresolved Greptile threads: {threadId, isOutdated, commentId, path, line, body}. The body is HTML-ish — the priority is a P1/P2/P3 badge, followed by a bold title, the rationale, and sometimes a suggestion block or "Context Used" footer.

Decide, per thread (action or skip) with a one-line reason. Heuristics:

P1 and security-badged comments: action unless clearly wrong or already handled.
suggestion blocks: evaluate the diff on merits; apply if correct.
Nits / style: skip if they conflict with this repo's conventions. Read CONTEXT.md, docs/adr/, and (for any UI/visual comment) DESIGN.md before deciding — repo conventions win over the bot.
isOutdated: true: usually skip (the code moved on) — reply noting it's outdated.
Anything you genuinely disagree with: skip with a clear reason.

Present a decision table and STOP for approval. Columns: path:line · priority · title · decision · reason. Do not edit code until the user approves. The user may flip any decision.

Apply the actioned changes. Make the edits (honour DESIGN.md for anything visual — flag mismatches rather than introducing them). Run the repo's tests/build for touched areas if quick. Then commit and push:

Group related fixes into sensible commits (one per concern is fine), referencing the comment, e.g. fix(frontend): validate ACE_BACKEND_URL before rendering nginx config.
Co-author the commit per repo convention, then git push.

Reply + resolve every thread (both actioned and skipped):

scripts/greptile.sh reply <pr> <commentId> "<body>"
scripts/greptile.sh resolve <threadId>
Actioned reply: what changed and the commit sha, e.g. Done in <sha> — added an upstream-URL validation guard before the config is rendered.
Skipped reply: the reason, e.g. Skipping — \location /api` already sits behind an exact-match block, so the prefix concern doesn't apply here.`

Report a summary: counts actioned/skipped, the commit(s) pushed, and any thread that failed to reply/resolve.

Notes

Run from inside the repo clone — gh infers aceobservability/ace automatically.

The script only ever lists unresolved threads, so re-running after a partial pass is safe.

If list returns [], there's nothing to do — say so and stop.

Never resolve a thread without first leaving a reply.

review-greptile

Review Greptile comments

Workflow

Notes

Review Greptile comments

Workflow

Notes