Feature request: --no-commit / fix-only mode for gstack workflow compatibility
Background
Our team uses gstack as our primary AI-assisted development workflow. gstack wraps Claude Code with skill-based workflows and enforces a set of safety guardrails around every destructive git operation. The skill we use for all shipping work is /ship.
What we're doing
/ship handles the full pre-PR pipeline: detecting the base branch, running tests, reviewing the diff, bumping VERSION, updating CHANGELOG, and then committing + pushing + opening the PR. Every destructive step is gated behind an explicit AskUserQuestion confirmation. Two rules are non-negotiable in this workflow:
- Never
git add -A — only intentionally staged files are committed.
- Never commit or push autonomously — the user confirms each step.
We love the concept behind greploop: iteratively fetching Greptile's confidence score and inline review comments, then applying fixes until the score reaches threshold. Greptile is already wired as an automatic CI check on every PR and every new commit push, so the feedback loop is genuinely useful for us.
Why this matters
The problem is that greploop's current iteration loop does:
git add -A && git commit -m "address greptile review feedback (greploop iteration N)" && git push
This is exactly what gstack's /ship skill prohibits. git add -A stages blindly — it can pick up .env changes, generated files, debug artifacts, or any other unintended working-tree noise. The autonomous commit + push then bypasses every confirmation gate that /ship enforces. Running greploop today means either abandoning the guarded workflow entirely or manually undoing its commits before /ship can take over.
The specific conflict
The lines inside greploop's iteration loop that conflict with our workflow are:
git add -A && git commit -m "address greptile review feedback (greploop iteration N)" && git push
These three chained commands are the entire source of incompatibility. Everything else greploop does — triggering the review, parsing the confidence score, reading unresolved comments, and applying code fixes — is something we actively want.
Additional motivation: review billing and reliability
Reading the other open issues here surfaced two more reasons why --no-commit mode would be broadly useful, beyond our specific gstack constraint:
Review billing (#12): The current autonomous loop can trigger a large number of Greptile review cycles in rapid succession — one report cited a dozen reviews in a single 40-minute run, with a corresponding spike on the Greptile billing dashboard. A --no-commit mode would naturally throttle this: because no push happens automatically, no new review cycle is triggered until the developer deliberately pushes. Users keep full control over how many billable reviews they consume per iteration.
Unbounded polling (#14): The inner while true polling loops (waiting for the Greptile check run to appear) have no timeout guard. If Greptile is disabled, misconfigured, or rate-limited, the agent spins indefinitely. With a fix-only mode the developer drives each pass manually, so a hung poll can never silently run forever.
Both of these are independent arguments for the same flag, and they'd benefit users who don't use gstack at all.
What we'd love to see
A --no-commit flag (or a dedicated fix-only mode) that scopes greploop's responsibility to:
- Triggering the Greptile review
- Fetching the confidence score and unresolved inline comments
- Applying the suggested code fixes to working-tree files
And then stopping cleanly — no staging, no commit, no push. The working tree is left in a modified state that the developer's own workflow (in our case /ship) can inspect, stage selectively, confirm, and push.
A rough sketch of the interface we have in mind:
# Current behavior (full autonomous loop)
greploop
# Proposed: apply fixes only, leave git operations to the developer
greploop --no-commit
# or
greploop --fix-only
Ideally the flag would be composable with any existing options (iteration count, score threshold, etc.) so teams can tune how many fix passes greploop runs before handing control back.
Closing note
We think greploop's core intelligence is genuinely valuable and we'd like to use it without forking or monkey-patching around it. We're happy to test a branch, provide feedback on the UX, or contribute a PR if that would be helpful. Thanks for considering this — feel free to reach out if you'd like more detail on how the gstack workflow is structured.
Feature request:
--no-commit/ fix-only mode for gstack workflow compatibilityBackground
Our team uses gstack as our primary AI-assisted development workflow. gstack wraps Claude Code with skill-based workflows and enforces a set of safety guardrails around every destructive git operation. The skill we use for all shipping work is
/ship.What we're doing
/shiphandles the full pre-PR pipeline: detecting the base branch, running tests, reviewing the diff, bumping VERSION, updating CHANGELOG, and then committing + pushing + opening the PR. Every destructive step is gated behind an explicitAskUserQuestionconfirmation. Two rules are non-negotiable in this workflow:git add -A— only intentionally staged files are committed.We love the concept behind greploop: iteratively fetching Greptile's confidence score and inline review comments, then applying fixes until the score reaches threshold. Greptile is already wired as an automatic CI check on every PR and every new commit push, so the feedback loop is genuinely useful for us.
Why this matters
The problem is that greploop's current iteration loop does:
This is exactly what gstack's
/shipskill prohibits.git add -Astages blindly — it can pick up.envchanges, generated files, debug artifacts, or any other unintended working-tree noise. The autonomous commit + push then bypasses every confirmation gate that/shipenforces. Running greploop today means either abandoning the guarded workflow entirely or manually undoing its commits before/shipcan take over.The specific conflict
The lines inside greploop's iteration loop that conflict with our workflow are:
These three chained commands are the entire source of incompatibility. Everything else greploop does — triggering the review, parsing the confidence score, reading unresolved comments, and applying code fixes — is something we actively want.
Additional motivation: review billing and reliability
Reading the other open issues here surfaced two more reasons why
--no-commitmode would be broadly useful, beyond our specific gstack constraint:Review billing (#12): The current autonomous loop can trigger a large number of Greptile review cycles in rapid succession — one report cited a dozen reviews in a single 40-minute run, with a corresponding spike on the Greptile billing dashboard. A
--no-commitmode would naturally throttle this: because no push happens automatically, no new review cycle is triggered until the developer deliberately pushes. Users keep full control over how many billable reviews they consume per iteration.Unbounded polling (#14): The inner
while truepolling loops (waiting for the Greptile check run to appear) have no timeout guard. If Greptile is disabled, misconfigured, or rate-limited, the agent spins indefinitely. With a fix-only mode the developer drives each pass manually, so a hung poll can never silently run forever.Both of these are independent arguments for the same flag, and they'd benefit users who don't use gstack at all.
What we'd love to see
A
--no-commitflag (or a dedicatedfix-onlymode) that scopes greploop's responsibility to:And then stopping cleanly — no staging, no commit, no push. The working tree is left in a modified state that the developer's own workflow (in our case
/ship) can inspect, stage selectively, confirm, and push.A rough sketch of the interface we have in mind:
Ideally the flag would be composable with any existing options (iteration count, score threshold, etc.) so teams can tune how many fix passes greploop runs before handing control back.
Closing note
We think greploop's core intelligence is genuinely valuable and we'd like to use it without forking or monkey-patching around it. We're happy to test a branch, provide feedback on the UX, or contribute a PR if that would be helpful. Thanks for considering this — feel free to reach out if you'd like more detail on how the gstack workflow is structured.