diff --git a/apps/web/src/content/pages/blog/four-iterations-of-an-incident-timeline.mdx b/apps/web/src/content/pages/blog/four-iterations-of-an-incident-timeline.mdx index ce3100904..c09f634d6 100644 --- a/apps/web/src/content/pages/blog/four-iterations-of-an-incident-timeline.mdx +++ b/apps/web/src/content/pages/blog/four-iterations-of-an-incident-timeline.mdx @@ -40,9 +40,9 @@ For deterministic tasks and fixes I use Claude Code remote. It spins up a VM and I write a lot of `PLAN.md` files and `/loop` over them once I'm *afk*. I keep several Claude Code tabs open, each grilling me on a different idea with Matt Pocock's grill-me skill. I rarely read those plans in full, except when it's a collaboration with Thibault on a bigger feature like incident response. We worked on that plan for a couple of days, with the idea spelled out for weeks before. Leave it, iterate the next day. -For dashboard work, Claude Code drives a browser against my local dev server and screenshots the page after every change. That's how it checks its own work. I do the same from my side: a screenshot, the broken part **boxed in red**, one sentence. While a loop runs I go bouldering or for a walk. When I'm back I test on localhost, not on a preview link, because the details only show up when you click through the real thing. +For dashboard work, the feedback is a screenshot from me: the broken part **boxed in red**, one sentence. While a loop runs I go bouldering or for a walk. When I'm back I click through the local dev server myself, because the details only show up when you use the real thing. Most loops run locally, and nothing gets pushed for a preview deployment until it feels right. When the work runs in a remote Claude Code session, I pull the branch and click through it locally before merging anything heavy on the dashboard. -For UI I use Claude Design for a first feeling. Without steering it looks very *claudy*, gradients and italics, so most of the time it's inspiration only. I usually ask for three or four variations. For dashboard work both tools have our design system. Claude Design gets it as a project asset, so the mocks come out in our tokens, fonts and spacing. Claude Code gets it from the repo: shadcn primitives in `@openstatus/ui`, our own blocks on top, and `AGENTS.md` files that say to compose from those and never fork a primitive into an app. Neither goes off the rails much, and both stay plain if I don't give enough detail. +For UI I use Claude Design for a first feeling. Without steering it looks very *claudy*, gradients and italics, so most of the time it's inspiration only. I usually ask for three or four variations. For dashboard work both tools know our design system, and both read it from the same place: the repo. In Claude Design I linked our GitHub repo, and it builds the design system from the code, so the mocks come out in our tokens, fonts and spacing. Claude Code works in the repo directly: shadcn primitives in `@openstatus/ui`, our own blocks on top, and `AGENTS.md` files that say to compose from those and never fork a primitive into an app. Neither goes off the rails much, and both stay plain if I don't give enough detail. ## Phase 1: from the plan @@ -121,6 +121,8 @@ Two things came out of this that aren't the timeline. A `DESIGN.md` at the repo root. `AGENTS.md` says where code lives, `DESIGN.md` says what *good* looks like: hierarchy over decoration, two row kinds on one rail, sentences instead of labels, composer first and newest first. Every rule in there is something I typed into a prompt during one of the phases, usually more than once. Now every session reads it before touching anything a user sees. -And the screenshot loop as a `screenshot` skill. Before, every session rebuilt it: borrow Playwright from somewhere, find the port, get past the login, set the theme. Now it runs on [agent-browser](https://github.com/vercel-labs/agent-browser) from Vercel instead of our own browser code, with a thin script for the parts that are ours: the seeded session, light and dark, the element instead of the viewport. Claude Code judges the PNGs against `DESIGN.md`, and for a dropdown or a dialog it drives agent-browser directly. +And the screenshot loop as a `screenshot` skill. Before, every session rebuilt it: borrow Playwright from somewhere, find the port, get past the login, set the theme. Now it runs on [agent-browser](https://github.com/vercel-labs/agent-browser) from Vercel instead of our own browser code, with a thin script for the parts that are ours: the seeded session, light and dark, mobile and desktop, the element instead of the viewport. Claude Code judges the PNGs against `DESIGN.md`, and for a dropdown or a dialog it drives agent-browser directly. The goal is fewer rounds where I'm the proxy. I still review on localhost, but the first pass should come back **already looked at**. + +Get inspired by the interfaces you use every day, make them your own, and inspire the next person. That's the circle of UI.