Resources · Documentation

Documentation

Pull requests

Work with your repository's pull requests next to the sessions that changed the code. The server machine needs the GitHub or Azure CLI, signed in.

On this page

Open Pull requests beside the workspace selector, then choose a checkout and repository. The view follows the focused session’s checkout until you select another checkout. An unavailable managed worktree does not fall back to the main repository.

Connect the server

Install and authenticate the CLI on the machine running the Prokop server, under the same operating-system account. A phone or browser connecting to that server does not need either CLI. Install only the CLI for the provider you use.

For GitHub.com, install GitHub CLI and run:

gh auth login

For Azure DevOps Services, install Azure CLI, then run:

az login

Prokop uses az only to obtain a token and calls the Azure DevOps REST API directly; the azure-devops extension is not needed. Each organization belongs to a Microsoft Entra tenant, which may differ from your default az tenant. Prokop reads the organization’s tenant and requests a token for it, preferring an az account already signed in to that tenant. If none is, the Pull requests view shows the command to run, for example:

az login --tenant 00000000-0000-0000-0000-000000000000 --allow-no-subscriptions

To use a personal access token instead, set AZURE_DEVOPS_EXT_PAT in the Prokop server’s environment. It then applies to every Azure organization. Do not put the token into a PR or Prokop conversation.

The checkout must have a GitHub.com or Azure DevOps Services Git remote. HTTPS, SSH, and legacy organization.visualstudio.com and vs-ssh.visualstudio.com Azure remote URLs are recognized. GitHub Enterprise and Azure DevOps Server are not supported in this implementation. Click Rescan CLI connections after changing CLI accounts or remotes. The selected repository and signed-in account appear above the inbox.

Create and manage

  1. Push the source branch using Branches.
  2. Click New PR, enter source and target branches, and write the title and description.
  3. Choose draft or ready for review, then create the PR. GitHub fork sources use owner:branch.

Overview supports editing the title and description, requesting or removing reviewers, switching draft status, closing or abandoning, reopening, and merging or completing. Automatic merge delegates completion to the provider when its policies allow it. The provider enforces permissions and required checks; Prokop does not bypass policies or delete the source branch.

Creating a PR does not push commits or switch the local branch.

Review changes

Files loads changed files and patches on demand. Choose unified or side-by-side diffs and click a line number to write an inline comment. Conversations for the selected file appear below its diff, with reply and resolve controls. Activity shows the conversation across the PR.

GitHub supports approval and requested changes. Azure preserves approval, approval with suggestions, rejection, waiting for the author, and reset vote. General comments are available on both providers.

Copy unresolved on the Activity tab copies every unresolved review thread as one markdown document, ordered by file and line, ready to paste into a session. Copy all adds resolved and outdated threads and the general conversation.

Checks

Checks that wait for you have an action in the Checks list:

  • Azure DevOps: Queue a build policy that blocks completion and has not run, has expired, was built for an older commit, or failed.
  • GitHub: Re-run a failed Actions job, Approve and run a workflow waiting for approval, or Approve or Reject a deployment waiting on a protected environment you can review.

Approvals ask for confirmation. Prokop checks that the job or policy belongs to the commit you are reviewing before starting it; provider permissions still apply.

Drafts and viewed files

Unsent feedback is saved in this browser, scoped to server, workspace, checkout, repository, account, and PR. Viewed-file markers are also local and scoped to the reviewed commit. A new source commit clears line selection and viewed markers.

Refresh and limits

Successful and failed Prokop mutations broadcast refresh events because a timed-out command may still have changed the remote PR. Writes do not retry automatically. After an uncertain result, refresh and check for the new comment, PR, or merge before submitting again. Azure posts review comments and votes in separate calls; if only the comment succeeds, the error asks you to retry only the vote.

Visible queries refresh when stale on view entry and after reconnecting. Changes made outside Prokop, including CI completion, need Refresh while the view stays open. There is no polling or webhook subscription.

Search and involvement filters apply to loaded PRs. Use Load more for additional results. GitHub activity reads are bounded and show a warning when truncated. Provider patches can omit large sections; binary and oversized patches show an unavailable message. Azure text versions are limited to 250,000 characters and patch lookup to the first 3,000 changed files. Open the provider link for content outside these limits.

Implementation entry points

  • SDK contracts: packages/sdk/src/shared-types/pullRequest.ts; REST namespace: packages/sdk/src/rest/pull-requests.ts.
  • Server use cases: packages/server/src/application/pull-requests/index.ts; CLI transport and adapters: packages/server/src/infrastructure/pull-requests/. Azure tenant resolution, tokens and REST calls live in azure-rest.ts.
  • Client workspace view: packages/client/src/components/pullRequests/PullRequestsView.tsx; event handling: packages/client/src/handlers/serverMessage/pullRequestHandlers.ts.

Automated verification uses injected CLI responses and component tests. Real provider authentication, remote writes, and browser geometry need a manual smoke test before release.

Spotted something wrong or missing? Open an issue ↗