From GitHub Issue to Pull Request Without Leaving Your Terminal

Most software work begins in one place and ends in another.

You read an issue on GitHub, inspect the repository locally, make changes in your editor, run tests in a terminal, create a commit, push a branch, and finally return to GitHub to open or review a pull request.

The individual steps are familiar. The context switching is the problem.

yottacode is a terminal coding agent designed to connect these steps into one developer-controlled workflow. Its GitHub integration lets you work with issues and pull requests without constantly moving between your browser, terminal, and editor.

This article walks through the workflow.

GitHub operations as agent workflows

A coding agent should not only edit files. It should understand the engineering workflow around those files.

That includes:

• Reading repository and issue context
• Creating commits
• Pushing branches
• Opening pull requests
• Updating pull request descriptions
• Creating GitHub issues
• Reviewing pull request diffs
• Implementing an issue from start to finish

With yottacode, these operations are exposed as explicit GitHub tools rather than being hidden behind an unrestricted shell command.

That distinction matters. The agent can work with GitHub while still making each operation visible and reviewable.

Start with an issue

A typical workflow begins with an existing GitHub issue.

Instead of manually copying the issue description into a prompt, you can ask yottacode to inspect the issue and explain what needs to change.

For example:

Implement GitHub issue #42 in this repository.
First inspect the issue, understand the relevant code, and propose a plan.
Do not edit anything until I approve the plan.

The agent can retrieve the issue title, description, labels, assignees, and recent comments before looking for the relevant code.

That gives the implementation better context from the beginning.

It also gives you an opportunity to correct the interpretation before any files change.

Work in an isolated branch

A good coding-agent workflow should make isolation easy.

Rather than modifying the main checkout directly, create a worktree for the task:

Create a new worktree for issue #42 and work there.

The implementation then has its own branch and working directory. This makes it easier to:

• Keep unrelated work untouched
• Run multiple tasks in parallel
• Review the complete change
• Discard an experiment safely
• Open a pull request from a clean branch

The worktree is not a replacement for Git. It makes the existing Git workflow safer for agent-assisted development.

Commit and push with context

Once the implementation is complete, yottacode can inspect the changes before creating a commit.

A useful request might be:

Review the current changes, run the relevant tests, and prepare a commit.
Show me the proposed commit message before committing.

The agent can examine the staged or unstaged changes, detect the repository’s commit style, and create a focused commit after approval.

Pushing is a separate operation:

Push this branch to origin.

Separating commit and push gives developers control over the point at which local work becomes remote work.

Create a pull request from the terminal

After pushing the branch, open a pull request without leaving the terminal:

Open a pull request for this branch against main.
Summarize the problem, implementation, tests, and any remaining limitations.

A useful pull request should explain:

1. What problem the change solves
2. What implementation approach was used
3. Which files or components changed
4. How the change was tested
5. What reviewers should pay attention to

Because the agent has already inspected the issue and implementation, it can produce a pull request description with more context than a generic generated summary.

You can also update the pull request later:

Update the pull request description to include the new integration test.

Review pull requests by reading the diff

Code review is another place where context switching adds friction.

Instead of opening a pull request in a browser and manually gathering its metadata, ask yottacode to review it:

Review pull request #57.
Look for correctness issues, regressions, missing tests, and security concerns.

The review workflow can combine:

• Pull request metadata
• The complete unified diff
• CI check results
• Failed job summaries
• Relevant repository code

The important part is that the agent reviews the actual change, not just the pull request description.

A useful review should distinguish between:

• Definite bugs
• Likely regressions
• Missing edge cases
• Test gaps
• Style or maintainability suggestions
• Findings that are probably false positives

That makes the output more useful than a long list of speculative warnings.

Create issues while the context is fresh

Not every discovery should be fixed immediately.

During implementation or review, you may find a related problem that belongs in a separate task:

Create a GitHub issue describing the unrelated configuration bug we found.
Include reproduction steps and a proposed direction, but do not implement it.

This preserves the context while keeping the current pull request focused.

It is a small workflow improvement, but it prevents useful discoveries from disappearing into chat history or untracked notes.

The complete issue-to-PR workflow

A complete yottacode workflow can look like this:

1. Read GitHub issue #42
2. Inspect the repository
3. Propose an implementation plan
4. Create an isolated worktree
5. Implement the approved change
6. Run tests and verification
7. Review the diff
8. Create a commit
9. Push the branch
10. Open a pull request
11. Review CI and address feedback

Each step remains explicit. The agent can help move the work forward, but the developer remains in control of file changes, commands, commits, pushes, and GitHub operations.

Designed for developer control

The goal is not to hide the engineering process behind an autonomous black box.

The goal is to reduce repetitive context switching while preserving the controls that make software work safe:

• Explicit tool calls
• Approval before risky actions
• Isolated worktrees
• Visible diffs
• Test verification
• Separate GitHub operations
• Reviewable commits and pull requests

This is especially important when an agent can modify code and interact with remote repositories. Speed is useful, but traceability and control are part of the feature.

Try it in your repository

yottacode is an open-source terminal coding agent written in Go.

You can find the project on GitHub and read the documentation.

For the complete GitHub integration overview, including the full set of supported workflows, see:

Read the complete yottacode GitHub integration guide

The broader idea is simple: GitHub should not be a disconnected destination at the end of a coding session. It can be part of the development workflow from the first issue to the final pull request.