A personal board on top of your GitHub issues, with a private half (notes, moved cards, how it looks and which parts show, what you pushed down, and what it counts) that follows you between devices. It runs entirely in your browser: there is no server, no account to make here, and nothing is stored anywhere except GitHub.

• Every open issue and pull request assigned to you, across every repository your token can read, in one list, each marked with what it is.
• A title says what kind of change it is, with an icon. fix(api): the board forgets the note becomes a red icon, a muted api, and the words that matter. A title the board does not recognise keeps every word it has.
• Copy a branch name from any pull request card, through the card menu, including one nested inside its issue.
• Copy your own lines from a card. Write a line once in Settings, for example /implement-issue #{N}, and it becomes a row in every card's menu that copies it with that card's own number in it. {URL}, {TITLE}, {REPO} and {BRANCH} work the same way. A line that asks for a branch is not offered on an issue, because an issue has none. Give each line an icon in Settings: pick one from the list, or type one emoji.
• A card menu you can read by its icons. Every row leads with one: a note, a branch, a column, a flame for high priority, a level line for normal and an arrow for "not a priority".
• A card you moved by hand wears a blue dot on its menu button, which then stays in view. Rest on the dot to see where you put the card and where the rules would put it, so a move that went stale does not hide.
• Point at anything that names other work and that card lights up. A child's pill, a child in the list, "Blocked by", "Sub-issue of": the card it means is washed violet wherever it sits on the board, so you find it with a glance instead of reading numbers. Nothing lights when that work is not on your board, and the tooltip still says what it is.
• Point at a stacked pull request and the rest of its stack lights up, wherever those cards are on the screen, including in another column. The keyboard does it too. Hovering the stack's number tells you which pull request that number is, by title.
• The review row sorts by the same rules as the columns. Under the smart order it reads a stack in merge order, so the one to review first comes first. A pull request you reviewed before (an approval, a change request or a plain comment) comes before one you have not opened yet, so you finish the reviews you started before you begin new ones. A stack moves up together. It lifts anything you marked "high priority" and pushes down anything you marked "not a priority". Every other order gives the row a plain date order, like the columns.
• A stacked pull request says so, in the columns and on the review row alike: Stack #5073 · 2 of 3 names the stack by the pull request that merges first and says where this one sits. Reviewing or merging a stack out of order is wasted work twice over. Each list counts itself, so a badge is always the truth about the list you are reading.
• What is waiting on you, above everything else. A row of the pull requests where somebody asked for your review, longest-waiting first, because those cost other people time rather than yours.
• What you finished today, in the last column: everything of yours that merged or closed since midnight, newest first. A pull request closed without merging never appears, because it did not ship.
• That column can be asked about other days. Press the calendar in its heading and choose Today, Yesterday, the last 7 days, or any two dates. The heading says which days it is showing, and the days are in the link, so "what we finished yesterday" is one paste into the standup chat. It opens on today again next time.
• A board that keeps itself up to date. Six columns, from To do to Done today, and a card moves itself when a pull request appears, when a reviewer is asked, when they answer, and when it merges. The button on a card opens a menu that moves it by hand when GitHub's answer is not the truth, and hands it back to the rules with one click.
• One column for everything waiting on you. "Needs attention" holds the work you cannot hand on: the branch conflicts, a reviewer asked for changes and is still waiting, or a check came back red with nobody else to wait for. Each card says which of the three it is, with a pill you can hover for what to do about it. A card with all three says all three.
• A red check does not pull a card out of "Awaiting review". Somebody is reading it, and that is the longer wait, so the column keeps saying so. In the smart order the card climbs to the top of its column instead, and its "Checks failed" pill says why.
• A dot beside the PR badge says how the checks on a pull request are going. Green when every run passed, red when one came back red, grey while they are still running. Rest on it for the breakdown: how many passed, failed, or are still running. A commit nothing has run on draws no dot at all. It reads GitHub Actions runs, which is the only way a fine-grained token can see checks, so a repository whose CI lives somewhere else shows no dot.
• An issue draws its children as a row of pills. A card with sub-issues shows one small pill per child under "Children", each painted with the colour of the column that child sits in, and the count of how many are closed beside them. Hover a pill to see which issue it is and where it sits, or press it to open it. One press below, the whole list unfolds, each child with its column: "Ongoing", "Awaiting review", "Done". A column you chose by hand wins there too, so neither the pills nor the list can disagree with the child's own card. A sub-issue on the board says "Sub-issue of", with the issue it belongs to.
• The children that want you come first. The five nearest to needing a person are on the card: changes asked for, then approved, then out for review, then being written, then not started, with finished work last. "Show all" opens the rest, and it stays open while you work.
• The real links between your work. A pull request appears inside the card of the issue it closes, an issue says what it is part of, and anything waiting on unfinished work is marked Blocked. All of it read from GitHub's own relationships, never guessed from a description.
• See who each piece of work is with, and narrow to one person by tapping their face. A pull request waiting for your review shows whose work it is, so you can see who is asking you. Every card on your own board shows everybody in the review instead, so you can see who you are waiting for, with a ring saying what each one is doing: asked for changes, has not reviewed yet, or approved. An issue shows the review of the pull request that would close it, because that is where the answer is. That is two separate filters, one for each list, and a link carries both.
• Find one issue or pull request by its number. Type 312 (or #312, or paste its GitHub link) in the box at the top, or press / to reach it. Every other card goes, and the one left sits in the column it is in, so you see its state at a glance. Words find titles too. The filters step aside while you search, and Escape brings the whole board back.
• Filter by kind, repository, label, milestone or issue field. Two labels means either of them; a kind plus a repository means both. The filters go into the address bar too, so "everything tagged urgent in this repository" is a link. A button folds the filters down to the chips you chose, so a long list of chips does not push the columns down. The board starts folded, and this browser remembers your choice.
• See the milestone on each card. A pill after the labels names the milestone and shows how much of it is closed. Press the icon or the number to open the milestone on GitHub; press the name to show only that milestone's work.
• See the issue fields on each card. The fields your organisation set on an issue, such as the effort or the priority, show as small pills under the labels. Press a number or an option to show only the work with that value. They come with the issues the board already reads, so they cost no extra call and no extra permission. Pull requests have no issue fields.
• Choose what each card shows. In Settings, under "How the board looks", switch the labels, the milestone, the fields, the people, the parent and blockers, or the sub-issues off. The choice is saved with your half of the board, so it follows you to every machine.
• A smart order, which is what the board opens on. Oldest first, so the work that has waited longest is at the top, with one rule over it: a stack of pull requests reads in the order it can merge. A stacked pull request targets another one's branch, so the lower one has to merge first, and it is usually the one that looks least recently touched. Inside each column, a card marked Blocked goes below the work you can start now, and anything stacked on it goes along.
• Or sort it plainly: recently updated, least recently updated, newest, oldest, ones you noted first, by label, by repository, or by title. The choice goes into the address bar, so a reload keeps it and a link carries it.
• Push work you do not care about this week to the bottom. Mark any card "not a priority" from its own menu. It goes faint wherever it appears, in every order, and wears an arrow to the bottom line in its top corner. In the smart order it sinks to the bottom of its list. A pull request stacked on top of a card you pushed down goes with it, because it cannot merge until that one does. The mark is saved in your own repository, so it follows you between machines.
• Lift the work that matters this week to the top. Mark any card "high priority" from the same menu. It gets an orange border and a flame in its top corner, in every order, and in the smart order it climbs to the top of its list. The raised cards keep the smart order among themselves, and a raised pull request brings the rest of its stack up with it, still in merge order.
• The browser tab counts what is waiting on you. It reads "Work Board (4)", so you can see from another tab whether it is worth going back. In Settings you choose which parts of the board add up to that number, and whether each part counts the work you marked "not a priority". The same number sits beside the board's name, and resting on it breaks the total down by part. A count that leaves work out says so when you rest on its badge.
• Ask GitHub now, with the button beside the schedule. Rest on it and it tells you when the board last heard anything, so you can tell a quiet morning from a board that stopped asking. It goes down until the answer is in, and for at least a second, so one press is one read.
• It asks GitHub again by itself. Every minute, and you can set that to 30 seconds, five minutes, or off. It never wipes the board to placeholders, never asks while the tab is out of sight, and never interrupts a note you are typing. A hidden tab costs you nothing at all. The choice stays in this browser: it is about what this one device spends, so it is not saved to your repository.
• Paint the columns, hide the ones you do not need, and choose light or dark. A colour on each column and on the review row, from a set of presets, a switch to show or hide each one, and a theme that follows your machine unless you say otherwise. All of these are saved in your own repository, so the board looks the same on every machine you open it on.
• A private note on anything on the board, including a pull request waiting for your review and one nested inside its issue.
• A private note on any issue, added from the card's own menu and shown only where one exists. Notes are yours alone: they never appear on GitHub's issue page, and nobody else sees them. To delete a note, empty its box and click away: the box folds shut, and the status line names the card.
• A suggested cleanup for notes on finished work. A note stays in your repository after its issue closes or its pull request merges. Settings -> Review suggested cleanup lists those notes. Delete each one, delete them all at once, or keep one so the board stops suggesting it on every device.
• Settings says whether your board is getting through. The cloud storage panel shows Saving or Not saving, and when it is not, it says what to fix. It answers when you open Settings and again after Save and reconnect.
• Your board saves itself. It lives in a JSON file in a private repository you own, so the laptop and the phone show the same thing, and every change keeps a version in git history.
• Two devices can edit at once. The merge runs record by record, so nothing you wrote is overwritten by the other device.
• Plain error messages. When a call fails, the page names the permission to add instead of showing GitHub's own wording.
• A settings screen in five sections: GitHub tokens, cloud storage, how the board looks, what the tab counts, and the lines you copy from a card. An index beside them moves between sections, and each section has its own link. A search box finds any setting by the word you think of ("dark", "hide", "backup") and takes you to it.
• Your tokens back out again. GitHub shows a token once and never again, so this browser holds the only copy. Settings can copy any token, show it, or copy every one of them as a single backup you keep in your password manager.

Your notes, the cards you moved by hand and how the board looks are saved in this browser. To keep them across devices, open Settings and set up Cloud storage: one private GitHub repository you own, shared by every project on this site. Press Use for cloud storage beside a token, or paste one there. If you set the board up before cloud storage existed, the board hands your old repository and token over on its own, and reads your old board.json once.

Settings -> Add token opens a screen that walks through it in four steps, with the same guide as below. You can give the token a name there; leave it empty and the board suggests one from wherever the token finds work.

1. Create a fine-grained personal access token at github.com/settings/personal-access-tokens/new. The form asks you for each of these:

   • Repository access: choose Only select repositories, then select every repository whose issues you want on the board.
   • Repository permissions: set each of these and leave the rest alone.
     • Metadata → Read-only
     • Issues → Read-only
     • Pull requests → Read-only
     • Actions → Read-only
   • Expiration: pick a date. 90 days is a good default.

2. Paste the token into the page and press Connect. The page checks each permission and tells you exactly which one is missing if any call fails.

3. Work in an organisation? Add a second token through Settings -> Add token (see above). A fine-grained token belongs to one owner. A token owned by your account cannot see an organisation's repositories, whatever permissions you give it. Create another token with the organisation as the Resource owner, grant it the same permissions, and paste it there. An organisation owner may have to approve the token first. Until then the token finds nothing, and the board says so above the board, with a link to the page where the organisation's owners approve it.

   Keep cloud storage on your personal token, in Settings, never on the organisation's. An organisation's owners can read its repositories, and this half of the board is meant for you alone.

If the board later needs access your token does not have, the page says so on load and names what to add. The permission list lives in the code, so the page and this README cannot fall behind it.

The token is kept in this browser and is sent only to GitHub. Anything else with access to this browser can read it, so keep the repository list short and keep the expiry date. Remove, on the token's row in Settings, removes it; removing your last token signs you out.

A different browser, a different computer and a different Chrome profile each keep their own storage, so none of them can see the tokens you added in the others. GitHub cannot show you a token a second time either.

1. In Settings, press Copy every token as a backup. Read the warning once and continue. You now hold one piece of text with every token and the name you gave it.
2. Keep that text in your password manager. It is a password: whoever holds it can do everything you granted those tokens.
3. On the other browser, paste it into the token box, on the welcome screen or on the add-token screen (Settings -> Add token). Every token comes back, with its name, and the board connects.

To move a single token instead, press Copy on its row. The token is never printed on screen: it appears in the row only if your browser refuses the clipboard, which happens when you open index.html as a file instead of serving it. Even then it is forgotten as soon as you leave Settings.

Open index.html in a browser, or serve the folder with any HTTP server:

python -m http.server 8000

bun test