Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add yonatangross/orchestkit --skill multi-surface-rendergit clone --depth 1 https://github.com/yonatangross/orchestkitWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/yonatangross/orchestkit/multi-surface-render)<a href="https://agentmods.dev/skills/yonatangross/orchestkit/multi-surface-render"><img src="https://agentmods.dev/badge/skills/yonatangross/orchestkit/multi-surface-render/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/yonatangross/orchestkit/multi-surface-render"><img src="https://agentmods.dev/badge/skills/yonatangross/orchestkit/multi-surface-render.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00098 | $0.03955 |
| Opus 5.5 | $0.00039 | $0.01582 |
| Sonnet 5.5 | $0.00020 | $0.00791 |
| Haiku 4.5 | $0.00010 | $0.00396 |
Grade A, and why
multi-surface-render scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 19d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 387 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Upstream version reference: @json-render/core 0.21.0 (2026-09-30).
Multi-Surface Rendering with json-render
Define once, render everywhere. A single json-render catalog and spec can produce React web UIs, PDF reports, HTML emails, Remotion demo videos, and OG images — each surface gets its own registry that maps catalog types to platform-native components.
Quick Reference
| Category | Rules | Impact | When to Use |
|---|---|---|---|
| Target Selection | 1 | HIGH | Choosing which renderer for your use case |
| React Renderer | 1 | MEDIUM | Web apps, SPAs, dashboards |
| PDF & Email Renderer | 1 | HIGH | Reports, documents, notifications |
| Video & Image Renderer | 1 | MEDIUM | Demo videos, OG images, social cards |
| Registry Mapping | 1 | HIGH | Platform-specific component implementations |
Total: 5 rules across 5 categories
How Multi-Surface Rendering Works
- One catalog — Zod-typed component definitions shared across all surfaces
- One spec — flat-tree JSON/YAML describing the UI structure
- Many registries — each surface maps catalog types to its own component implementations
- Many renderers — each package renders the spec using its registry
The catalog is the contract. The spec is the data. The registry is the platform-specific implementation.
Quick Start — Same Catalog, Different Renderers
Shared Catalog (used by all surfaces)
import { defineCatalog } from '@json-render/core'
import { schema } from '@json-render/react/schema'
import { z } from 'zod'
export const catalog = defineCatalog(schema, {
components: {
Heading: {
props: z.object({
text: z.string(),
level: z.enum(['h1', 'h2', 'h3']),
}),
children: false,
},
Paragraph: {
props: z.object({ text: z.string() }),
children: false,
},
StatCard: {
props: z.object({
label: z.string(),
value: z.string(),
trend: z.enum(['up', 'down', 'flat']).optional(),
}),
children: false,
},
},
})
What ships with it
13 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
- references/ork-delta.md 5.4 KB
- references/upstream-email.md 5.8 KB
- references/upstream-image.md 2.8 KB
- references/upstream-pdf.md 3.7 KB
- references/upstream-remotion.md 2.9 KB
- rules/_sections.md 1.4 KB
- rules/_template.md 339 B
- rules/pdf-email-renderer.md 3.6 KB
- rules/react-renderer.md 2.6 KB
- rules/registry-mapping.md 3.9 KB
- rules/target-selection.md 2.8 KB
- rules/video-image-renderer.md 3.7 KB
- test-cases.json 3.5 KB
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 19d ago Changed · +2 lines 55f2bbfa2c70
- 21d ago Changed · -1 lines 5f3f16246cdf
- 29d ago Changed d9caa657d523
- 1mo ago First seen · 386 lines · 98 tokens per session scan A 042fa56271c8
multi-surface-render is a skill published in the GitHub repository yonatangross/orchestkit (297 stars, last pushed today), licensed MIT. It adds 98 tokens to every session and 3,955 once invoked, about $0.0004 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-03.
Other skills, from other repositories
decocms-ui
Build or style React UI with the decocms product design system (@decocms/ui). Use when creating interfaces, pages, or components in a project that should look like decocms products, when the user mentions "design system", "@decocms/ui", "decocms style", or asks to make UI consistent with Studio. Covers installation…
frontend-design
Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, artifacts, posters, or applications (examples include websites, landing pages, dashboards, React components, HTML/CSS layouts, or when styling/beautifying any web UI).…
pn-ui-component-libraries
Curated UI/UX and component library knowledge. Recommends libraries for stack and use case; when shadcn MCP is available, use its tools to browse/search/install. Use when building UI, during discovery, or prior-art for frontend projects.
factsheet-design
Print design system for systemprompt.io PDF factsheets and one-pagers. Light branded containers (never dark glassmorphism), print token table, sp-card asymmetric corners in points, full-width SVG diagram rules, WeasyPrint constraints, and the two-page budget discipline. Load before creating or editing any factsheet…
chakra-ui-refactor
Review or refactor Chakra UI v3 code INSIDE packages/design-system only. Use only when editing files under packages/design-system. Feature code in modules//browser or apps/ui never imports Chakra: use the design-system skill instead.
design-system
Which component to use, where tokens and colour live, and why nothing but packages/design-system imports Chakra or Emotion. Use when someone says 'which component', 'design system', '@langwatch/design-system', 'import Chakra', '@chakra-ui/react', 'primitives', 'Box/Flex/Button', 'theme', 'token', 'colour', 'hex'…