Thanks for the kind words! Excited to have you try it out

the cool part is that you can run the skill from the same agent session so it has the context on the plan and implementation process

but if you run the skill in a fresh session, it naturally wouldn't have the plan

appreciate it! and yep, we've got lots of ideas on the roadmap to bring a more complete iteration experience closer to the coding agent.

we've found it pretty silly that we have to push to GitHub in order to get comments from a review bot, pull them down locally, then rinse and repeat. the whole agentic coding landscape could benefit from some centralization

yeah, i definitely feel like we're currently in a very time-sparse model for review, when a lot of changes can be condensed locally. it'd reduce a lot of friction and also save a lot of compute costs if we were able to left-shift a lot of our current review work

parley looks awesome! we're planning to add support for comments soon, which is definitely a key feature to being able to iterate back and forth with a coding agent

Ideally, the world trends towards enabling less technical people to get more involved in the whole software loop! Stage is still geared toward a more technical audience, but I think we are going to start reviewing at a higher level for certain types of software or areas of the codebase where we assign more trust to agents to write proper code

Yeah it's getting easier to have agents just add "one more thing" to a PR, and I think there is still an aspect of human engineering judgement to know when to break up PRs versus trusting AI/tools to keep velocity high.

In the ideal world, each PR is as small and self-contained as possible but we've noticed people struggling to justify the extra overhead every time.

Agree that agents are definitely handling more and more of the coding side, and there's almost no doubt they will get better slop-wise.

In our view, even vibe coders should understand how the codebase works, and we think review is a natural place to pause and make sure you know what you and your coworkers are shipping. And we should have tools to reduce the mental load as much as possible.

Do you think there's a problem of cognitive debt among your coworkers who aren't reading the code or reviewing PRs?

It's possible, but at the same time it's been years and they haven't copied things like Graphite's dashboard or stacked PR interface yet. We have the advantage of speed :)

In our experience, it's difficult to create well-mannered commits as you code and new ideas pop into your head or you iterate on different designs (even for LLMs). One concept we toyed around with was telling an LLM to re-do a branch using "perfect commits" right before putting up a PR. But even then you might discover new edge cases and have to tack them on as additional commits.

We thought git wasn't the right level of abstraction and decided to tackle things at the PR level instead. Curious to hear your experiences!

> In our experience, it's difficult to create well-mannered commits

Sure, it is. But it's worth it, not just for code review, but for a myriad other things: bisect, blame, log, etc.

Your tool makes one thing (the code review) easier, while decreasing people's motivation to make well-mannered commits, thus making everything else (bisect etc) worse.

I'm sure it's net positive in some cases, and I think it's net negative in other cases.

> We thought git wasn't the right level of abstraction and decided to tackle things at the PR level instead. Curious to hear your experiences!

The frick is a PR abstraction? Is this a GitHub PR abstraction where the commits are squashed and the PR description is whatever was hallucinated at 5 am? Yes, that’s certainly an abstraction, aka loss of information.

You either have the information stored in the version control database or you don’t. You can curate and digest information but once it’s lost it’s lost.

People layering stuff on top of Git or Subversion makes no sense. Your AI is not so dainty and weak that it cannot write a commit message. And if it can’t then you can recuperate the information that you trashed.

Ah, my feelings exactly, put much more eloquently!

> And if it can’t then you can recuperate the information that you trashed.

Typo: cannot recuperate

> But even then you might discover new edge cases and have to tack them on as additional commits.

Have you heard about `rebase -i` ?

Chapters are regenerated every time a new commit is pushed to a PR. Our thinking is that the chapters should serve as "auto stacked diffs" since they should follow a logical order.

Do you or your team use stacking in your workflows?