A plugin showed up in the share-and-create crowd that most people filed under "neat trick." You install a browser extension, open a page you want to restyle, drop in an AI key, then either point at elements directly or talk to the AI to change them. When you're happy, it spits out a decoration code you hand to someone else, and they import it to reproduce the exact look. The author even posted a V2EX restyle in a "new brutalist" theme as a long `PSAI1.` blob.
Most of the chatter was about the restyling itself. I kept staring at that blob instead. That string is the only part of the whole system that travels. The extension is the engine, sure, but the code is the thing people copy, paste, trade, and remember. And right now it has nowhere to live except a forum comment.
Where the value actually leaks
If you scan the rest of the share-and-create posts, the same pattern repeats. Someone ships a working tool, and the weakest half is almost never the core feature — it's distribution. A code buried in a thread has no version history, no preview, no way to tell last week's theme from today's. The next person who wants it has to scroll, guess, and hope the author didn't quietly change it.
That's the opening. You don't have to rebuild the extension to add real value. You rebuild the half it skipped: a place where each decoration code is a first-class record with a preview you can actually look at before you commit.
Draw the boundary first, because it's a hard one
Here's the part I want to be honest about, because it's easy to oversell. Applying one of these patches to a live third-party page — restyling v2ex.com in a visitor's own browser — still needs the extension's runtime. That injection happens inside the browser, against a page you don't control. Nothing on a hosting platform reaches into someone else's open tab and rewrites it. If a build claims to do that without the extension, it's lying.
So I'm not touching the injection trick. The extension keeps that job. The exact internal format of the `PSAI1.` code is also unverified — treat it as an opaque blob you store and hand back intact, not something you decode and re-render on your own. What's left is still a real product: the catalog, the preview, the versioning, the sharing. That's the distribution layer, and it's completely buildable.
The preview that doesn't pretend
Start with the thing people want most: seeing the theme before they import it. Since the code itself is opaque, the preview can't be the extension decoding it live. What it can be is a static page you capture during authoring — representative markup plus the CSS you want to showcase — rendered on its own so a browser can run HTML online and show the look faithfully.
In practice that means each catalog entry carries two things: the shareable code (untouched, for import) and a self-contained preview page (a snapshot you built to demonstrate it). The preview is honest about what it is — a sample, not the live site — and that framing keeps you out of trouble. One of the better tools in the same crowd, a reference checker, made a point of stating exactly what it does and doesn't verify. Borrow that discipline. Say "preview of a sample layout," not "this is how the real page will look."
A registry that remembers versions
The forum-comment approach loses history instantly. Give each code a row instead. A lightweight schema is enough to start: an entry id, a human name, the target site it was made for, the raw code string, a created-at timestamp, and a version number. When a theme changes, you insert a new version rather than overwriting the old one, so "the brutalist v2 I liked" is still retrievable after v3 ships.
Standing this up and poking at it directly through a SQLite editor means you can seed entries, fix a typo in a name, or bump a version without wiring an admin screen first. For a one-person catalog that's often all the backend you need — the database is the product's spine, and you edit it in place. If you later want programmatic access, in-platform API endpoints can read from the same store, but the registry works on day one as plain rows.
Publishing the library
The last piece is turning that registry into something you can actually send to people. A browsable library — list the entries, show each one's preview, expose a copy-the-code button for import back into the extension — is a small front end over the SQLite data. Publishing it with web app hosting gives you a shareable URL you can drop into the same threads where these codes currently go to die, except now there's a durable home instead of a comment that scrolls away.
And because the platform supports sharing and monetization, a curated set of themes isn't automatically a free-for-all. I'd keep expectations modest here — whether anyone pays for restyle codes is unproven, and I'd call any revenue claim unverified until you've actually seen it. The point isn't a business plan. It's that the artifact finally has a container that respects it.
What you end up with
Strip it down and the build is three honest parts. A static preview page per theme that renders a sample so people can look before they import. A versioned SQLite registry so codes stop being disposable forum text. A published library that gives the whole thing a URL. The extension still owns authoring and live injection; you own everything that happens to the code after it's generated.
That split is the whole trick, and it's a repeatable one. Plenty of these shared tools produce a portable artifact — a code, a config, a theme — and then abandon it in a comment box. The engine gets the attention; the distribution gets nothing. If you're the one who builds the distribution half well, you're not competing with the extension. You're finishing the job it started.