The same paper can now come out looking different depending on a style users pick before generating: a charcoal-and-parchment "Academic Editorial," a candy-colored maximalist look, a flat WPA-era "Vintage Travel Poster," a raw "Brutalist" anti-aesthetic. Each style is a fragment of instruction appended to the prompt before Claude generates the page -- so the whole thing works with zero changes to the generation pipeline.
Changed from deployable files to admin tool
Claude's first plan stored each style as a text file and pushed those files into the database on every deploy. This kind of short-sighted design is typical of LLMs so I had to steer it in the more sensible direction of making an admin tool.
The source of truth is now the database, not the files. Each style gets a record that includes the prompt, name, and some metadata. The text files survive only as a one-time seed for a fresh environment, and the seeder uses a conditional write that refuses to overwrite a row that already exists. A re-deploy never overwrites an edit someone made from the dashboard; it just reports "already there" and moves on. The files are now an audit trail of original intent, not the live store — which matters the first time someone needs to fix a typo from their phone.
And since I have both test and production environments, I made a handy Claude skill that copies the theme database records from one environment to the other.
Parallel build using sub-agents
All engineering tasks are handled by Beads by Steve Yegge. Brilliant tool. My beads-planner plugin makes it easy to grab GitHub issues, create a plan with Claude, then decompose it into Beads. Beads automatically have relationships and dependencies so Claude can decide how many sub-agents to fire up based on parallelizable tasks.
For this feature, I had Claude fan the work out across sub-agents working on disjoint files in three waves -- generation plumbing, the dashboard CRUD UI, the public dropdown, the tests -- and aggregate the commits between waves. A couple of agents flagged real cross-cutting gaps for me to fix in between, like a deploy script that separately tracks every Lambda in three different places. New GitHub issues were created for these so as not to clutter the current context.
The deploy itself squeaked through because the infrastructure change pushed the Lambda's inline permissions policy near the ceiling. It succeeded, but failed on the very next feature, which forced a move to managed policies (which is architecturally better but doing it too early would have been over-engineering).
One late catch: after everything deployed, some styles had the same fundamental design mistake — light text on light backgrounds - that were a problem in beta versions of the app. The fix was to remind Claude about font-to-background contrast requirements both at the start and end of the prompt.