Vein turns a GitHub issue into a peer-reviewed pull request through a four-stage pipeline — planner, executor, reviewer and policy gate. Two LLMs (from different vendors), one deterministic gate, every step audited.
This walkthrough describes how to use Vein's agentic workflow to go from GitHub issues to fully reviewed and merged pull requests. It covers connecting GitHub, selecting a repository, listing and resolving issues, reviewing changes, resolving conflicts, and configuring per-stage models.
To begin, connect your GitHub account so Vein can access your repositories and issues. Vein uses a GitHub App for repo access — you choose which repos Vein can read and write. After the connection is completed, Vein can interact with your GitHub resources on your behalf.
Once GitHub is connected, use Vein's chat to ask which repositories are available for use (for example: "What repos can I use?"). Vein will respond with the list and count of accessible repositories. Identify or create a repo you want to use as a demo or working repo, then select it. Confirm that the selected repository is now active in the Vein interface.
Open the chat panel for the selected repository and continue in an existing conversation or start a new one. Ask Vein to list your current issues (for example: "What issues do I have?"). Vein will automatically trigger the list_issues tool call and return a structured list — horizontal scaling tasks, team backlog items, and issues that need additional scrutiny. Review the list to identify which issue you want Vein to resolve.
In the chat, instruct Vein to resolve a particular issue (for example: "Please resolve issue 10"). Vein will start a new run to plan and execute the work required to address that issue. If there are other runs already in progress (for example, for issue 18), you may see them still running in parallel. Vein will display a run ID for the new task — open this run to monitor its status and internal steps, including planning and execution phases.
Within the run view, observe the following stages. Wait while the execution completes. When the review and policy gate are done, Vein will mark the run as completed. Close the run view once you confirm the process has finished and the changes are ready for GitHub review.
From the Vein interface, use the option to view the generated pull request directly on GitHub. Confirm that a new pull request has been raised for the issue. If there are conflicts, they will be indicated in the pull request view.
Back in Vein, ask it to review the PR associated with the issue. Use the Monaco editor integration in Vein to view the diff for the pull request side-by-side. Run the review workflow for the identified pull request so Vein can analyze the changes and provide feedback or approval.
When GitHub indicates a merge conflict, open the conflict resolution view from the pull request. Resolve the conflicts manually by editing the files to keep the correct changes. After resolving, mark the conflicts as resolved and add any necessary comments to document what you did. Then proceed to merge the pull request (for example, using a squash merge). Verify that the PR is merged successfully and the corresponding issue (such as issue #10) auto-closes as expected.
Optionally, explore previous chats and actions in Vein to see which tasks were completed autonomously and which need manual follow-up.
From the main Vein interface, switch to any other connected repository and continue the same ticket-to-PR workflow. You can also customize the models used by Vein from the configuration area — select your preferred provider (such as OpenRouter or Ollama), and specify a custom base URL and model name if required. Apply these settings so Vein uses your chosen models for planning, execution, and review.
Vein moves the human reviewer to the top of the stack instead of the bottom. Two LLMs argue, a policy gate adjudicates, and every action is auditable — so teams can let agents touch real repos without losing review discipline.
Describe your workflow and we’ll draft a plan in 60 seconds.
