Hey thanks! You re spot on, understanding the codebase context is key and maintaining history of the repo is perhaps the top problem to solve going forwards.
Also, there is context that’s not just code but documentation/guidelines etc, plenty of experimentation to be done there.
Customisable rules? YES - i ve got a lot of plans currently on this. I see two layers of customisation:
- allow the user to customise when and how often reviews happen, and how they re triggered (i.e every commit/every x mins etc, avoid running prs on specific files I.e package.json changes etc)
- pass in custom rules to the reviewer that work well for you(or team in the future). This will allow the tool to be more dynamic in nature as opposed to just LLM + your code.
Hope this answers your questions, thank you for the support!
Also, there is context that’s not just code but documentation/guidelines etc, plenty of experimentation to be done there.
Customisable rules? YES - i ve got a lot of plans currently on this. I see two layers of customisation: - allow the user to customise when and how often reviews happen, and how they re triggered (i.e every commit/every x mins etc, avoid running prs on specific files I.e package.json changes etc) - pass in custom rules to the reviewer that work well for you(or team in the future). This will allow the tool to be more dynamic in nature as opposed to just LLM + your code.
Hope this answers your questions, thank you for the support!