PR Slicer

Plan dependency-aware Git commits and split large changes into reviewable, size-limited units.

PR Slicer is a local-first VS Code extension for the change you already have. It reads the selected repository, groups related changes, checks the plan before anything is written, creates the approved commits, and helps you push and raise the pull request with the Git and GitHub tooling you already use.

Every commit is kept within your line limit (390 changed lines by default, counted as additions + deletions), so every pull request stays small enough to review.

No GitHub password or personal access token is requested, collected or stored. PR Slicer does not create a login flow, copy a browser session, or use another tool's sign-in (it does not use the GitHub CLI). Local analysis is done on your machine; network access happens only when you run a Git push or fetch. Pull requests are created on GitHub, in your own browser.

Analyze -> Commit planning -> Validation -> Commit & push -> Pull request

Install

Install PR Slicer from the Visual Studio Code Marketplace (Extensions view, search for "PR Slicer", or ext install SaiKiranYarabarla.pr-slicer in Quick Open).

To build and install it from source instead:

npm install
npm run package
code --install-extension pr-slicer-0.1.0.vsix

Reload the VS Code window, open a Git repository, and run PR Slicer: Analyze Changes & Suggest Commits from the Command Palette. The full workflow is in the PR Slicer sidebar or the dashboard.

For a source checkout, the security checks are:

npm run lint
npm test
npm run audit:security
npm run audit:deps
npm run package
npm run verify:package

See SECURITY.md, PRIVACY.md, and the security audit for the verified details.

How it works

• Extension host (TypeScript). The extension runs where the repository lives. It inspects Git, parses changed lines, detects Java/Groovy and Python dependencies, builds the commit plan, validates it, and writes commits with a temporary index so the user's index and working tree are preserved.
• Dashboard. The same renderer is used as a VS Code webview and as an optional loopback page in a normal browser. It displays state and sends bounded actions; it never runs Git itself.
• Git and GitHub handoff. Commits are local Git operations. Pushes and browser pages are started only by an explicit action. Git runs non-interactively with the user's own setup; pull requests are created, listed and merged on GitHub in the browser. There is no API client, no GitHub CLI use and no stored token in the extension.
• State. Workflow state is in memory for the selected repository and is cleared when the workspace folder changes. Settings and the loopback theme are the only persisted preferences. See PRIVACY.md.

---

Why it exists

Many organizations only accept pull requests under a fixed size (the default here is at most 390 changed lines, additions + deletions). Splitting a big feature by hand is slow and error-prone: you have to work out which files belong together, count the diff of every candidate, and keep every commit consistent. The limit is a configurable review policy, not a GitHub rule; confirm the number with your organization.

PR Slicer does the mechanical part and refuses to lie about the result:

• a commit counts only when it is within the limit (390 changed lines pass, 391 fail)
• a group that would be too large is split into several commits, never silently dropped
• a file that is too large on its own gets a commit of its own, and you pick the hunks that go into it - the rest stays in your working tree
• binary files have unknown line counts and are reported as a warning, never counted as a safe 0
• the exact commands are shown as a dry run before anything is executed
• the commits are built in a temporary index, so your staged work, your unstaged work and your untracked files are never touched

---

The workflow

1. Changes - what does the repository look like?

The dashboard shows the repository as it is right now:

• repository name and working directory
• the current branch and the branch the pull request would target
• the configured remote (with any credentials removed from the URL) and its host
• added, modified, deleted, renamed and untracked files, staged and unstaged
• how far the branch is ahead of or behind its upstream
• whether git is available

Press Analyze changes to read the working tree.

2. Commit planning - how should the changes be grouped?

The changes are grouped the way a reviewer would expect them to be grouped - never just because two files share a folder:

• a test stays with the implementation it covers (tests/checkout.test.ts + src/services/checkout.ts, OrderServiceSpec.groovy + OrderService.java)
• a lockfile stays with its manifest (package-lock.json + package.json)
• imports/includes between changed files pull them together, but an import on its own is only an uncertain hint; the planner looks for real symbol use, calls, inheritance, constructors and static members
• for Java/Groovy and Python, a dependency that is actually used is mandatory: the files stay in the same commit even when the group is over the limit, and the dashboard reports the conflict instead of silently splitting them
• Spring stereotypes decide the layer (@RestController, @Entity, @Service, @Configuration), because in a Spring project the path says nothing

Every group can be edited before anything happens:

You can	How
approve or unapprove a commit	the checkbox next to the summary
write the summary and the description	the Describe the commits form at the bottom - pick the commit, then write
move a file to another commit	the move to... menu
leave a file out of the plan	leave out
pick the hunks of a file	the numbered hunk buttons under the file
see what a file really changes	preview - a GitHub-style diff, opened only when you ask for it

Nothing is written until you approve the plan.

The summaries live in one place, the way GitHub Desktop does it: the cards stay clean and show the summary you wrote ("Commit 1", "Commit 2" until you write one), and the form on the plan page edits the commit you pick - Summary (required) for the title of the commit, Description for the text under it. With three commits you fill in three summaries, one after the other, in the same place - not three fields spread over the page.

The dashboard is a page-wise wizard. Only the step you are on is on the page: pick a commit on Plan the commits, press Check the plan in the footer (or the arrow at the end of the stage bar), and the dashboard moves to the next page instead of asking you to scroll. Every page ends with Back and a named Next button, and the footer says what will happen - for example "2 commits -> 1 pull request from feature/login into main".

The five stages at the top are rounded boxes of their own and keep their own state: a stage turns green as soon as it is finished (the analysis ran, the plan holds an approved commit, the validation passed, the commits were created, the pull request exists), and the stage you are in gets a green ring. A flat green progress bar under the row shows how far the flow has got - green is the progress colour throughout, while blue stays the colour of the actions and the tabs. A small pair of arrows at the end of the stage bar walks the flow; they stay disabled while the current page still has something to finish, and the footer says exactly what that is. A stage can still be clicked to jump straight to its page.

The ways through the flow

What you have	What you do	What PR Slicer does
One commit	Approve it, write the summary, press Check the plan	Creates the commit, pushes the branch, raises one pull request
Two or more commits	Approve the ones you want, write one summary each	Puts all of them on the same branch and raises one pull request with every commit
Two or three commits that are too big together	On the plan page press Split into N pull requests	Keeps every commit whole and puts one or more of them into each stacked pull request
A commit from another branch	Open the Cherry-pick tab	Applies the commits onto the branch you pick, then pushes and opens the pull request page
A file over 1,000 changed lines	On the plan page press Split into N pull requests, name the branches, press Create the branches	Builds one stacked branch per part, pushes them and opens every pull request in order

The branch is chosen in Where the commits go: it defaults to the branch you are already working on in the editor, so a single pull request comes from that branch. A new branch can be named instead, and the pull request always shows both ends (feature/login -> main) before it is raised. The branch the commits go on is never offered as its own pull request target, and the picker lists only the branches of the open repository.

A file that is bigger than the limit

When one file alone is bigger than the limit, the dashboard does not just warn - it asks:

index.html is too big for one commit. 900 changed lines, the limit is 390. Split it into parts, each one a pull request of its own - or take it apart yourself.

[Split into 3 pull requests] [I will do it myself]

Split into N pull requests does the work:

• the file is cut into parts that each stay inside the limit (one single huge change is cut into equal pieces)
• every part becomes a branch, and the branches are stacked: part 2 is based on part 1, so the pull requests are raised and merged in that order
• the branches are built in a temporary worktree - your working tree, your index and your current branch are never touched
• every part is measured again before it is committed, so nothing over the limit is ever pushed
• the dashboard shows the branches and, once they are pushed, the page of each pull request

Not one line is lost: the parts together bring the file back exactly as you wrote it (proved against a real repository for a rewrite, a new file and a deletion).

A file that is not tracked yet is split the same way: git diff says nothing about a brand-new file, so the extension describes it as the new file it is and cuts it into the same stacked parts. Nothing is added to your index.

I will do it myself leaves the file out of the plan - you split it by hand and the extension stays out of it.

A pull request with several commits

One pull request can hold two or three commits - that is the normal case. When the approved commits together are above the limit, the plan page offers a second split:

These commits would make one pull request with 520 changed lines. The limit is 390 changed lines. Split them into 2 stacked pull requests - every commit stays whole, and the pull requests are raised in order.

[Split into 2 pull requests]

The commits are cut at commit boundaries, never in the middle:

• commit 1 + commit 2 can go into the first pull request, commit 3 into the next
• every commit keeps its own message and history
• every pull request is measured against the one before it, so each stays inside the limit
• the branches are stacked (pr-slicer/pull-request-1, then pr-slicer/pull-request-2 on top of it) and pushed with your own git credentials
• a single commit that is already above the limit is not cut here - split that file first, then split the rest

Both kinds of split use the same temporary worktree, so your working tree, your index and the branch you are on are never touched.

After the split

You name the branches before anything is created. Pressing Split into N pull requests only works out how the file would be divided - no branch is created yet. The plan page then shows one field per part, pre-filled with a suggestion, and you write the names you want:

index.html will become 3 pull request(s) - name the branches:
                                                    [ Create the branches ]

part 1   [ feature/index-page-header  ]                          +300 -0
part 2   [ feature/index-page-body    ]                          +300 -0
part 3   [ feature/index-page-footer  ]                          +300 -0

Press Create the branches and the branches are created with your names, in the order you see them (each part is based on the one before it). If the split file was the whole plan, the dashboard moves straight to the pull request page; otherwise it stays on the plan for the remaining commits.

The dashboard then shows what was made, and you finish the job from the dashboard:

index.html was split into 3 pull requests.   The pages are open.

feature/index-page-header   part 1 of 3   +300 -0   open the pull request
feature/index-page-body     part 2 of 3   +300 -0   open the pull request
feature/index-page-footer   part 3 of 3   +300 -0   open the pull request

If a page did not open, Raise the pull requests opens (or creates) all of them again.

Raise the pull requests opens the compare page of every part in your browser, with the title and description filled in; you click Create pull request there.

Pressing Split again does not fail with "the branch already exists" - the branches that are already there are used as they are, and the dashboard carries on showing them.

3. Validation - a real dry run

The dry run checks the plan without changing anything:

• git is available and this really is a repository
• the branch is still the branch you planned for
• the repository has not changed since the analysis
• the changes are still in the working tree
• every approved commit has files and a message
• every commit stays within the line limit
• every dependency travels with its commit
• a remote is configured and the target branch exists on it
• active repository hooks are named, because Git will run them during the commit
• the remote is a GitHub remote, so the compare page can open (only for the pull request)

Each check says whether it was performed, simulated or cannot be verified until execution. A simulated push is never presented as a guarantee. While the checks run, a progress bar with a percentage shows how far the dry run is and which check is running right now.

4. Commit & push

The plan is re-validated, then the commits are created:

• the commits are created on the branch you are on, or on a new branch you name (created from the current HEAD, so no work is lost)
• the pull request target is a dropdown of every branch in the repository - local and remote-tracking, with the remote prefix removed
• only the changes you approved are committed - a file can go in with only some of its hunks
• your own staged changes, unstaged changes and untracked files are preserved
• the push uses your own git setup (an SSH key, or a sign-in your credential helper already saved) and never starts a sign-in prompt - see Credentials, privacy and network access

5. Pull request (optional)

The pull request is a separate, optional step - and it works with the tools your company already gave you:

1. The branch is pushed with git, non-interactively, using the authentication you already set up yourself. The extension never sees a credential and never starts a sign-in.
2. The compare page opens in your normal browser, where you are signed in already, and you create the pull request the way you always do. PR Slicer does not use the GitHub CLI or any GitHub API, so it never uses another tool's session.
3. GitHub Enterprise is supported: the repository's own remote decides the host.

The dashboard does not ask for a pull request URL. You finish the pull request on GitHub; there is nothing to paste back, because the extension does not store the address. A page that is refreshed starts again from the machine: the analysis runs again and you get a normal, fresh dashboard.

The dashboard never says "a tool is missing" - it says what will happen.

If the pull request cannot be created, the commits and the push stay exactly as they are and the dashboard tells you what to do next.

Your pull requests

The last step of the workflow includes Your pull requests: the pull requests you raised in this repository - open, merged and closed - on GitHub, with the branches they join and their last update. Open on GitHub opens that filtered list in your browser, where you are signed in already. The extension never reads the list itself and never handles a token.

The small arrows under the stage bar walk the workflow, and an open diff preview has the same arrows to walk the files of that commit without closing it.

6. Cherry-pick a commit onto another branch

The Cherry-pick tab, next to Workflow at the top of the dashboard, does what GitHub's cherry-pick button does, on your own machine. Opening the tab loads the commits of the current branch; the workflow pages stay exactly where they were. The branch pickers list only the branches of the open repository, and the source branch is not offered as its own target.

1. From - pick the branch whose commits you want. Its latest commits are listed with the author, the date and their size.
2. Tick the commits. A commit that the base branch already has is marked already there and is skipped, so the same change is never applied twice.
3. Onto - pick the branch the commits land on. By default a new branch is created from it (the name is suggested from the first commit and can be edited); untick Create a new branch to add the commits to that branch directly.
4. Cherry-pick applies the commits oldest first, with -x so git records where each one came from.

The pick is careful: it needs a clean working tree, it refuses to start while another merge, rebase or cherry-pick is in progress, and it refuses commits that are not on the source branch. A conflict changes nothing - the pick is aborted, a half-created branch is removed and you are put back on the branch you started from. Undo removes exactly the commits the pick created and only while they are still the tip and were not pushed. Push & open pull request pushes the new branch with your own git authentication and opens the compare page, like the rest of the workflow.

---

Credentials, privacy and network access

PR Slicer is built around a small, explicit credential boundary:

• no token, password or login field anywhere in the UI
• no OAuth or device-code flow is started by the extension
• the extension does not read, copy or store credentials - not in SecretStorage, not in workspace or global state, not in a file; it does not write one into an environment variable
• no cookie or session of a browser or of VS Code is copied into the extension
• no telemetry, analytics, AI API, or background reporting exists in the extension
• no credential is written to a log; credential-like text (sign-ins inside URLs, tokens, authorization headers, cookies, passwords) is removed from every error before it is shown
• no other tool's sign-in is used - not the GitHub CLI, not VS Code's accounts, not a browser profile, not Devin

Local analysis, dependency detection, commit planning, line counting and dry runs use only the selected repository and local Git. They do not need GitHub authentication and start no other tool.

When you explicitly push or fetch, the extension starts git as a child process. Git uses your own, independently configured setup (an SSH key, or Git Credential Manager and whatever it already saved). PR Slicer never reads, asks for or inspects that credential, never changes your git configuration, and never parses credential-helper output. The child process inherits the environment as Node.js does by default; the extension reads no value from it.

Git always runs non-interactively from PR Slicer (GIT_TERMINAL_PROMPT=0, an empty GIT_ASKPASS, GCM_INTERACTIVE=never, -c credential.interactive=false for that one command). PR Slicer therefore never starts a password prompt or a Git Credential Manager sign-in, and never causes a new entry in Windows Credential Manager. If the push cannot authenticate with what you already have, it fails safely and the dashboard tells you to sign in with your organization's approved Git workflow, outside PR Slicer - or to push yourself. The commits stay safe either way.

Pull requests are created, listed and merged on GitHub in your browser, where you are signed in already. PR Slicer only builds the page address.

The only user-triggered network destinations are the Git remote of the selected repository (through git) and GitHub pages opened in your browser. See PRIVACY.md for the full inventory.

---

Failure recovery

User work is treated as valuable:

• never git reset --hard, never git clean, never a force-push
• a failed step never rolls back the steps that already succeeded
• after a failure the dashboard says what completed, what failed, whether the commits exist, whether the push worked and what is safe to do next
• the execution log contains operation names and outcomes - and no secrets

---

Commands

Command	What it does
PR Slicer: Analyze Changes & Suggest Commits	read the working tree and suggest a plan
PR Slicer: Dry Run: Validate the Plan (writes nothing)	check the plan without changing anything
PR Slicer: Commit & Push the Approved Commits	create the approved commits and push them
PR Slicer: Push & Open the Pull Request Page (Browser)	push the branch, then open the compare page in your browser
PR Slicer: Open Compare Page in Browser (Raise PR)	open the compare page in your browser
PR Slicer: Open Dashboard	open the dashboard
PR Slicer: Open Dashboard in Browser (localhost)	serve the dashboard on http://127.0.0.1:7345
PR Slicer: Copy Commit Plan (Markdown)	copy the plan to the clipboard
PR Slicer: Discard the Current Plan	forget the plan (nothing on disk is touched)
PR Slicer: Reload Window (apply an extension update)	reload the editor window to pick up a freshly installed build

The sidebar is only a launcher: it chooses the browser and opens the dashboard. Everything else - the analysis, the commit plan, the commits, the push and the pull requests - happens in the dashboard itself. A circular refresh button on the launcher heading line does the same reload with one click, so a new build no longer needs the command palette.

Settings

Setting	Default	What it does
prSlicer.lineLimit	390	maximum changed lines in a single commit
prSlicer.countingRule	total	count additions + deletions, or only the added lines
prSlicer.branchPrefix	pr-slicer	prefix of a generated branch name
prSlicer.baseBranch	auto	the branch the pull request targets
prSlicer.dashboardPort	7345	port of the local dashboard server
prSlicer.protectedBranches	main,master,release/*,hotfix/*,prod/*	branches that are never written to
prSlicer.defaultBrowser	default	browser used for the dashboard and GitHub links
prSlicer.remote	(empty = detect)	the git remote to push to and read pull requests from - origin when it exists, otherwise the remote your branches track
prSlicer.cherryPickPrefix	cherry-pick	prefix of the suggested cherry-pick branch name, for example backport
prSlicer.forgetAfterCloseSeconds	30	seconds after the last dashboard tab closes before the session is forgotten; 0 = when VS Code closes

---

The dashboard opens in the browser you want. The sidebar has an Open in picker above the Open dashboard in browser button:

• System default - the same browser the editor uses for links
• Google Chrome, Microsoft Edge, Mozilla Firefox, Brave, Safari

Click the picker, choose a browser, then press Save - that browser is used from now on (prSlicer.defaultBrowser). Choosing alone changes nothing, and the button is always there, so you can change it whenever you like. The saved confirmation is a small square note under the picker and closes itself after five seconds. If the window has no repository, Open dashboard in browser shows the same kind of square notice - "Open a git repository first." - which leaves after five seconds and returns the next time it is needed.

The dashboard header has the same choice in a compact Links open in menu. Pick a browser there and it applies straight away - there is no second Save step - so open on GitHub, open in the pull request list and the dashboard's own links use that browser.

A browser that is not installed on your machine is marked not installed in the list, and the list says which ones are missing: "Not available on this system: Mozilla Firefox, Safari. Please install it to use it as the browser for PR Slicer."

The extension only starts the browser with a URL - it never reads a profile, a session or a cookie.

The local dashboard

The dashboard runs in the editor and in a normal browser on http://127.0.0.1:7345:

• it binds to the loopback interface only
• every request needs a session token that is handed out with the page (a SameSite=Strict cookie plus a header for changes)
• cross-site requests are refused
• the server never makes an outbound request of its own

The browser page is the full dashboard, not a viewer: Analyze changes, Run dry run, Commit & push and Create pull request all work from the browser, and the result of an action is shown as a short note on the page. When you open the dashboard the analysis has already run, so the page opens with a plan instead of an empty screen.

Requirements

• VS Code 1.85 or newer (also runs in VS Code based editors such as Antigravity and Devin Desktop)
• git on your PATH
• a browser for creating the pull request on GitHub (no other tool is needed)

Package identity

• Extension ID: saikiranyarabarla.pr-slicer
• Manifest publisher ID: SaiKiranYarabarla (IDs cannot contain spaces)
• Author: Sai Kiran Yarabarla
• Marketplace publisher profile display name: Sai Kiran Yarabarla

The VS Code extension page shows the manifest publisher ID for a locally installed .vsix. The spaced display name comes from the Marketplace publisher profile, which must be set to Sai Kiran Yarabarla in the Marketplace management page. Do not change the publisher ID to add spaces: that would change the extension ID and break updates.

---

Development

npm install
npm run compile     # build
npm test            # tests, real disposable Git repositories included
npm run lint        # type check
npm run audit:security
npm run audit:deps  # production dependency audit
npm run package     # build the .vsix
npm run verify:package
npm run reinstall   # uninstall + install the freshly built .vsix

scripts/ holds the development helpers (visual previews, packaging and security checks). They are not part of the published extension.

Security and limitations

• PR Slicer is not sandboxed from the operating system: like every VS Code extension it runs with the editor's permissions. It reduces what it does rather than claiming isolation.
• An open VS Code workspace is trusted or untrusted. Analysis, planning and dry runs work in an untrusted folder. Creating commits or branches, cherry-picking, pushing and creating pull requests require a trusted workspace.
• The extension reads the selected repository's changes, which is required for its purpose. It does not read unrelated files by design, but a Git repository can contain configuration that affects Git; review repository-controlled hooks and filters.
• The extension does not guarantee that an organization will approve it, that a remote is trustworthy, or that no vulnerability can ever exist. Review the source, the dependency audit and the package before deploying it.
• GitHub password/token login is deliberately not implemented. If Git cannot authenticate with your existing setup, the extension fails safely and tells you to use your organization's approved Git workflow.
• PR Slicer does not use the GitHub CLI or a GitHub API, so it does not create pull requests itself, read your pull request list, or detect an existing pull request number. Those pages open on GitHub in your browser instead.
• Git itself may use a credential you already saved (for example in Git Credential Manager, which keeps it in Windows Credential Manager) when you push. That is Git's own setup; PR Slicer never sees it and never starts a new sign-in.

To report a vulnerability, use the private GitHub Security Advisory flow described in SECURITY.md. Do not open a public issue with exploit details.

Marketplace security statement

PR Slicer is designed for local-first Git workflows. It does not request GitHub passwords or personal access tokens and delegates remote authentication to the user's existing Git environment. Local analysis and commit planning are performed on the selected repository. See the repository's security and privacy documentation for verified storage, network, and dependency details.

Support

• Bugs and feature requests: open an issue on the repository's GitHub Issues page.
• Security reports: use the private GitHub Security Advisory flow in SECURITY.md; do not publish exploit details.
• No account or support contract is required to use the extension. The project does not promise a response deadline, a specific fix date, or enterprise certification.
• Include the extension version, VS Code version, operating system, and the exact command that failed. Redact repository names, paths, logs, and credentials.

License

MIT. See LICENSE. The license grants permission to use, modify and distribute the software; it does not certify security or guarantee enterprise approval.