Monday: noticing the scatter across 188 articles
Opened the /writing index on my phone, scrolled for thirty seconds, and realized the image system was broken. Not any single image. The whole index. 188 articles, 14 clusters, hero images distributed by nothing in particular. A dune interior next to an iridescent glass prism, next to a fantasy ruin, next to another glass prism. Visual coherence per cluster: zero.
Each image had been fine on its own. Commissioned, reviewed, approved in the feedback ledger, shipped. But the /writing index was not reading as a library. It was reading as a shuffle.
Tuesday: pool-per-cluster as the unit of coherence
The instinct was to art-direct each post harder. Wrong instinct. At 188 articles that path ends in burnout, and it still would not fix the underlying problem, which is that the cluster is the unit of design, not the article.
Pulled up src/lib/writing-clusters.ts and the 14 cluster definitions. Each cluster has its own audience and topic shape. Each one should also have its own visual archetype, the same way a brand has a type scale and a color system. One rule per cluster. The article inherits.
First-draft mapping, cluster to style:
ai-agent-engineeringinherits monoliths in nature.brand-architecture-dtcinherits dune architectural interiors.dtc-shopify-infrastructureinherits fantasy ruined architecture.healthcare-complianceinherits fantasy ice and arctic forms.attribution-and-capiandanalytics-data-infrastructureinherit the prior iridescent-glass inventory (it already matched those topics).email-lifecycle-marketinginherits portal landscapes.paid-social-dtcandecommerce-conversion-uxinherit epic fantasy terrain.services-pricing-businessandfractional-ops-leadershipinherit dune worlds.creative-tech-solo-brandinherits epic solitary landscapes plus a pinch of iridescent.programmatic-seo-content-opsandshopify-app-stackinherit fantasy architecture and mountain formations.
Ran the remap as commit 5bd7b25. 188 heroes swapped in place. No regen yet; this pass only reassigned from the pooled library.
Wednesday: 27 within-cluster duplicates left over
Walked the index again. Better. Not done.
The thin pools had a predictable problem: 12 dune images could not uniquely hero 12 brand-architecture articles. Some clusters had 8 images and 12 slots. Within a cluster, two neighboring articles were sharing the same hero, and two neighbors with the same image reads like a broken carousel.
Counted the duplicates. 27. Each duplicate was a specific slot: cluster X, article Y, currently sharing image Z with article W. That list was the actual work queue.
Thursday: 81 bespoke prompts to fill the last holes
81 prompts. 27 concepts, 3 variants each. Authored on the Mac, queued on the Windows box, rendered in Flux. The hardware split has its own write-up in the Mac-plus-Windows GPU pipeline notes if you want the full setup.
Three variants per concept let me pick without regenerating. Prompt taxonomy from the image feedback ledger kept the pass focused. The ledger is ninety-plus reviews at this point, so I know what works ("monolith, off-center, shallow depth, single dominant form") and what never works ("hooded figures, spaceships, internal-refractive-planes in Z-Image"). The taxonomy is the reason 81 prompts produced 27 usable picks instead of 9.
“The cluster is the unit of design, not the article. One rule per cluster. The article inherits.
”
The Mac drives prompt writing only. The Windows box with the dGPU runs the diffusion. SSH the prompts over, run the batch, pull the outputs back, review in a simple HTML button-driven template I keep around for exactly this. That split means I do not crash the Mac with simultaneous Flux loads, and I do not eat cloud-API cost per image when I am iterating. The mflux safety wrapper is the reason I trust the Mac with any concurrent generation at all, and the Z-Image Turbo versus Flux Schnell grammar divergence is why the 81 prompts all targeted Flux, not Z-Image, for the within-cluster deduplication work.
Reviewed all 81, picked 27, dropped the prompts-round-21 file into .image-work/ as commit ade5afc.
Friday: shipping remap v3 on main
Remap v3 shipped as commit 158c8ec on main. Every duplicate slot now has a unique hero. Every cluster reads as a coherent visual family. The index reads as a library.
The best read of the week is that I built a content hero image design system without writing a design system doc. The rules live in the mapping file, the cluster pool directories, and the feedback ledger. The same thinking I put into a design-token system that survives a rebrand applies to a content image system: write the rule at the pool level, let the individual article inherit, only hand-tune the exceptions.
This is also why the living brand guide matters more than a static PDF. Static guides cannot hold "cluster X gets dune, cluster Y gets monoliths, except these 27 specific slots which get bespoke variants keyed off the prompt taxonomy." Living docs can.
What a content hero image design system actually teaches you
Pool before bespoke. Generic cluster styles covered 85% of slots for free. Commissioning 188 bespoke heroes would have been the wrong shape of work, and the wrong shape of spend.
Bespoke only for the duplicates the pool cannot solve. 27 out of 188 is the ratio I will plan against next time. Budget for the long tail up front; do not pretend the pool will do everything.
The /writing index is the design artifact, not the individual article. That reframe is the real lesson. I was grading myself on "did this article get a great hero" when the grade that mattered was "does the library read as a library." Same mistake happens in a DTC context: grade the PLP, not just the PDP. The component library handoff for designer-to-code teams covers the parallel pattern for shippable UI: review the library, not only the page.
Visual coherence is a cluster-scale problem because the cluster hub-and-spoke architecture is already the cluster-scale problem. You build the hub article, you build the supporting articles, you build the visual family. Three artifacts, one unit of work.
Brand architecture work looks like this in practice. Not a rebrand, not a mood board, not a 60-page PDF. A week of systematic pool-and-fill work that makes the content you already shipped look like it came from the same studio. More of this pattern in the brand architecture hub and in the brand case study set for where this kind of system-level visual work lands in client engagements.
One last note: the AI-content workflow that grounds these articles uses the same pool-and-fill thinking. The writer agent stack with real grounding is the upstream equivalent of the cluster pool. Each article writer reads the cluster definition first, inherits the voice and the topic shape, then writes only what is specific to its slug. Cluster-uniform voice, slug-specific body. Same pattern, different artifact.
FAQ
Why not just commission a bespoke hero for every article?
At 188 articles and 14 clusters, bespoke-for-everything is the wrong shape of work. The pool-and-fill pattern lets 85% of slots inherit a cluster-level rule, and only the duplicates need hand-authored prompts. That is 27 bespoke renders instead of 188, which is the difference between a week of work and a month.
How do you pick which visual archetype fits each cluster?
I read the cluster's tagline and audience in src/lib/writing-clusters.ts, then pick a style already present in my image library that reinforces the cluster's topic. The regulated-topics cluster gets arctic forms because the content is cold, forensic, exacting. Shopify infrastructure gets fantasy ruined architecture because the topic is rebuilding on top of legacy structures. The choice should explain itself once you see the pairing.
What is the feedback ledger and why does it matter for prompt authoring?
The ledger is a JSON file at .image-feedback-ledger.json with every reviewed image and a tag for why it worked or did not. After ninety-plus reviews, the taxonomy predicts what a new prompt will produce. That is why 81 targeted prompts yielded 27 usable picks on the first pass instead of needing a second round.
Why a Mac-for-prompts and Windows-for-render split?
The Mac is where I write and review. Running Flux there crashes the machine under load, and cloud-API pricing eats margin at iteration scale. The Windows box has the dGPU and runs the diffusion models locally. SSH prompts over, pull outputs back. The split keeps the Mac responsive and the per-image cost at zero after hardware amortization.
Would this same approach work for stock imagery instead of generated?
Yes, the pool-per-cluster pattern is indifferent to the image source. Replace the generated pool with a Unsplash or Getty collection tagged per cluster and the remap logic is the same. The bespoke-fill step just becomes "commission or shoot these 27" instead of "prompt these 81 variants." The cluster-scale design rule is what carries the work.
How do you version the system when you add a 15th cluster?
Add the cluster definition, pick its visual archetype from the existing pool or commission a new micro-pool, run the remap script, and the registry updates. A new cluster with 10 articles can usually inherit an existing style that fits; commission only if the topic shape does not match anything already in the library.
Sources and specifics
- Site carries 188 published articles across 14 topical clusters as of 2026-04-24; counts pulled from
src/content/writing/_registry.jsonandsrc/lib/writing-clusters.ts. - Cluster-uniform hero styles shipped as commit
5bd7b25on 2026-04-24; cluster remap v3 on main shipped as commit158c8ecthe same day. - Round 21 of the image work produced 81 bespoke prompts (27 concepts, 3 variants each) targeting 27 within-cluster duplicate slots; prompts logged at
.image-work/prompts-round-21.jsonand committed asade5afc. - The 111-image approved asset library was consolidated in commit
320b096, retiringpublic/images/fantasy/in favor of the cluster-keyed pool directories. - Prompt taxonomy and review state live at
.image-feedback-ledger.json; image generation runs on a Windows dGPU host driven by prompts authored on a Mac, described in the cluster-remapping notes at.image-work/cluster-remapping-v3.txt.