Context is Key
Always gather full context before attempting a fix. This includes reading all relevant PR comments, checking CI/CD logs, and understanding the surrounding code.
Without full context, fixes may be incomplete or introduce new issues.
Incremental Fixes
Address issues one at a time (e.g., fix tests first, then address comments). This makes the process more manageable and easier to validate.
Tackling all issues at once can be complex and error-prone.
Handle Fork Remotes Correctly
Always check if a PR comes from a fork (cross-repository) before pushing changes. Use 'gh pr view --json isCrossRepository' to determine the correct remote.
Pushing to the wrong remote (e.g., origin instead of fork) will fail for cross-repository PRs.
PR from a fork
Check isCrossRepository, add fork remote if needed, push to fork
Always push to origin without checking PR source
How to correctly escape conflict markers when using apply_diff.
When removing merge conflict markers from files, you must **escape** them in your `SEARCH` section by prepending a backslash (`\`) at the beginning of the line. This prevents the system from mistaking them for actual diff syntax.
**Correct Format Example:**
```
<<<<<<< SEARCH
content before
\<<<<<<< HEAD <-- Note the backslash here
content after
=======
replacement content
>>>>>>> REPLACE
```
Without escaping, the system confuses your content with real diff markers.
You may include multiple diff blocks in a single request, but if any of the following markers appear within your `SEARCH` or `REPLACE` content, they must be escaped:
```
\<<<<<<< SEARCH
\=======
\>>>>>>> REPLACE
```
Only these three need to be escaped when used in content.
- Have all review comments been addressed?
- Are all CI/CD checks passing?
- Is the PR free of merge conflicts?
- Have the changes been tested locally?