The problem
Describe what is broken, missing, slow, unclear, or painful for users or engineers.
Use case
Use Vif when a GitHub issue is ready for a PR.
Pick a clear issue, let Vif run the connected coding agent in the right boundary, and review the result as a normal pull request.
What makes a good first issue
The expected behavior
Say what should be true when the work is done, including edge cases, screenshots, or constraints reviewers care about.
The review standard
Include relevant tests, affected files, product expectations, or reasons the work should stay small.
What Vif does after the issue starts
| Start with the issue | The request remains attached to the GitHub issue so reviewers can see why the work exists. |
|---|---|
| Run in the right place | Vif chooses the hosted, dedicated, or custom runtime configured for that workflow. |
| Open the pull request | The implementation lands as a normal PR with notes, checks, and status for review. |
| Keep the team in control | Engineers review, ask for changes, merge, or close the PR using the same GitHub process they already trust. |
Good first runs
Good fit
- Bug fixes with a clear expected outcome.
- Small product improvements that need code and tests.
- Maintenance work blocked by engineering queue time.
Wait until it is clearer
- Issues that still need product decisions.
- Large rewrites without a review plan.
- Work that needs private systems before a runtime boundary is configured.
Give Vif a real issue.
Install the GitHub App, connect your agent account, and start with one backlog item your team can review.