Four design skills is not a designer. Meet Graphic Designer.

I asked for a twenty-four-label graphic. The render returned sixteen.

Nothing errored. No warning, no failed check, no red anywhere. The image came back looking finished. Eight of the facts I had asked for were simply gone, and two of the survivors were misspelt. Forward that to a client and they will quote it with confidence.

That is the failure mode I built a profession around. Not a bug I patched. A boundary I hired for.

Who this role is for

You already own good design skills. That is the problem.

Di-Atomic ships four of them, and each one is deliberately narrow. Narrow is what makes them good. But narrow also means each stops somewhere different, and none of them stops at "done".

iconography picks the set, resolves the token, clears the licence, and ships no files. section-designer composes the markup and explicitly stops at hand-off. explainer-illustrations plans the shot list and hands the prompts onward. infographic writes its own HTML but cannot render raster at all.

Install all four and you own four half-pipelines. You also inherit a job nobody put in the box: knowing, per request, which one to open, where it stops, and who finishes it.

Here's why that matters: the gap is not a missing feature. It is a missing role.

What you hire when you equip Graphic Designer

A request goes in. A hosted URL and a verifier report come out.

That is the whole promise, and it rests on one fact about the chain. Twelve skills are linked into this profession. Six are called, six are read. Across all twelve there is exactly one call that actually renders an image: gateway-skills.generate, at POST /media/generations. None of the four design skills holds it. This role does.

The catch is that the chain is full of things that look callable and are not. media-generator declares six method names and routes none of them. It builds the prompt and picks the model. It does not render. Call it and you get a guaranteed missing-method error, which is exactly the defect that shipped in an earlier profession of mine. media-skills looks like hosting and is a read-only catalogue with no upload path at all. Hosting here is a side-effect of rendering, not a step you can perform on someone else's file.

So the role holds the render and the catalogue. It routes, it produces, it proves, it hands over.

The toolkit, and what each piece is for

Six that it calls:

• @opvs-ai/agentboard gives a render-bearing job a card with a hand-back stage, so multi-minute render state survives a compact.

• @opvs-ai/agentdocs holds the design intake, the shot lists, and the asset provenance.

• @opvs-ai/agentmemory is the compounding layer: set, style pack, design system, mark permissions.

• @opvs-ai/opvs-protocol carries requests in and hand-offs out.

• @spideriq/gateway-skills is the one real render in the chain.

• @spideriq/media-skills finds an asset by content after an ambiguous timeout.

Six that it reads and then runs itself:

• @di-atomic/iconography for set choice, token resolution, licence verdict, and the RTL contract.

• @di-atomic/infographic for the nine content shapes, the render-path routing, and the fabrication gate.

• @di-atomic/section-designer for 150 design systems and the script-driven critique.

• @di-atomic/explainer-illustrations for cognitive-anchor extraction and shot-list planning.

• @di-atomic/media-generator to build the prompt and pick the model.

• @di-atomic/voice-builder, whose "never does" list extends the slop blacklist.

Five workflows, and what fires each one

client-intake runs on a new brand, before any asset exists. It decides the visual constants once and writes them down.

asset-request-route runs on any visual request. It names the artifact class out loud, produces exactly that class, and finishes the pipeline.

infographic-build runs on a data or document graphic. It carries the fabrication gate.

icon-system-adopt runs when a surface needs a real icon vocabulary. A dead token renders nothing and raises no build error, so resolution is checked against the live set by script, every time.

render-path-escalation runs when a render times out, hits the ceiling, or comes back ambiguous. Every branch in it is a measured failure, not a hypothetical.

The refusals are the role

Fifteen rules in negative_scope say what this role will not do. Three of them are the product.

It will not put a number in a graphic that is not in your source. A request with no data and no document is a request to fabricate, and the answer is to ask for the source.

It will not ship a raster above sixteen labels. That ceiling is measured, not guessed. Above it you get a finished-looking image missing your facts.

It will not grade itself. Delivery is gated on the owning skill's own verifier report, shown to a human in full before hand-off. Those scripts exit zero by design. The report is the product and the exit code is not the verdict. Read only the exit code and you will cheerfully call a fabricated graphic clean.

And when a refusal blocks a deadline, it escalates to @ops::di-atomic rather than softening. Deadline pressure changes who decides. It never changes what the refusal is.

The guild address, and why the craft compounds

The address is graphic-designer@profession.md.

That is not decoration. It is how another profession sends this one a request, and how this one hands work back. A profession is a single file that carries its own method, its own judgment, its own toolkit, and its own limits. Equip it and you get all of that at once, versioned.

Now the part that actually pays. A brand's icon set, style pack, design system, and mark permissions get decided once at intake and written to memory as structured fields. Today those get re-litigated on every request, because nothing durable holds them. That is how one brand ends up rendered to two different looks by two sessions in the same week.

Decide them once and the second asset is cheaper than the first. The twentieth is consistent with the first, and nobody has to remember why. A second intake run confirms rather than re-decides, because re-deciding on a brand with published assets is drift, and drift is invisible one asset at a time.

What it will not do

I would rather you know the edges before you equip it.

It does not publish. Nothing is live until SpiderPublish deploys it, so this role hands over rather than ships. It does not write the words: copy-engine is deliberately unlinked so that refusal stays sharp. It does not build brand identity systems, only work inside one you already have. It cannot host a file it did not itself render. And it does no motion, video, or audio.

Equip it

opvs-skills install @di-atomic/graphic-designer

Bottom line? Run client-intake first. It is the blocking workflow and it produces no asset, which is the point. Your first thirty days should look like one intake, then a run of requests where the constants are recalled rather than re-argued. The number to watch is not how fast the first asset ships. It is whether the second one costs less than the first.