gstack Greptile Code Review Integration: Triage That Actually Works

The Problem with Automated Code Review

Automated code review tools are powerful in theory. Greptile, a Y Combinator-backed company, reviews pull requests automatically and catches issues that CI pipelines miss entirely: race conditions, security vulnerabilities, logic errors, and architectural anti-patterns. These are real bugs that would otherwise ship to production. The tool works. The problem is what happens after it works.

When Greptile leaves five comments on a PR, some are genuine issues and some are false positives. Without a system to triage those comments, developers face an unpleasant choice: spend 15 minutes evaluating each comment manually, or start ignoring them. Most teams choose the latter. Within weeks, Greptile comments become background noise -- unread, unresolved, and silently piling up on every pull request.

This is the triage problem, and it is where gstack Greptile code review integration steps in. Instead of leaving you to manually sort through automated findings, gstack reads every Greptile comment, classifies it, and takes the appropriate action -- all before you even look at the PR.

How gstack Greptile Code Review Integration Works

The integration operates in two layers. First, Greptile reviews your PR asynchronously on GitHub, leaving inline comments on the diff. Second, gstack's /review and /ship skills read those comments and triage them intelligently. This two-layer approach means you get the benefit of Greptile's deep codebase understanding combined with gstack's contextual judgment about what is actually worth fixing.

Setting Up Greptile

Getting Greptile running on your repository takes approximately 30 seconds. Install the Greptile GitHub app on your repository, grant it read access to your codebase, and it begins reviewing PRs immediately. There is no configuration file to write, no CI pipeline to modify, and no webhooks to set up. Once Greptile is active, gstack picks up its comments automatically -- no additional integration step required on the gstack side.

# Step 1: Install Greptile on your GitHub repo (via greptile.com)
# Step 2: Open a PR as usual
# Step 3: Greptile leaves review comments automatically
# Step 4: gstack reads and triages those comments

# When you're ready to review
/review

# Or when you're ready to ship
/ship

What Greptile Catches

Greptile is not a linter. It does not flag missing semicolons or style violations. It catches the kind of issues that require understanding the broader codebase to identify. Here are the categories of bugs that Greptile surfaces and that gstack Greptile code review integration triages:

• Race conditions -- Concurrent access to shared state without proper synchronization, especially in async code paths
• Security vulnerabilities -- SQL injection vectors, unvalidated user input, exposed secrets, insecure defaults
• Logic errors -- Off-by-one mistakes, incorrect null checks, inverted boolean conditions that CI cannot detect
• Breaking changes -- API modifications that would break downstream consumers, missing migration steps
• Performance regressions -- N+1 queries, unnecessary re-renders, missing database indexes on new columns
• Error handling gaps -- Unhandled promise rejections, missing try-catch blocks, swallowed exceptions

These are issues that pass every CI check, every linter rule, and every unit test -- because they require understanding how the code interacts with the rest of the system. That is Greptile's strength, and it is why the triage layer matters so much. When Greptile flags a race condition, you want that comment actioned immediately, not buried under three false positives about code style preferences.

The Three-Way Classification System

When gstack's /review or /ship skill encounters Greptile comments on a PR, it classifies each one into exactly one of three categories. This classification drives the automatic response.

This three-way classification is what transforms Greptile from "a tool that leaves comments" into "a tool that makes your code better." Without it, every Greptile comment requires manual evaluation. With it, you only spend time on the comments that matter.

How Classification Works Under the Hood

The classification is not a simple keyword match. When /review or /ship encounters a Greptile comment, it reads the full diff context, understands the intent of the change, cross-references the comment against the current state of the code (not just the diff), and determines whether the concern is valid. This is the same contextual understanding that powers gstack's broader AI code review capabilities, but applied specifically to triaging third-party review comments.

The /review and /ship Greptile Workflow

Both /review and /ship are Greptile-aware, but they handle Greptile comments at different points in your workflow.

/review: Early Triage

Running /review during development gives you an early read on what Greptile has found. It reads all existing Greptile comments on the PR, classifies them, and presents a summary. Valid issues are highlighted so you can address them before you consider the PR ready to ship. This is the investigative phase -- you are still actively working on the code and can incorporate fixes naturally.

/ship: Final Gate

Running /ship is the final quality gate before merging. At this point, gstack re-evaluates all Greptile comments against the current state of the branch. Comments that were valid earlier but have since been fixed get the "already fixed" classification. Remaining valid issues block the ship with a clear explanation. False positives get a push-back reply posted directly to the PR.

# During development: see what Greptile found
/review

# Output:
# Greptile Comments (3 found):
#   [VALID]   Race condition in user session handler - concurrent
#             writes to session store without mutex
#   [FIXED]   Missing null check on user.email - addressed in commit a3f8e2d
#   [FP]      "Unused import" - import is used in conditional branch
#             on line 142

# Fix the valid issue, then ship
/ship

# Output:
# Greptile triage complete:
#   1 issue fixed (race condition - mutex added)
#   1 auto-acknowledged (null check already resolved)
#   1 pushed back (false positive: import used conditionally)
# Ready to merge.

The Learning System: Getting Smarter Over Time

One of the most valuable aspects of gstack Greptile code review integration is the learning system. Every time a Greptile comment is classified as a false positive, the pattern is saved to ~/.gstack/greptile-history.md. This file acts as institutional memory -- a growing record of the kinds of comments that Greptile gets wrong for your specific codebase.

On future runs, /review and /ship consult this history file before classifying new comments. If a new comment matches a known false positive pattern, it is automatically skipped or deprioritized. This means the triage gets faster and more accurate over time, without any manual configuration.

The practical impact is significant. In the first week of using gstack Greptile code review integration, you might spend a few seconds per false positive as the system learns your codebase's patterns. By the second week, most recurring false positives are auto-skipped, and the triage output is almost entirely valid issues that genuinely need your attention.

Tracking Greptile's Accuracy with /retro

Knowing how well your automated reviewer performs is important for deciding how much weight to give its findings. gstack's /retro skill tracks Greptile's batting average over time -- the ratio of valid findings to total comments across all your PRs.

This data answers questions that are otherwise impossible to answer without manual record-keeping:

• What percentage of Greptile comments are actionable?
• Is accuracy improving or degrading as the codebase evolves?
• Which categories of bugs does Greptile catch most reliably?
• Are there recurring false positive patterns that could be reported upstream?

Over time, this retrospective data helps you calibrate your trust in automated review. If Greptile's batting average is 70%, you know that most comments deserve attention. If it drops to 30%, you might consider adjusting Greptile's configuration or reporting the false positive patterns to the Greptile team.

End-to-End Example: A Real /ship Workflow

Here is a complete example of how gstack Greptile code review integration works in practice, from PR creation to merge.

Step 1: Open the PR

You push a feature branch that adds a new API endpoint for user profile updates. Within minutes, Greptile reviews the diff and leaves three comments on the PR.

Step 2: Run /ship

When you are ready to merge, you run /ship. gstack reads the three Greptile comments and classifies them:

/ship

# Greptile Triage Results:
#
# 1. [VALID] Race condition in profile update handler
#    Greptile says: "Concurrent PUT requests to /api/profile could
#    cause a lost update. The read-modify-write cycle is not atomic."
#    Action: Fix required before shipping.
#
# 2. [FIXED] Missing input validation on email field
#    Greptile says: "User-supplied email is passed directly to the
#    database query without validation."
#    Status: Fixed in commit b7c2e41 (added zod schema validation).
#    Action: Auto-reply posted to PR.
#
# 3. [FALSE POSITIVE] "Unused variable profileData"
#    Greptile says: "profileData is assigned but never used."
#    Reality: profileData is used in the catch block on line 89
#    for error logging.
#    Action: Push-back reply posted to PR.

Step 3: Fix the Valid Issue

gstack identifies the race condition as a genuine problem. You (or gstack, if you ask it to) add optimistic locking to the profile update handler. The fix takes two minutes.

Step 4: Ship

Running /ship again confirms that all three Greptile comments are resolved: one fixed by you, one already fixed, one dismissed as a false positive. The PR is ready to merge. The false positive pattern ("variable used in catch block") is saved to ~/.gstack/greptile-history.md for future reference.

Why Two Layers Beat One

You might wonder why gstack Greptile code review integration uses two layers (Greptile plus gstack triage) instead of just relying on one tool. The answer comes down to specialization.

Greptile excels at deep codebase analysis. It indexes your entire repository, understands cross-file dependencies, and catches issues that require global context. It runs asynchronously on GitHub, reviewing every PR without blocking your workflow. But it has no knowledge of your current development context -- it does not know which comments you have already addressed, which patterns are intentional in your codebase, or which findings your team considers noise.

gstack excels at contextual triage. It runs in your local development environment, has access to the current state of your branch, understands the diff history, and maintains a learning history of past classifications. It cannot replace Greptile's async analysis, but it can make Greptile's output dramatically more useful.

Together, the two layers create a review system that is both thorough and practical. Greptile casts a wide net. gstack sorts the catch. The result is a workflow where automated code review comments actually get read, evaluated, and actioned -- instead of being ignored.

Comparison: With and Without Triage

Getting Started with gstack Greptile Code Review Integration

Setting up the full integration takes under five minutes. If you already have gstack installed, you are halfway there.

1. Install Greptile -- Go to greptile.com, connect your GitHub account, and install the app on your target repository. This takes about 30 seconds.
2. Open a PR -- Push a branch and open a pull request as you normally would. Greptile begins reviewing automatically.
3. Run /review or /ship -- gstack detects Greptile comments on the PR and triages them. No configuration needed.
4. Review the triage output -- Fix valid issues, verify auto-acknowledged items, and confirm false positive dismissals.
5. Let the learning system accumulate -- After a few PRs, recurring false positives are auto-handled.

The learning history at ~/.gstack/greptile-history.md is created automatically on first use. You can review and edit it at any time -- it is plain Markdown. If gstack misclassified a comment, correct the entry and the system adjusts on the next run.

When to Use Greptile Integration vs. gstack's Built-In Review

gstack's /review skill performs its own code review independently of Greptile. The two are complementary, not redundant. Greptile reviews asynchronously on GitHub with full repository context. gstack's built-in review runs locally with full diff and branch context. Using both gives you the widest coverage.

Think of it this way: Greptile is like a senior engineer who reads every PR on the team and leaves comments overnight. gstack's /review is like a pair programmer sitting next to you who can check your work in real time. The gstack Greptile code review integration is the system that makes sure the senior engineer's comments do not go unread.

For teams that want the most thorough review process, the recommended workflow is: write code, run /review locally for immediate feedback, push the PR for Greptile's async review, then run /ship to triage everything before merging. This combination covers both local context and global codebase awareness. Learn more about the full shipping workflow that ties these steps together.