Arranging a pull request

The author of a change knows the order it makes sense in. Arrange mode is where you write that down.

#Who can arrange

Anyone with write access to the repository (push, maintain or admin on GitHub) can save an order. Everyone who can read the repository can see it. LogiKFlow checks your permission with GitHub on every save.

#Open arrange mode

On the pull request page, choose Arrange files. Every changed file is listed, in the current order or alphabetically if nothing is saved yet.

• Move a file or section: drag it by the handle (⋮⋮), or use ↑ and ↓. The arrows work with the keyboard too.
• Add a section: Add section puts a new section at the top. Give it a title, then move it where it belongs. Files below a section belong to it until the next section.
• Remove a section: Remove deletes the section header. Its files stay where they are.
• Start over: Reset to alphabetical removes all sections and sorts the files by path. Notes and checklist items on files are kept.

Nothing changes for reviewers until you choose Save order. Cancel or Esc discards your edits.

#Sections

A section groups files that change for the same reason. Good sections make a large pull request feel like a short story:

Three to eight sections suit most pull requests. The ordering guide has the full rules.

#Notes

Sections and files can have a note, shown above the section or the file's diff. Use notes to say why, which the diff can't show:

• the reason behind a non-obvious choice;
• what to watch out for;
• that a file is a mechanical rename and can be skimmed.

Wrap code in backticks, for example `isNewClipboardEnabled`, to show it as code.

#Focus labels

Give a file a focus label from the menu next to its path:

• Key file: the heart of the change. It's highlighted for reviewers.
• Skim: mechanical or low-risk.
• Generated: generated or vendored output. It starts collapsed.

Most files need no label. Use Key file for one to three files at most, or it stops meaning anything.

#Checklists

Add checklist items to a section or a file for things a reviewer should verify:

• "With the flag off, the list is unchanged"
• "Deleting a clip also deletes its extracted clips"
• "Back key closes the highlight before the page"

Each reviewer ticks their own boxes. Everyone sees who checked each item (✓ amal, octo), and each section shows how many items you've checked. Items keep their identity when you move files around or edit other parts of the order, so ticks aren't lost.

Avoid vague items such as "Check for bugs". If an item can't be verified, it doesn't belong on the list.

#When two people arrange at once

LogiKFlow uses versions. If someone else saves an order while you're editing, your save is stopped and you choose:

• Load their order: discard your edits and start from theirs.
• Overwrite with mine: save yours as the new version. Theirs stays in history.

#History and restore

History lists every saved version with who saved it, when, and whether an AI agent saved it. Restore saves an old version again as the newest one, so nothing is ever lost.

#Review progress

The people button in the toolbar shows who has started reviewing, how many files each person has viewed (counting only files that haven't changed since), and how many checklist items they've ticked.

#New commits after arranging

When commits are pushed after the order was saved, a banner says so and how many changed files aren't in the order yet. If you have write access, it offers Arrange files, and Copy agent prompt, which copies a one-line request you can paste into your agent to re-arrange.

The order stores file paths, so it survives new commits:

• Files you already placed keep their position.
• Files added to the pull request later appear at the end, under Not in the saved order. Arrange again to place them.
• Files removed from the pull request disappear from the order.

#Post the link to the pull request

Post to PR adds a comment on the GitHub pull request with the review link and the list of sections. It's posted as you, and needs the Pull requests: write permission on the app installation.

After the first post, the button becomes Update PR comment. It edits the same comment instead of adding a new one, so re-arranging never clutters the pull request. If the comment was deleted, or someone else posted it and you can't edit it, a new comment is posted.