New Task Or Edit Pull Arbiter

[0x4007]

Overview

• During pull requests, we need to have a bias of always moving forward.
• We always need to make an active decision on whether to include requested changes in the current pull or if we should break them off into new tasks.
• We should use an LLM to help us decide what to do.

Ideal Outcome

We seamlessly can review pulls and then the OS can intelligently create a new issue batching the requested changes and link back. Ideal if it can batch similar tasks aiming for between 1 hour and 1 day within the same GitHub issue (I think this is possible with my experience working with Claude 3.5 Sonnet.)

Implementation

The way that this can work is if we leave the review state as "commented" and leave comments that seem like we want changes to be done. These will need to be understood by the OS.

If we really think the changes are critical to be done in the current pull, then we must be sure to "request changes."

Remarks

I am concerned that it might be too quick to fire off new issues, so ideally we have it understand that there is a possibly already created "post pull request review" task, and to continue batching everything from the review in that task (we could standardize the naming scheme of the generated issue.)

We may possibly need to check for pull request closed and merged to process the full conversation and fire off new tasks. This will allow us room to determine the necessity of such suggestions.

Similar ¹

Footnotes

1. 2025 Plugins Wishlist 81% ↩

[ubiquity-os-beta]

Note

The following contributors may be suitable for this task:

sshivaditya2019

76% Match ubiquity-os-marketplace/generate-vector-embeddings#25