<!-- https://logikflow.yemzikk.in/docs/introduction.md -->

# Introduction

LogiKFlow shows a GitHub pull request with its changed files in a reading order chosen by the author, instead of alphabetically. Files are grouped into sections, explained with notes, and paired with checklists that tell reviewers what to verify.

## Why

GitHub lists changed files by path. A reviewer opening a pull request usually meets the layout files and resources first, then the UI, and only at the end the model or feature flag everything else depends on. They end up reading the change backwards, or jumping around to rebuild the author's mental model.

The author already knows the right order. LogiKFlow lets them write it down once, or ask a coding agent to do it, so every reviewer reads the change the way it was built.

## What you get

- **A reading order.** Files appear in the order they should be read, usually in dependency order: contracts and flags first, then models, logic, storage, UI and resources.
- **Sections and notes.** Related files are grouped under a title, with a short note on what changed and why.
- **Review checklists.** Specific things to verify, such as "With the flag off, the list is unchanged". Each reviewer ticks their own, and everyone sees who checked what.
- **Viewed tracking.** Mark files as viewed. It's saved to your account, so it follows you across devices, and it resets for a file when that file changes.
- **History.** Every saved order is a version you can restore.
- **AI agents.** Connect Claude Code, Cursor or another MCP client and say "Arrange PR #123 in LogiKFlow". The agent reads the change, builds the order and gives you the link.

## How it fits your workflow

1. Finish the change and open the pull request on GitHub as usual.
2. Arrange it in LogiKFlow, either by hand in the web app or by asking your agent.
3. Share the LogiKFlow link with reviewers, or post it to the pull request with one click.
4. Reviewers follow the order, tick Viewed and checklist items, and leave their comments on GitHub as usual.

LogiKFlow doesn't replace GitHub reviews. Approvals, comments and merging stay on GitHub. LogiKFlow changes the order and adds context.

## Next steps

- [Quickstart](/docs/quickstart): sign in and arrange your first pull request.
- [Arrange with AI agents](/docs/agents): connect your coding agent.
- [Ordering guide](/docs/ordering-guide): the rules for a good reading order.

---

<!-- https://logikflow.yemzikk.in/docs/quickstart.md -->

# Quickstart

Arrange your first pull request in about five minutes.

## 1. Sign in

Open [https://logikflow.yemzikk.in](https://logikflow.yemzikk.in) and choose **Sign in with GitHub**. LogiKFlow reads pull requests through your GitHub account, so you see exactly what you can see on GitHub.

## 2. Install the app for private repositories

Public repositories work right away. For a private repository, the LogiKFlow GitHub App must be installed on the account or organization that owns it:

1. Open the install page, linked from your dashboard as **Install LogiKFlow**.
2. Choose the account or organization.
3. Pick **All repositories** or only the ones you want.

Organization owners may need to approve the installation. The app asks for read access to code and pull requests, plus write access to pull requests so it can post the review link as a comment.

## 3. Open a pull request

On your dashboard, paste a pull request link such as `https://github.com/acme/app/pull/123`. Or take any pull request URL and replace `https://github.com` with `https://logikflow.yemzikk.in`:

```text
https://github.com/acme/app/pull/123
https://logikflow.yemzikk.in/acme/app/pull/123
```

LogiKFlow redirects that to the review page at `https://logikflow.yemzikk.in/r/acme/app/pull/123`. Tabs such as `/files` or `/commits` at the end of the URL are fine. The same works for a repository (`https://logikflow.yemzikk.in/acme/app`), which lists its pull requests.

You see the changed files in alphabetical order, like GitHub, until someone saves an order.

## 4. Arrange it

You need write access to the repository.

**By hand:** choose **Arrange files**. Drag files by the handle, or use the arrows, into reading order. Add sections with **Add section**, and add notes and checklist items where they help. Choose **Save order**. See [Arranging a pull request](/docs/arranging).

**With your agent:** connect LogiKFlow to Claude Code or another MCP client once:

```bash
claude mcp add --transport http logikflow https://logikflow.yemzikk.in/mcp
```

Then, in the repository's checkout, ask:

```text
Arrange PR #123 in LogiKFlow in logical order.
```

See [Arrange with AI agents](/docs/agents).

## 5. Share it

Use **Copy link**, or **Post to PR** to add a comment on the pull request with the link and the section list. Reviewers open the link, sign in, and follow the order. See [Reviewing a pull request](/docs/reviewing).

---

<!-- https://logikflow.yemzikk.in/docs/arranging.md -->

# 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:

| Instead of | Write |
|---|---|
| Kotlin files | Grouping model |
| Models | Storage works on groups |
| UI | Highlight overlay and action menu |

Three to eight sections suit most pull requests. The [ordering guide](/docs/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.

---

<!-- https://logikflow.yemzikk.in/docs/reviewing.md -->

# Reviewing a pull request

Open the link the author shared, or any pull request at `https://logikflow.yemzikk.in/r/<owner>/<repo>/pull/<number>`, and sign in with GitHub.

## Read in order

The toolbar says whose order you're looking at and when it was saved, for example *Reading order by octo · 2 hours ago*. Read top to bottom:

- **Sections** start with a title, a note from the author, and sometimes a checklist.
- **File cards** show the diff, with the author's note and checklist above it when there is one.
- The **file tree** on the left follows the same order and highlights the file you're reading. Type in the filter box to find a file by path.

Diffs over 400 changed lines, and files the author labelled **Generated**, start collapsed. Open one with the arrow in its header. Collapse a whole section with the arrow next to its title. Each section shows how many of its files you've viewed.

### Focus labels

Authors can label files so you know where to spend your attention:

| Label | Meaning |
|---|---|
| **Key file** | The heart of the change. Read it carefully. |
| **Skim** | Mechanical or low-risk, such as a rename or a string. |
| **Generated** | Generated or vendored output. Collapsed by default. |

### Comments

A speech-bubble count in a file's header, and in the file tree, shows how many review comments the file has on GitHub. Click it, or the GitHub icon, to open that file's diff on GitHub.

## View settings

The gear button in the toolbar holds the diff settings. Your choices are remembered in this browser.

- **Unified** (one column) or **Split** (old and new side by side).
- **Hide whitespace:** hides lines whose only change is whitespace, such as indentation.
- **Compact line height:** fits more lines on screen.
- **Expand all** and **Collapse all**.

Changed lines also highlight the exact characters that changed.

## Keyboard shortcuts

| Key | Action |
|---|---|
| `j` / `k` | Next or previous file |
| `n` | Next file you haven't viewed |
| `v` | Mark the current file viewed and go to the next one |
| `e` | Expand or collapse the current file |
| `o` | Open the current file in GitHub |
| `s` | Switch between unified and split |
| `?` | Show all shortcuts |

## Viewed

Tick **Viewed** on a file when you're done with it. The card collapses and the file tree shows a check.

- Viewed is saved to your account, so it follows you to other devices and browsers.
- It's tied to the file's content. If the author pushes a change to that file, it becomes unviewed again, so you never miss a change.
- When that happens, the file shows **Changed since you viewed**. Choose it to see only what changed since you last looked, instead of the whole diff again. Choose **Show full diff** to switch back.
- **Clear viewed** unticks every file in the pull request at once, for when you want to start the review again.

The meter in the toolbar shows how many files you've viewed. The people button next to it shows everyone's progress: files viewed and checklist items ticked.

## Checklists

Tick checklist items as you verify them. Your ticks are saved and shown to everyone: each item lists who checked it, and each section shows how many you've checked. Untick an item to take your check back.

## Comments and approval

Leave review comments and approvals on GitHub as usual; **Open on GitHub** takes you there. LogiKFlow is for reading the change in the right order. It doesn't replace GitHub's review tools.

## Refresh

**Refresh** reloads the pull request from GitHub, including new commits and the latest saved order.

---

<!-- https://logikflow.yemzikk.in/docs/agents.md -->

# Arrange with AI agents

Once your pull request is open, ask your coding agent to arrange it. The agent reads the change, orders the files so each comes after what it depends on, groups them into sections with notes and checklists, saves the order, and gives you the link.

```text
Arrange PR #123 in LogiKFlow in logical order.
```

LogiKFlow is a remote [MCP](https://modelcontextprotocol.io) server, so it works with any agent that supports remote MCP servers with OAuth.

## Connect

The server URL is:

```text
https://logikflow.yemzikk.in/mcp
```

### Claude Code

```bash
claude mcp add --transport http logikflow https://logikflow.yemzikk.in/mcp
```

Then run `/mcp` in Claude Code, select **logikflow**, and choose **Authenticate**. Add `--scope user` to the command to make it available in every project, not just the current one.

### Cursor

Add to `~/.cursor/mcp.json`, or `.cursor/mcp.json` in a project:

```json
{
  "mcpServers": {
    "logikflow": { "url": "https://logikflow.yemzikk.in/mcp" }
  }
}
```

### VS Code

Add to `.vscode/mcp.json`:

```json
{
  "servers": {
    "logikflow": { "type": "http", "url": "https://logikflow.yemzikk.in/mcp" }
  }
}
```

### Other clients

Add a remote server that uses the streamable HTTP transport, with the URL above. The client registers itself automatically.

### Signing in

The first time, your browser opens a LogiKFlow page asking whether the app may act for you. It shows which app is asking and where access is sent. Choose **Allow**, then sign in with GitHub. For private repositories, the LogiKFlow GitHub App must be installed on the owning account or organization; see [Quickstart](/docs/quickstart#2-install-the-app-for-private-repositories).

## Ask

Run the agent from the repository's checkout. It can then read the whole codebase, not just the diff, and the order is much better.

```text
Arrange PR #123 in LogiKFlow in logical order.
```

```text
Create a LogiKFlow review for https://github.com/acme/app/pull/123 and add review checklists.
```

```text
Arrange the open PR for this branch in LogiKFlow.
```

```text
I pushed new commits to PR #123. Re-arrange it in LogiKFlow and keep the existing sections where they still fit.
```

Say what you care about and the agent takes it into account, for example "put the migration first" or "keep the tests at the end".

## What the agent does

1. Reads the [ordering guide](/docs/ordering-guide) with `get_ordering_guide`.
2. Fetches the changed files and any saved order with `get_pull_request`.
3. Studies the change, locally if it can, or from the patches.
4. Saves the order with `save_reading_order`.
5. Replies with the review link.

The [MCP reference](/docs/mcp-reference) documents each tool.

## Safety

- **The agent acts as you.** It reads only what your GitHub account can read, and saves only on repositories where you have write access.
- **It can't drop or invent files.** Every changed file must appear exactly once, or nothing is saved and the agent gets the list to fix.
- **It can't silently overwrite.** If someone saved a new order in the meantime, the agent gets a conflict and asks you.
- **It's labelled.** Orders saved by an agent say *arranged by octo's AI agent* on the page and in History, and any earlier version can be restored.
- **You can disconnect.** Remove the server from your agent.

## Troubleshooting

| Message | What to do |
|---|---|
| GitHub access for this connection has expired | Reconnect: in Claude Code, `/mcp`, then **Authenticate**. |
| This pull request doesn't exist or this account can't see it | Check the owner, repo and number. For a private repository, install the GitHub App on the owning account. |
| doesn't have write access | Only people who can push to the repository can save an order. |
| The order must list every changed file exactly once | The agent will usually fix this itself. If it doesn't, ask it to call `get_pull_request` again and include every file. |
| Conflict | Someone saved a newer order. Ask the agent to fetch it and decide whether to replace it. |
| Rate limited | Wait a minute. The limit is 120 requests per minute per person. |

---

<!-- https://logikflow.yemzikk.in/docs/ordering-guide.md -->

# Ordering guide

How to arrange a pull request's changed files into a reading order for reviewers. It applies to people using arrange mode and to AI agents, which receive this page from the `get_ordering_guide` tool.

The goal: a reviewer who reads top to bottom always meets a piece of code after the things it depends on, and understands why each group of files changed.

## Workflow for agents

1. Call `get_pull_request` with the owner, repo and number. It returns every changed file, the current saved order (if any) and its `version`.
2. Understand the change. If you are running inside a checkout of the repository, read the diff and the surrounding code there (for example `git diff <base>...<head>`); that gives far better results than patches alone. Otherwise call `get_pull_request` again with `include_patches: true`.
3. Build the order following the rules below.
4. Call `save_reading_order` with `base_version` set to the `version` you received (0 when there was no order). If it reports missing or unknown paths, fix the list and save again. If it reports a conflict, someone else saved in the meantime: fetch again, and only overwrite if the user wants that.
5. Tell the user the review link returned by the save.

## Ordering rules

Order by dependency: a file comes after the files it uses, before the files that use it. When there is no dependency between files, use these layers, top to bottom:

1. **Contracts and switches**: feature flags, remote config, constants, API schemas, database migrations, public interfaces, event names.
2. **Models and types**: data classes, DTOs, enums, type definitions.
3. **Core logic and utilities**: pure functions, parsers, algorithms, helpers the rest builds on.
4. **Storage and data access**: repositories, caches, persistence, network clients.
5. **Application logic**: controllers, services, view models, use cases, state holders.
6. **Presentation**: views, components, adapters, screens, templates.
7. **Wiring**: dependency injection, routing, entry points, platform glue that only connects the pieces above.
8. **Resources**: layouts, drawables, styles, strings, dimensions, assets, translations. Put the main screen layout before the small pieces it includes.
9. **Build and tooling**: build scripts, CI, lint config, generated files, lockfiles.

Tests go directly after the file they test, not in a separate block at the end, unless a test covers many files at once; then put it after the last of them.

Other rules:
- Deleted files go next to the file that replaced them, so the reviewer compares old and new together.
- A renamed or moved file with no real changes goes in the Build and tooling section or the last section.
- If one file is the heart of the change, it may come first with a note, even if it depends on small files; say so in the section note.
- Every changed file appears exactly once. Do not invent paths.

## Sections

Group the files into 3 to 8 sections. A very small pull request (under 5 files) can use one section or none.

- **Title**: a short noun phrase naming what the group does in this change, such as "Feature flag and analytics events" or "Storage works on groups". Not a file type ("Kotlin files") or a layer name alone ("Models").
- **Note**: one to three plain sentences saying what changed and why, and anything the reviewer should keep in mind. Name concrete classes, functions or flags in `backticks`. Don't restate the file list.

## File notes

Add a note to a file only when it helps the review: a non-obvious reason, a risk, a follow-up, or "mechanical rename, skim". Most files need no note. Keep notes to one or two sentences.

## Focus labels

A file can carry one focus label:

- `key`: the heart of the change, where most of the review effort should go. Use it for one to three files, never most of them.
- `skim`: mechanical or low-risk, such as renames, string changes and simple wiring.
- `generated`: generated, vendored or lock files. They start collapsed for reviewers.

Leave most files without a label.

## Checklists

Checklist items tell the reviewer what to verify. Add them to a section or file when there is something specific and checkable:

- Good: "With the flag off, the list is identical to before", "`removeRecentClipGroup` also deletes the extracted clips", "Back key closes the highlight before the page".
- Bad: "Code looks good", "Check for bugs", "Review this file".

Use 0 to 4 items per section and at most one or two per file. Keep each item under 120 characters.

## Style

Write for a busy reviewer: short, specific, no filler, no marketing tone, no emoji. Use the terms the code uses.

---

<!-- https://logikflow.yemzikk.in/docs/mcp-reference.md -->

# MCP reference

LogiKFlow's MCP server lets an agent read a pull request and save its reading order.

| | |
|---|---|
| Endpoint | `https://logikflow.yemzikk.in/mcp` |
| Transport | Streamable HTTP (stateless, JSON responses) |
| Authorization | OAuth 2.1 with PKCE; scope `reviews` |
| Server name | `logikflow` |

## Tools

### get_ordering_guide

Returns the [ordering guide](/docs/ordering-guide) as Markdown. Call it once before saving an order. It takes no input and is read-only.

### get_pull_request

Returns a pull request's changed files, the saved order and its version, whether you may change the order, and the review link. Read-only.

| Input | Type | Required | Description |
|---|---|---|---|
| `owner` | string | yes | Repository owner, for example `acme` |
| `repo` | string | yes | Repository name, for example `app` |
| `number` | integer | yes | Pull request number |
| `include_patches` | boolean | no | Include each file's diff. Default `false`. Each file is capped at 20,000 characters and the response at 400,000. |

Result (JSON text):

```json
{
  "reviewUrl": "https://logikflow.yemzikk.in/r/acme/app/pull/123",
  "repository": "acme/app",
  "pullRequest": {
    "number": 123, "title": "Add grouped clipboard", "state": "open",
    "author": "octo", "base": "develop", "head": "clipboard-new", "headSha": "9fce14f", "url": "https://github.com/acme/app/pull/123"
  },
  "canArrange": true,
  "filesTruncatedByGitHub": false,
  "files": [
    { "path": "app/src/main/java/.../ClipboardStorage.kt", "status": "modified", "additions": 79, "deletions": 10 }
  ],
  "currentOrder": null,
  "baseVersion": 0
}
```

`currentOrder`, when an order exists, has `version`, `updatedBy`, `source` (`web` or `agent`), `savedBeforeLatestCommits` (true when commits were pushed after it was saved) and `sections` in the same shape `save_reading_order` takes. `status` is GitHub's: `added`, `removed`, `modified`, `renamed`, `copied`, `changed` or `unchanged`. Renamed files also have `previousPath`.

### save_reading_order

Saves the reading order, replacing the current one. Earlier versions stay in history. Requires write access to the repository.

| Input | Type | Required | Description |
|---|---|---|---|
| `owner` | string | yes | Repository owner |
| `repo` | string | yes | Repository name |
| `number` | integer | yes | Pull request number |
| `base_version` | integer | yes | `baseVersion` from `get_pull_request`; `0` when no order exists |
| `sections` | array | yes | 1 to 50 sections, in reading order |

Each section:

| Field | Type | Description |
|---|---|---|
| `title` | string, optional | Up to 200 characters. Omit only for a single untitled group in a tiny pull request. |
| `note` | string, optional | Up to 4,000 characters. Backticks render as code. |
| `checks` | string[], optional | Up to 20 checklist items, each up to 300 characters |
| `files` | array | Files in reading order: `{ "path", "note"?, "checks"?, "focus"? }` with the same limits. `focus` is `key`, `skim` or `generated`. |

Example input:

```json
{
  "owner": "acme", "repo": "app", "number": 123, "base_version": 0,
  "sections": [
    {
      "title": "Feature flag and analytics",
      "note": "Everything new is behind `enable_new_clipboard_experience`, off by default.",
      "checks": ["With the flag off, the clipboard page is unchanged"],
      "files": [{ "path": "app/src/main/java/.../RemoteConfigs.kt" }]
    },
    {
      "title": "Grouping model",
      "files": [
        { "path": "app/src/main/java/.../ClipboardListItem.kt" },
        { "path": "app/src/main/java/.../ClipExtractionUtils.kt", "note": "Clips with time 0 are never grouped.", "focus": "key" }
      ]
    }
  ]
}
```

Result:

```json
{ "saved": true, "version": 1, "reviewUrl": "https://logikflow.yemzikk.in/r/acme/app/pull/123", "sections": 2, "files": 3, "checklistItems": 1 }
```

A checklist item with the same text in the same section or file keeps its identity across saves, so reviewers' ticks survive a re-arrange.

## Errors

Tool errors come back as a result with `isError: true` and a message the agent can act on. Nothing is saved when a save fails.

| Situation | Message starts with |
|---|---|
| A changed file is missing, unknown or listed twice | The order must list every changed file exactly once |
| Someone saved a newer version | Conflict: … saved version N |
| No write access | … doesn't have write access |
| Invalid input, such as an empty checklist item | The order is invalid |
| Pull request not visible | GitHub says this pull request doesn't exist or this account can't see it |
| GitHub token expired or revoked | GitHub access for this connection has expired |
| GitHub rate limit | GitHub's rate limit was reached |

## Authorization

LogiKFlow follows the [MCP authorization specification](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization).

| Endpoint | Path |
|---|---|
| Protected resource metadata | `/.well-known/oauth-protected-resource/mcp` |
| Authorization server metadata | `/.well-known/oauth-authorization-server` |
| Authorization (consent page) | `/authorize` |
| Token | `/oauth/token` |
| Dynamic client registration | `/oauth/register` |

Client ID metadata documents are also accepted. Unauthenticated requests to `/mcp` get `401` with a `WWW-Authenticate` challenge.

- **Access tokens** last up to one hour and are refreshed automatically.
- **Refresh tokens** last 30 days from last use and at most 180 days.
- **Rate limit:** 120 MCP requests per minute per person.

---

<!-- https://logikflow.yemzikk.in/docs/security.md -->

# Security and privacy

LogiKFlow is built to see no more than you can, and to store as little as possible.

## Access

- **Your permissions, not the app's.** Every request to GitHub uses your own token. You see only repositories and pull requests your account can see.
- **Writing an order requires write access.** LogiKFlow asks GitHub for your permission on the repository before every save.
- **Private repositories need the app installed.** The owning account or organization decides which repositories the LogiKFlow GitHub App can reach, and can remove it at any time.

## What the GitHub App can do

| Permission | Why |
|---|---|
| Contents: read | Show diffs of changed files |
| Pull requests: read and write | Read pull requests; write only to post the review link as a comment when you choose **Post to PR** |
| Metadata: read | Required by GitHub for every app |

LogiKFlow never pushes code, changes branches or approves pull requests.

## What's stored

| Data | Purpose |
|---|---|
| Your GitHub user ID, login and avatar URL | Show who saved an order or ticked an item |
| Sessions: a hash of the session token and your GitHub tokens, encrypted | Keep you signed in |
| Reading orders: file paths, section titles, notes, checklist text, and each version | The feature itself |
| Viewed files and checklist ticks | Your review progress |
| Recently opened pull requests (repo, number, title) | Your dashboard |

LogiKFlow doesn't store source code or diffs. They're fetched from GitHub when you open a pull request.

## How it's protected

- GitHub tokens are encrypted with AES-256-GCM before they're stored. Session cookies hold a random token, and only its SHA-256 hash is stored.
- Cookies are `__Host-` prefixed, HttpOnly, Secure and SameSite=Lax.
- Every change must come from the LogiKFlow site itself and be sent as JSON, which blocks cross-site request forgery.
- A strict Content Security Policy, HSTS and `nosniff` are sent on every page.
- Agent connections use OAuth 2.1 with PKCE and a consent page that can't be framed or forged, and follow the MCP authorization specification.
- Requests are rate limited per person.

## Signing out and disconnecting

- **Sign out** on any page ends the session and deletes it.
- To disconnect an AI agent, remove the LogiKFlow server from the agent.
- To revoke LogiKFlow entirely, go to GitHub → Settings → Applications → Authorized GitHub Apps.

---

<!-- https://logikflow.yemzikk.in/docs/faq.md -->

# FAQ

## Does LogiKFlow replace GitHub reviews?

No. Comments, approvals and merging stay on GitHub. LogiKFlow changes the order you read the files in and adds the author's context and checklists.

## Do reviewers need to do anything to see the order?

They open the LogiKFlow link and sign in with GitHub. There's nothing to install. For private repositories, the app must already be installed on the owning account or organization.

## Who can change the order?

Anyone with write access to the repository. Everyone who can read the repository can see it.

## What happens when I push new commits?

Files you placed keep their positions. New files appear at the end under **Not in the saved order**, and removed files disappear. A file you marked as viewed becomes unviewed if it changes. Ask your agent to re-arrange, or place the new files by hand.

## Does it work with GitHub Enterprise or GitLab?

Not yet. LogiKFlow works with github.com.

## Which AI agents work with it?

Any agent that supports remote MCP servers with OAuth, including Claude Code, Cursor, VS Code, Windsurf and others. See [Arrange with AI agents](/docs/agents).

## Does the agent send my code to LogiKFlow?

No. The agent sends only the reading order: file paths, section titles, notes and checklist items. Your code stays between your agent, your machine and GitHub.

## Is there a limit on pull request size?

GitHub returns at most 3,000 changed files for a pull request, and omits the diff for very large or binary files. LogiKFlow shows a warning when files are missing, and a link to GitHub for files without a diff.

## Is it free?

Yes. LogiKFlow is free during early access. Paid plans may come later, and they'll be announced before anything changes.