The One Tool That Changed How I Work More Than Anything in 20 Years

I built something, and it has changed how I work more than any tool I've adopted in twenty years. I want to describe how it works, because the pattern is reproducible and I think more small teams should steal it. I also explain what I got wrong about my first model of AI tool development, and lay-out the most underrated part of my solution.

The problem

For years the way my small team kept up was the usual magic: talented engineers, short lines of communication, and me writing a lot of specs.

I've hand-written thousands of specs over the years: feature requests, bug reports, data model sketches, "I thought you might enjoy experimenting with this" notes to engineers. And every single one of them started from a blank page, drew on context that lived only in my head, and disappeared into a project management tool the moment it shipped.

That's fine when you're maintaining one product, or one idea at a time. But I'm juggling a dozen workstreams across our entire organization, and we're revamping everything this year. I needed a way to keep it all straight.

The core idea: files are the shared state

The setup has two parts: I built a web app and the command-line brains behind it. The web app is always running on my computer, a pinned tab in Dia that's always a glance away. It's a lovely presentation of everything we're working on: context, decisions, milestones, and designs in one place.

The brains are a clever network of agent skills that guide me through each step of my thinking: from product vision to research to features, decisions, and ultimately design. The best part? Everything we create lives in a folder of human-readable flat files backed by a git repo. Markdown, JSON, and images. No lock-in, no model-specific or agent-specific behavior.

Here's how it works:

1. Claude Code writes files. Custom slash commands (/shape-feature, /design-screen, /record-decision, and a couple dozen more) are the only way anything gets written. Each command is a carefully authored prompt that knows exactly what questions to ask, what files to read first, and what format to write.
2. A local React app reads those files. Vite watches the disk and renders everything (specs, data models, decisions, screen designs) as a browsable product workspace in the browser. The UI is read-only on purpose. All writes go through conversation.
3. The files on disk are the bridge. No database, no API, no server. Version-controlled, greppable, portable. The formats are strict enough that the UI can parse them, which means they're also strict enough that an AI agent six months from now can parse them too.

I work in two windows: a terminal where I talk to Claude, and a browser where I watch the artifacts take shape. It feels less like using a tool and more like having a product organization that happens to fit on my laptop.

Institutional memory is the actual product

Here's the thing I got wrong in my first mental model of AI tools: I thought the main value was the speed of creation. It isn't. The value is persistent context. It's reproducing my brain in a system that doesn't forget, doesn't make shit up, and keeps it all together so I don't have to.

Every project in the system is a workspace where the important stuff accumulates: the product vision, a conceptual data model, a glossary of domain terms, constraints, and (my favorite) a running log of decision records with the alternatives we considered and why we chose what we chose. When I sit down to shape a new feature, the agent loads all of it before we exchange a word. It knows our vocabulary. It knows we decided against that approach eight months ago, and why. Oh, and of course it has full access to the actual source code of a project, so we're shaping ideas against the reality of our setup, not some idealistic state that doesn't exist yet.

A small team's biggest tax is re-explaining context. We mostly don't pay it anymore.

It writes specs the way I would

Early on, the AI-generated specs had a problem: they read like they were written by a product manager from a much larger, much more boring company. "The system shall..." language. Acceptance criteria in Given/When/Then. My engineers would have staged an intervention. I hated that nonsense.

So I fed the system an analysis of years of my own hand-written specs and distilled a voice guide from them. How I lead with the story of why before the what, how I frame schema ideas as suggestions ("whatever you think is best here"), how I end big specs with a practical testing checklist rather than an exhaustive test plan. Every prose-producing command reads that guide first.

The result is that specs come out sounding like me, because in a real sense they are me, at scale. My engineers read them the same way they read the ones I wrote by hand. That was the moment this went from a toy to infrastructure.

Design systems and screens, before an engineer touches anything

Each project gets its own design system: color tokens, typography, spacing, shared component treatments. The agent helps shape it conversationally, then every screen it designs afterward is bound to those tokens. Real React components, responsive, dark-mode aware, rendered live in the companion app and screenshot via Playwright.

The components follow one strict rule: props in, callbacks out. No data fetching, no routing, no state management. Which means they're portable. When a feature is approved, the actual components ship to engineering along with the spec, sample data, and TypeScript interfaces. Design review happens on working screens, not mockups. We can go from "rough idea" to "clickable, on-brand screens with a spec my team can build from" in an afternoon.

The bridge to real code

The next piece is the handoff. When a feature is shaped and approved, another skill command assembles everything (the spec, the relevant slice of the data model, the decisions that constrain the work) into a build prompt and drops it directly into the target codebase. A fresh agent session in that repo picks it up and builds a thin, reviewable slice. One prompt, one scoped PR. Engineers review real diffs against a spec they trust.

And this is the part I want to be careful about, because "fully agentic" gets misread: the platform deliberately produces the what and the why, never the how. I'm not replacing my team here, not interested. I'm replacing the manual back and forth and imprecise nature of a typical project handoff. No prescribed architecture, no dictated libraries. Engineers own the implementation, same as always. The agents just remove (most of!) the ambiguity of my ideas on the way to implementation.

One rule I never bend: the agents aren't allowed to touch Git. No commits, no pushes, nothing. I read what they produce and commit it myself. The system drafts; I decide what sticks.

There is no lock-in, and that's by design

I can't state this plainly enough: everything I've described is plain text. Markdown, JSON, a handful of React components. Any agent, any program, any human can open these files and understand them completely.

I think this is the most underrated property of the whole system. I love Claude and it's what I reach for most right now. But nothing about the platform depends on that choice. The "API" between me and the AI is a folder of readable files, so I can point any model at it. In practice I sort by price: the heaviest model does the thinking and shaping, and cheaper ones handle the execution. I can throw a different model at a hard problem just to see what it does with the same context. I can run adversarial reviews, where one model shapes a spec and another one tries to poke holes in it, and the referee is just... the files. Whoever makes the best frontier model next year, this whole system comes with me.

And because it's just files, it's just Git. Branches, commits, pull requests, history. A spec under review is literally a branch. A decision is a commit you can trace back five years from now. Anyone on the team can clone it like any other project, and any tool that speaks Git can plug into it. There's no vendor to outgrow and no export button to pray over. You could run an entire product ecosystem off this platform, and it scales the way plain files have always scaled: effortlessly.

I shape product wherever I'm thinking

Because the whole system is files in a repo with a conversational front door, it doesn't care where I am either.

I keep a remote Claude Code instance connected to the platform, which means the terminal-and-browser setup on my desk is just one way in. Lately my favorite way in is my iPad. I can be on the couch, still chewing on an idea, and I can open a session, think out loud, preview the screens, pencil in notes, react to something the agent drafted yesterday. Feedback and context get captured wherever I am, whenever the thought shows up.

That sounds like a small convenience. It isn't. Product thinking doesn't happen on a schedule, and the old cost of an idea-while-walking was "hope I remember this at my desk." Now I'm shaping the product when I'm thinking about it, not just when I'm sitting in front of a keyboard. Some of our best recent features started as a twenty-minute walk and a conversation. I probably need to work on my boundaries, but I love this stuff and can't stop thinking about it.

It's not just a me thing

Earlier this week I walked another company's team through the whole system. No real prep, just a screenshare and a conversation. Their questions were the good kind, the ones that poke at the edges. What about security? The agents can't reach outside the filesystem they work in, and they only get the tools I've explicitly allowed. Could a whole team share one of these? That one has my favorite answer, because it's the same answer as everything else here: it's just a repo. Push it, pull it, and now the entire team is working from the same context, the same decisions, the same vocabulary. By the end of the call they were riffing on client workspaces and a shared skills library that captures their team's taste.

That's the part that has me excited lately. This started as a system built for exactly one brain, mine, and the pattern travels anyway. The files don't care whose judgment they encode.

If you're a technical leader at a small company, this pattern is sitting right there. Files as shared state. Conversation as the write path. Your own judgment, encoded once, applied everywhere.

Steal this if you like. If you build one, I'd love to compare notes. I might open source this, I might not. The code isn't particularly novel, but the thinking behind it is.