Project Explorer – Code & PRs

The Explorer provides a direct view into the repository connected to your ORGN project. It allows you to browse source files, review commit history, and manage pull requests without leaving the development workspace.

Unlike external Git interfaces, Explorer is integrated with the ORGN environment. This means that repository activity, agent-generated changes, and task-driven work all remain visible inside the same interface.

Explorer is organized into three main areas:

• Code: browse and inspect the repository structure
• Commits: review commit history and individual changes
• Pull Requests: manage proposed changes before merging

These views give you full visibility into how the repository evolves as tasks are executed and changes are reviewed.

Code

The Code tab shows the current state of the repository at the selected branch.

The interface is divided into two primary sections:

• File Tree: the repository directory structure
• File Viewer: the contents of the selected file

This layout allows you to navigate through the project in the same way you would in a local editor.

Branch Selection

A branch selector dropdown sits above the file tree. It shows the currently active branch — for example, main — and allows you to switch branches to inspect the repository at a different point in its history.

Repository Navigation

The file tree displays the full directory structure of the repository. You can expand folders to explore nested directories and quickly locate files across the codebase.

For example, a frontend project may include a root-level structure such as:

public/
src/
.gitignore
bun.lockb
package.json
tailwind.config.ts
vite.config.ts

Selecting a file immediately loads its contents in the viewer panel below. The viewer displays the filename and full source content of the selected file.

This makes it easy to inspect files without switching tools. For example, opening a component file shows its imports, structure, and logic at a glance.

This view is especially useful when:

• reviewing code before executing an agent task
• understanding the structure of an unfamiliar repository
• confirming file contents during a debugging investigation

Because Explorer operates inside the same workspace as agents, you can move from reading code directly into a session or task without switching environments.

Commits

The Commits tab displays the chronological history of changes made to the repository.

A search bar at the top lets you filter commits by message. Two date fields allow you to narrow the list to a specific time range using from and to date filters.

Each entry in the list shows:

• commit message
• author
• relative timestamp (for example, "1m ago" or "5mo ago")
• short commit hash (for example, 895fa21)

Commits are grouped by date to make it easier to follow the progression of development activity.

For example, you may see entries such as:

Update README.md — User · 1m ago · 895fa21

Merge pull request #9 from User/remove-feature — User · 5mo ago · afd377b
fix: Remove unused feature — User · 5mo ago · 76d18b5

A pagination control at the bottom of the list lets you move between pages when the commit history is long.

Selecting a commit opens a detailed diff view showing exactly what changed.

Commit Diff View

When a commit is selected, the interface splits into two areas:

• Changed Files Panel: a list of modified files
• Diff Viewer: line-by-line changes within the selected file

Additions appear in green, while removed lines appear in red.

For example, if a commit modifies new.md, the diff viewer shows exactly which lines were added or removed. This allows developers to quickly review the scope of a change before pulling it into another branch or investigating a regression.

The commit view is useful for:

• tracing when a bug was introduced
• reviewing recent activity in the repository
• verifying the changes included in a merge

Because the commit history reflects both manual commits and merged pull requests, it provides a complete record of how the repository has evolved.

Pull Requests

The Pull Requests tab is where proposed code changes are reviewed and merged.

Instead of pushing changes directly to the main branch, contributors create pull requests that allow others to inspect the modifications before integration.

A search bar at the top lets you filter pull requests by title. An Updated sort button and a Filters button are also available to help narrow the list.

Pull requests are organized into three tabs, each showing a count of entries:

• Open: pull requests awaiting review or merge
• Merged: changes that have been accepted into the repository
• Closed: pull requests that were rejected or abandoned

Each entry in the list displays:

• pull request title
• author
• source and target branches (for example, main ← feature/opencode)
• pull request number (for example, #11)
• relative timestamp
• inline change summary: additions, removals, and file count (for example, +6 -1114 28 files)

Pull Request Detail

Opening a pull request shows a full view of the proposed changes.

The header displays:

• pull request title and number
• status badge (Open, Merged, or Closed)
• author
• relative timestamp
• source and target branches
• total additions, removals, and files changed
• a link to the pull request on GitHub

The left panel lists all modified files with their per-file change counts. Selecting a file loads the diff in the main viewer, showing added lines in green and removed lines in red.

The right panel shows the pull request description. For pull requests created from within ORGN, this description is structured automatically and may include sections such as:

• Summary: a brief overview of what the pull request introduces
• Changes: a list of specific modifications made
• Expected Result: what should happen once the changes are merged

Authors can also write their own descriptions, including inline code references, explanations of new functions, and notes for reviewers.

A comment thread appears below the description. Team members can leave feedback directly on the pull request using the comment box. Press Cmd+Enter (or Ctrl+Enter) to submit a comment. Bot integrations may also post automated comments in this thread.

A status indicator at the bottom of the right panel shows the current state of the pull request — for example, "This pull request is open" or "Pull request was merged 5mo ago."

Pull Request States

Open pull requests are changes currently awaiting review or merge.

Merged pull requests are changes that have already been integrated into the repository.

Closed pull requests were rejected or abandoned without being merged.

Each state is accessible from the tabs at the top of the Pull Requests view. Selecting any pull request from these lists opens the full detail view described above.

How Explorer Fits Into the Workflow

Explorer serves as the repository inspection and review layer of ORGN.

It allows developers to:

• explore the repository structure at any branch
• review commits and historical changes
• inspect pull requests and diffs
• discuss and merge proposed changes

Because Explorer operates inside the same workspace used by tasks, agents, and sessions, developers can move smoothly between planning work, generating changes, and reviewing the final result.

For example, a typical workflow might look like:

1. A task is created to address missing test coverage.
2. An agent implements the changes inside the workspace.
3. The modifications are proposed as a pull request.
4. The pull request appears in Explorer under Pull Requests.
5. Reviewers inspect the diff, leave comments, and merge the changes.

This tight integration ensures that repository activity remains transparent, traceable, and fully aligned with the task-driven development workflow used throughout ORGN.