perq is my attempt to stop doing that. It’s a terminal dashboard for the PRs you care about, built with Textual, with Claude Code folded in to do the reading-and-thinking parts - summarise a PR, review it, answer a question, or work out why a check is failing - streamed straight into the TUI.
uv run perq
You open perq and you see three lists: the PRs you’ve opened, the ones waiting on your review, and the ones you’re otherwise tangled up in (assigned, mentioned, commented on). Each row tells you what you actually want to know at a glance - CI state, review decision, the diff size, how many comments, when it last moved.
Arrow-key to a PR, hit enter, and you’re in the detail view: five tabs for the overview, the conversation, code-review threads, individual CI checks, and the full diff. No page loads, no spinner, no thirty open browser tabs.
The dashboard refreshes itself every sixty seconds - silently, keeping your cursor exactly where it was - and tells you when something meaningful changes. Your CI just went green. Someone approved you. A new review got requested. You don’t go looking for those; they come to you.
Because the terminal is already where I am, and a PR dashboard that lives in a browser tab has the same problem a cheat sheet in a browser tab has - the moment you have to leave what you’re doing to go look at it, you’ve paid the cost the tool was supposed to save you.
A TUI is always one keystroke away, renders instantly, and works the same over SSH on a bad train connection as it does at my desk. It doesn’t fight for focus and it doesn’t ask me to find the right tab. It’s just there when I press the key, and gone when I’m done.
The part I use most isn’t the dashboard - it’s the four things Claude Code can do once you’re looking at a PR:
s summarise - what this PR does, the key changes grouped by area, how risky it is, and anything worth asking the author.R review - an advisory code review with a verdict, findings tied to file:line with severities, and design and security notes.? ask - type any question about the PR and get an answer grounded in the diff and the conversation.d diagnose - on a failed GitHub Actions check, perq pulls the job logs and Claude tells you what failed, the root cause, a suggested fix, and whether it smells flaky or real.All of this streams into a modal as it’s generated, so you’re reading the first sentence while the rest is still arriving. Crucially, it’s local and advisory - none of it is ever posted to GitHub. It’s the equivalent of a colleague leaning over and saying “this looks fine, but check the migration” - a private read, not a public comment. Press c to copy the output, escape to dismiss it.
When you do want to act, perq can write to GitHub too - a to approve, x to request changes, c to leave a comment, C to close. The line between “Claude helps me think” and “I act on GitHub” is deliberate and never blurry.
The whole thing hangs off a single GraphQL query. One round-trip to GitHub fills all three dashboard sections, and the detail view is a second query plus the raw diff. perq authenticates by shelling out to gh auth token, so if you’ve run gh auth login it just works (it falls back to $GITHUB_TOKEN).
The notifications are the bit I’m quietly pleased with. Every refresh is diffed against the previous snapshot, and only transitions raise a toast - CI failing or recovering, a review decision changing, comment counts going up, a new review request appearing. Absolute states never fire, so startup is silent and a PR simply showing up on your dashboard doesn’t nag you. If more than five things changed at once, they collapse into a single “dashboard updated” line instead of a wall of toasts. On macOS, when the terminal isn’t focused, the same events become desktop banners via osascript.
The Claude integration is a thin wrapper around the CLI. perq spawns claude -p --output-format stream-json --max-turns 1, feeds it a self-contained prompt, and parses the streaming JSON for text deltas as they come. The prompts ship everything Claude needs inline - the PR metadata, description, conversation, review threads, and the diff (truncated if it’s enormous) - and explicitly tell it not to use any tools. For diagnosis, perq fetches the Actions job logs, strips GitHub’s per-line ISO timestamps, and tails them to fit. It’s one turn, no agent loop, no tool calls: a fast, bounded, read-only ask. The streaming subprocess runs in its own process group so a cancel actually kills it and its children.
There’s a command palette too (ctrl+p): paste any GitHub PR URL or type a owner/repo#123 shorthand to jump to a PR that isn’t even on your dashboard, or fuzzy-search the ones that are.
It’s about 1,800 lines of Python - Textual for the UI, httpx for GitHub, and the gh and claude CLIs for auth and intelligence. Python 3.12+, managed with uv.
perq isn’t trying to be the GitHub web UI in a terminal. There’s no merging, no branch management, no project boards, no notifications inbox. It’s the narrow slice of the PR experience I touch dozens of times a day - what’s waiting on me, what changed, and what does this diff actually do - made fast and keyboard-native, with an LLM doing the tedious reading.
If you want the full surface area of GitHub, it’s a browser tab away. If you want your pull requests to stop pulling you out of the terminal, this is for you.
It’s on github.com/tuckerwales/perq. You’ll need Python 3.12+, uv, the gh CLI logged in, and the claude CLI on your PATH for the summaries and reviews.
uv run perq
Then press s on your gnarliest open PR and see what Claude makes of it.
Engine is the platform that powers Starling Bank, now offered to other banks building on top of it. After five years on banking infrastructure at Monzo, it’s a natural next step - and a chance to work on the platform side of banking from a different angle.
More to share once I’ve found my feet.
]]>
I joined as a Backend Engineer in July 2021 and have spent the last (almost) five years in the Platform Collective - the team that builds the things the rest of the bank is built on. It has been, by some distance, the best job I’ve had.
Most of that time was on the bank’s data infrastructure: the platforms and pipelines that move data between our services, AWS, and GCP, and the libraries and tooling that sit on top of them - data access, metadata, annotations, retention, right-to-erasure, the graph database that ties it all together. I picked up a healthy amount of incident response along the way too, which is its own kind of education.
I’m not going to try to summarise five years in a blog post. The short version: I got to work on systems that millions of people use every day, alongside some of the sharpest engineers I’ve ever met, in a place that took both the engineering and the customers seriously. That combination is rarer than it should be.
To everyone I worked with - thank you. You made it.
I’ll have more to share soon, but I’m very excited about the future.
]]>git every working day for the better part of a decade and I still cannot reliably remember the incantation for “undo the last commit but keep my changes staged.” I have a tab open in my browser for it. I have it written on a sticky note that has fallen behind my desk. I have, on more than one occasion, just guessed.
The honest answer is that I don’t need to memorise it. I need it on screen in under a second, the moment I think the question. That is what Cheetos is for.
It’s a small macOS menu bar app that holds your cheat sheets - vim, tmux, git, docker, kubectl, ssh, curl, find/grep, bash, brew out of the box - and surfaces them with a global hotkey from anywhere. Click a command, it’s on your clipboard. Hit esc, the window’s gone.
Press your hotkey (or click the menu bar icon). A floating panel appears with a search box. Type a few characters - commit amend, tmux split, kubectl logs - and the matches highlight across every sheet. The top match shows up in a banner; press ↩ and the command is copied and the panel disappears. Total interaction time: about a second.
If you’d rather browse, the sidebar lists every sheet. Pick one, scroll, click any backticked command to copy it. ⌘1–⌘9 jumps you between sheets. ⌘F focuses the search box. ⌘, opens settings inline.
That’s the whole app.
A cheat sheet that lives in a browser tab is not a cheat sheet, it’s a search result. The whole value is being one keystroke away while you’re already in the terminal thinking the question. The moment you have to alt-tab to a browser, find the right tab, and cmd-F for “amend,” you’ve lost.
Menu bar apps are the right shape for this. They’re always running, always one shortcut away, and they get out of the way the instant you stop looking at them. The window is an NSPanel - floating, non-activating - so it appears over whatever you’re doing without stealing focus, and hides as soon as you click elsewhere.
The dock icon is suppressed (LSUIElement = true), so Cheetos doesn’t clutter your ⌘-tab switcher. It’s there, and then it isn’t.
The bundled sheets are a starting point. Everyone’s muscle memory is different - your tmux is not my tmux, and neither of us cares about half the flags the other one has memorised.
Drop any .md file into ~/.cheetos/ and it shows up in the sidebar. The filename becomes the id, the title is derived from it (docker-compose.md → “Docker Compose”). Edit the file, save it, and Cheetos picks up the change immediately - it watches the directory with DispatchSource and rebuilds the library when anything inside changes. No reload, no settings panel, no restart.
You can also hide bundled sheets you don’t use. Right-click in the sidebar, click the eye-slash, done. The sheet stops appearing in search, the sidebar, and the quick-action banner until you bring it back.
The sidebar reorders itself by usage too. Sheets you reach for often float to the top; the ones you forgot you had drift down. It’s the kind of small thing you stop noticing, which is the point.
Cheetos renders a deliberately tiny subset of markdown - the parts that matter for cheat sheets:
#, ##, ### headings to structure a sheet- bullets, where lines like - `cmd` — description render as a copyable command pill next to the description`inline code` becomes a clickable pill> block quotes for the occasional warningThat’s it. There’s no images, no tables, no link rendering, no theme switcher. It’s the smallest markdown that does the job, which keeps the renderer a few hundred lines of SwiftUI rather than a dependency.
If you want richer notes, you have a text editor. Cheetos is for the surface area you reach for in the middle of typing a command.
A lot of the work in something like this isn’t the obvious stuff - the menu bar plumbing, the markdown parser, the search. It’s the small interactions that decide whether you actually use it.
The quick-action banner is one of those. When you type a search, the top match doesn’t just highlight, it gets pulled out into a banner at the top of the panel that says “press ↩ to copy git commit --amend.” If you don’t even bother reading the rest of the results, the right answer is one keystroke away. Most of the time it is exactly what you wanted.
The global hotkey is another. It uses Carbon’s RegisterEventHotKey because that’s still the right way to register a system-wide shortcut on macOS, even in 2026. The toggle behaviour - hotkey opens it, hotkey closes it, esc closes it, click-away closes it - turns out to require thinking about every combination of “is the panel open, is it focused, is something else active” that you might be in.
And the bit where clicking on a backticked command in the rendered markdown copies it. That’s a Button inside an AttributedString inside a Text, and getting it to look like a pill in the body of a paragraph - without the layout breaking, without focus rings appearing in odd places, without dragging on the cursor change - is the kind of thing that takes an evening for one feature.
None of these are exciting in isolation. Together they’re the difference between an app you open twice and one you open every day.
Cheetos is not a documentation browser. It’s not a snippet manager. It’s not trying to replace man or tldr or your notes app. It is one screen with one job: hand you a short command you almost remember, fast.
If you want a syncing, tagging, multi-device, AI-summarised knowledge base, this isn’t that. If you want your cheat sheets one keystroke away on your own machine, in plain markdown files you control, with no accounts and no telemetry, this is for you.
Grab the latest build from github.com/tuckerwales/cheetos/releases, or check out the source - ./build-app.sh produces a Cheetos.app. macOS 14+.
Drop your own sheets into ~/.cheetos/. Pick a hotkey. Stop guessing at git reset flags.
So I built TorDrop. It’s a small native macOS app that turns any file on your disk into a .onion URL you can hand to someone. They open it in Tor Browser and download. You click Stop Sharing. The onion service, and its private key, cease to exist.
No accounts. No servers I run. No persistent keys anywhere.
Open TorDrop, drop one or more files into the window (or use the file picker), and you get a .onion URL and a QR code. Send the URL to whoever needs the files, over whatever secure channel you already use to talk to them. They open it in Tor Browser and download. When you’re done, you click Stop Sharing and the onion service vanishes.
That’s the whole app.
It’s deliberately minimal. There’s no sign-in, no “my files” list, no history. Nothing is ever uploaded anywhere - the file stays on your disk the entire time, served directly from your machine through Tor.
While a share is starting or live, TorDrop also drops a small status icon into the menu bar. Click it to bring the window back, or drop a file straight onto it to start another share. When nothing is being shared, the menu bar icon disappears.
File → local HTTP server (127.0.0.1:random) → tor → v3 onion service → Recipient
When you share a file, TorDrop starts a tiny HTTP server bound to a random loopback port on your machine. It then spawns tor, connects to its control port, and asks it to create an ephemeral v3 hidden service that forwards onion port 80 to the local HTTP port.
The magic bit is the ADD_ONION NEW:ED25519-V3 Flags=DiscardPK command. That tells tor to generate a fresh onion service keypair and not hand us the private key. The service exists only inside that running tor process. When you stop sharing, the process forgets it, and the .onion address is gone forever. There is nothing on disk to leak, back up, or forget to wipe.
I wanted sharing a file to feel like AirDrop, not like opening a webapp. A regular Mac app you can drag files into, that doesn’t need a browser tab of its own, and that gets out of the way when you’re not using it.
The whole thing is a SwiftUI window backed by an NSWindowController, with an NSStatusItem that only appears while a share is active - so you can dismiss the window and still see at a glance that something is being shared, and drop more files on it if you want.
TorDrop has exactly one external dependency: the tor daemon itself. Everything else - the HTTP server, the Tor control-protocol client, the QR code renderer - is first-party code built on the macOS system frameworks.
This wasn’t philosophical purity. It’s that for something whose whole value proposition is “this is doing what it says on the tin,” auditability matters. A dependency tree a mile long undermines the pitch. If you can read the source in an afternoon, you can actually trust it.
So I wrote the HTTP server. It’s a small Network.framework listener that speaks just enough HTTP/1.1 to serve a directory listing and range-request downloads. I wrote the Tor control-protocol client too - it’s a line-oriented text protocol that’s genuinely pleasant to implement. Between the two, it’s a few hundred lines of Swift. Small enough to reason about, big enough that it definitely works.
There’s something grounding about writing the primitives yourself once in a while. You remember that HTTP is not magic, that a file server is just sockets and strings, that the stack you depend on every day is made of things a person wrote.
TorDrop doesn’t try to add anything on top of what Tor itself provides. What it does try to do is not weaken it:
DiscardPK means the private key never touches disk, never touches Swift memory that might be swapped, and cannot be recovered after the process exits./<20 random chars>/... path, so leaking the onion address alone doesn’t immediately hand over the files. It’s defense in depth, not a secret - you should still treat the full URL as sensitive.127.0.0.1. It is not reachable on your LAN, let alone the open internet. The only way in is through the onion service.The usual Tor caveats still apply. If you need to be certain the URL reached the right person, confirm it through a channel you already trust.
TorDrop is for one-off, person-to-person file handoffs where you care about not routing the file through somebody else’s infrastructure. Sending a keyfile to a colleague. Sharing a video with a family member abroad. Getting a big artifact off your machine and onto theirs without it being cached, indexed, or scanned along the way.
It is not a backup tool, not a sync client, not a hosting service. Your machine has to be on for the transfer to work. The moment you stop sharing or quit the app, it’s over.
github.com/tuckerwales/tordrop - source, build instructions, and a Makefile that produces a .app. You’ll need brew install tor and macOS 13 or later.
If you try it, I’d love to hear how it went.
]]>It’s a short browser game. You’re an astronaut who’s made a bad landing on an uncharted moon. Your communicator is in pieces, scattered across a tiny procedural world, and you need to repair it and call for rescue.
No install, no sign-up. Open the page, hit start, play.
You wake up next to a crashed landing pod. The planet is small - genuinely small, you can walk around it in a minute or two - so there’s no map, no fast travel, nothing to get lost in. You just explore.
As you wander, you find things: an ancient altar with empty sockets that want to be filled, a still pond with something glinting under the surface, a cave mouth you can’t walk into without waking whatever’s sleeping in there. Each of these is hiding a piece of your broken communicator. Put the pieces back together and you can signal the rescue shuttle.
That’s the whole game. It takes about fifteen minutes to finish.
The “tiny” isn’t just aesthetic - it’s a design constraint that made the whole project tractable. A small world means a small scope. I didn’t need quest systems, map UI, save files, or a HUD full of icons. The player can see most of the world from anywhere on the surface, so I could lean on sightlines for storytelling rather than markers or objective text.
It also meant I could afford to be generous with detail: bioluminescent plants, drifting fireflies, footprints that fade behind you, a rescue ship with a working tractor beam. The budget I’d have spent on a large world went into small-world atmosphere instead.
It’s pure Three.js on top of Vite, no game engine. The planet is a subdivided icosahedron with a noise function driving surface height. Props are placed by raycasting onto the mesh, so trees and rocks sit properly on the curvature. Collision is a cylindrical collider registry that ejects the player horizontally when they walk into something - simple but enough for a game where you don’t jump on things.
Systems communicate through a tiny pub-sub I wrote in about twenty lines. When you pick something up, a pickup.collected event fires, the inventory reacts, the story system reacts, and whatever spawned the pickup cleans itself up. Nothing knows about anything else it doesn’t need to. That decoupling was the single most useful decision in the codebase - it meant each puzzle could be written as a self-contained module that subscribed to a handful of events.
The atmosphere is a Fresnel shader on a slightly-larger sphere around the planet. The fog blends the horizon into space. The starfield is a single Points mesh with a custom shader for twinkle. Everything renders in one scene.
W / S run forward / backward
A / D turn left / right
Shift walk (hold while moving)
Space jump
E interact / pick up
F throw held item
I toggle inventory
Scroll zoom camera
No mouse required. This was deliberate - I wanted it to feel like an arcade game you could play on a laptop trackpad on a train.
The thing I didn’t expect when I started this was how much fun I had.
When you write software for a living, it’s easy to forget that the activity itself is enjoyable. Most of the day-to-day is shaped by things that aren’t the code: deadlines, stakeholders, reviewers, the weight of a system that thousands of people depend on. You start to measure your work by whether it shipped, not by whether you liked making it. I think that’s a fair trade for the work I do - the stakes are part of why it matters - but it means the pleasure of just building a thing gets a bit squeezed out.
Tiny Planet had none of that. Nobody was waiting for it. There was no ticket, no standup, no design review, no postmortem hanging over a decision. If I wanted the fireflies to glow a different colour, I just did it. If I wanted to spend an evening making footprints fade behind the player, that was allowed. I’d forgotten how good that feels.
So this is partly a release post and partly a nudge - if you write software for work, and you haven’t built anything silly lately, go build something silly. Not a side project with a business plan. Not a startup idea. Just a thing. You might enjoy yourself more than you remember.
tinyplanet.tucker.wales - runs in any modern browser, keyboard only, no install. It takes about fifteen minutes. Headphones recommended.
If you finish it, I’d love to hear what you thought.
]]>That’s why I built Terraviz: https://terraviz.dev/.
Terraviz is a browser-based tool that takes your Terraform files and turns them into an interactive infrastructure diagram. Drop in your .tf files, and within seconds you get a visual map of your entire infrastructure - resources, dependencies, and all.
No sign-up. No backend. Your files never leave your browser.
If you’ve worked on any non-trivial Terraform project, you’ve probably experienced this: you open up a directory with dozens of .tf files, and you need to understand what’s going on. Maybe you’re onboarding onto a new team. Maybe you’re reviewing a PR that touches networking and compute. Maybe you’re trying to figure out why deleting one resource is going to cascade into something unexpected.
You can read the code line by line, grep for references, or try to hold the dependency graph in your head. But at a certain scale, that just doesn’t work.
I wanted something where I could just see it.
You give it your .tf files (drag and drop a folder, or browse for individual files), and it produces an interactive diagram.
Resources are rendered as color-coded nodes organized by category - compute, network, storage, database, security, DNS, CDN, monitoring, and more. Dependencies are auto-detected by parsing HCL reference expressions, so if your EC2 instance references a security group, that connection shows up as an edge in the graph.
Click any node and its direct dependencies light up while everything else dims. Click an edge to highlight the connection and both endpoints. Expand a node to inspect the raw HCL body. Drag, pan, and zoom to explore large infrastructures.
One of the features I’m most pleased with is smart containment. VPCs and subnets are rendered as visual containers, and resources are automatically placed inside their parent network based on attribute references - vpc_id, subnet_id, vpc_security_group_ids, and so on.
It even handles transitive relationships. If a resource doesn’t directly reference a VPC but references something that’s already inside one, Terraviz figures that out and places it in the right container. This makes it much easier to see the network topology of your infrastructure at a glance.
Not every diagram needs to show everything. Terraviz lets you toggle resource categories on and off to focus on specific layers - just networking, just compute, just security. The diagram re-layouts automatically when you hide or show categories.
There’s a search bar (Cmd+F / Ctrl+F) that lets you find any resource and zoom straight to it. Useful when you’re looking at a large project and need to locate something specific.
When you need to share what you’re looking at, you can export the diagram as a high-resolution PNG or SVG - great for documentation, architecture reviews, or presentations.
The parser works with any Terraform provider, but category detection and containment grouping have enhanced support for AWS, GCP, and Azure. This means VPCs, virtual networks, subnetworks, and their child resources are all grouped correctly regardless of which cloud you’re working with.
Resources from other providers still show up - they’re categorized using general pattern matching and displayed without containment grouping.
This was a non-negotiable for me. Terraform files often contain sensitive information - resource names that reveal internal architecture, variable defaults, provider configurations. Terraviz runs entirely in your browser. Your .tf files are parsed client-side, never uploaded anywhere, and never stored. There is no backend.
Because of course there is. Both themes have distinct color palettes for each resource category, and your preference is persisted across sessions.
If you work with Terraform, give Terraviz a try. I’d love to hear what you think - there’s a feedback button right in the app.
Whether you’re onboarding, reviewing, debugging, or just trying to get a clearer picture of your infrastructure, I hope it saves you some time.
]]>