The part everyone copies, and the part that actually lasts
Someone pulled an Agent Skill out of OpenAI's storage engineering blog. You know the figures: white background, thin lines, small squares that run back and forth along the connections. They captured that house style, pushed the skill to GitHub, and stood up a live page where the animation plays. The look holds up. It's a clean piece of work.
But something nags me every time I see a skill built this way. What got packaged is a prompt that teaches a model to imitate a style. The style lives in the model's head for the length of one request. Ask for the same diagram tomorrow and you get a slightly different figure. The box drifts two pixels, the easing curve changes, a label wraps differently. For a one-off blog image that's fine. For a figure you want to reuse across a doc set, a changelog, or a product page, re-improvisation is a bug, not a feature.
The durable asset isn't the prompt. It's the diagram spec. The layout and the animation timeline, written down as structured data you can read, diff, and hand-edit. Once that exists, the model's job shrinks to "produce or amend a spec," and rendering becomes a deterministic step that has nothing to do with sampling temperature.
The broader signal underneath the skill
Look across what builders are actually shipping right now and the same shape keeps showing up. One developer described sending out a large batch of pull requests last month, all driven by cloud agents, leaning on a personal skill set for rigorous engineering and self-validation. The agents collect context, run end to end, and verify their own output while the person is asleep. The number is theirs and I'd treat the throughput as unverified, but the method is the interesting part: the skill plus a validation gate is the thing that carries the work, not the raw model call.
Another note compared two assistant apps and landed on the same nerve. The one that stuck gave each agent its own instructions and memory, so threads didn't bleed into each other. The other dumped everything into one shared memory board and the context went muddy. Isolation and a stable record beat a single improvising brain.
And then there's the honest confession from someone who topped up three AI subscriptions, copied what everyone else was doing, and ended up with tools and an empty head. That's the failure mode when you buy capability without building a durable output. A skill that re-improvises every run is a soft version of the same trap. It feels productive and leaves you nothing you can trust to repeat.
So the move is: stop treating the prompt as the deliverable. Treat the spec as the deliverable, and make rendering boring and repeatable.
What I'd actually build on VicroCode
Here's the architecture I'd rebuild from the editorial-diagram idea, mapped to what the platform actually supports.
The spec is a plain structured record. Nodes with positions and sizes, edges between them, and an animation track that says which token moves along which connection and when. That record is the single source of truth. A human can open it and nudge a coordinate. An agent can regenerate it from prose. Either way, the record is the contract.
The generation and validation step is a Python service. You feed it a prose description, it emits a spec, and before returning anything it validates the spec against a schema: every edge references real nodes, nothing overlaps out of bounds, every animation step points at a connection that exists. If validation fails, it rejects the spec instead of handing back a broken figure. You can run Python online and expose that routine as a hosted API endpoint, then register it as an in-platform tool call so an agent invokes it the same way the cloud-agent crowd invokes their validation steps. The agent proposes, the endpoint judges.
Rendering is a hosted HTML page that reads a spec and draws it deterministically. Same spec in, same frame out, every time. No model in the render path at all. Because you can run HTML online and publish it, the animated figure gets a stable URL you can drop into docs or share with a reviewer, and it replays identically rather than being redrawn by a model on each load. I can't verify how the original Vercel demo behaves under reload, so I'd treat deterministic replay as a property you design in, not one you inherit.
The spec store is where versioning lives. Keep every spec as a row with an id, a version number, the prose that produced it, and the validated JSON. A SQLite table handles this without any infrastructure to babysit, and the built-in SQLite editor lets you open a spec, bump a label, and save a new version by hand when the agent gets 90 percent of the way there. That's the hand-editable record the whole idea rests on. You get history for free, you can roll back to the figure that looked right, and you never lose a diagram to a model that decided to redraw it.
Where the boundaries are
I want to be straight about what this is and isn't. The original skill ships through GitHub and renders on an external host; rebuilding it here means moving the hosting and the endpoint onto the platform, not calling out to those services. The deterministic rendering has to be written in HTML and plain client-side logic, since that's the publishing surface available. Heavy export formats, native desktop packaging, or a non-HTML render target fall outside what I'd promise with these pieces. And any claim about speed, output quality, or how many figures you can crank out stays unverified until you measure it on your own specs.
What's solid is the spine: prose goes to a Python endpoint, the endpoint returns a validated spec, the spec lands in a SQLite version store, and a hosted HTML page renders it the same way on demand. The model becomes a drafting assistant for a record you own, instead of the thing you re-roll every time you need the figure again.
That's the shift worth internalizing from everything builders are shipping this season. The leverage isn't in the prompt. It's in the artifact the prompt produces, written down somewhere you can version, validate, and re-render without crossing your fingers.