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 agentmods add skills/webjsdev/webjs/webjs-scaffold-syncnpx skills add webjsdev/webjs --skill webjs-scaffold-syncgit clone --depth 1 https://github.com/webjsdev/webjsWhat 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 | $0.00301 | $0.05152 |
| Opus 5 | $0.00151 | $0.02576 |
| Sonnet 5 | $0.00060 | $0.01030 |
| Haiku 4.5 | $0.00030 | $0.00515 |
Grade A, and why
webjs-scaffold-sync 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 2d 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 — 259 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Keep every scaffold surface in sync with what webjs create generates
The scaffold is the primary way AI agents learn WebJs, through TWO teaching surfaces that must stay in sync with the framework:
- The agent skill
.agents/skills/webjs/(SKILL.md + references/): the DURABLE teacher. It is the ONE canonical source (bundled into every scaffold at prepack viascripts/sync-scaffold-skill.mjs, and the repo's own agent guide). Crucially,gallery:clearstrips the whole gallery to a blank slate, so the skill is the ONLY teaching surface that SURVIVES, and after a clear it is the agent's sole reference. A feature the skill does not teach is lost the moment an agent clears the gallery. - The gallery (the repo-root
gallery/**app): runnable, densely commented demos an agent learns the idioms from by reading and running, then adapts. It is DISPOSABLE (removed bygallery:clearbefore real work begins). It lives ONCE, at the repo root, as a live workspace app you can boot and test (npm run dev:gallery,npm test --workspace=@webjsdev/gallery).packages/cli/prepackbundles it intopackages/cli/templates/gallery/for the tarball andpostpackdeletes that copy, so never edit or commit there.
So a change to a WebJs FEATURE usually needs BOTH: the skill updated (the durable
pattern) AND a gallery demo (the runnable illustration). A change to what
webjs create emits is a first-class change with MANY surfaces, and the
recurring failure is updating one (usually a template file, or the gallery but
not the skill) while the skill, the per-agent rule files, the scaffold tests, the
framework docs, and the preview apps drift behind. This skill closes that gap.
It is the sibling of webjs-doc-sync. Division of labour:
- webjs-doc-sync owns the framework's API/behaviour docs (the root
AGENTS.mdAPI sections,agent-docs/*.md, docs-site topic pages, the marketing website). - webjs-scaffold-sync (this skill) owns what the scaffold GENERATES and the surfaces that DESCRIBE the scaffold.
They overlap on two surfaces (the scaffold's per-agent rule files, and the template matrix in the framework docs/README). Whichever skill reaches that surface must update it; when in doubt run both.
Enforcement is TWO tiers, deliberately mirroring how tests are enforced (a commit-time floor plus an un-skippable CI gate):
-
Tier 1, the commit floor.
.claude/hooks/require-scaffold-with-src.shBLOCKS a commit that stages framework-feature source (packages/(core|server|cli)/src) with no teaching surface in the same commit (escape hatchWEBJS_NO_SCAFFOLD_GATE=1). A teaching surface is EITHER the scaffold (packages/cli/templatesorpackages/cli/lib) OR the agent skill (.agents/skills/webjs/), since the skill is the durable half of the teaching pair. Like the test commit gate, it only proves you touched a teaching file; it cannot tell a real demo from a doc bullet, nor that you updated BOTH the gallery and the skill where both were needed, which is exactly how #848 slipped (forbidden()/unauthorized() staged doc bullets, shipped no gallery demo). -
Tier 2, the CI coverage gate.
test/scaffolds/gallery-coverage.test.jsreconciles the LIVE framework surface against the hand-curatedtest/scaffolds/gallery-coverage.jsonmanifest and FAILS when a new surface is neither demoed nor exempted. It gates THREE surfaces:@webjsdev/coreexports (a{ demo }pointing at a gallery file that references it),@webjsdev/serverexports ({ demoed: true }, verified by a generated app importing it), and routing convention files (the stems the router parses, DERIVED frompackages/server/src/router.jsso a newstem === '...'branch auto-appears, each demonstrated by a file in a generated app). Every entry isdemo/demoedor{ exempt }with a reason (internal: ...for plumbing,deferred: ...for an agent-facing surface not yet demoed). It runs on everynpm testand in CI, so it cannot be skipped with a local--no-verify, the analogue of "a test must exist AND pass": a new export or convention turns CI red until it is classified. When you add or rename a core/server export, or add a routing convention file the router parses, update the manifest (a demo, or an honest exemption), the same reflex as writing a test.
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.
- 2d ago First seen · 259 lines · 0 tokens per session scan A 4443ad2dac0b
webjs-scaffold-sync is a skill published in the GitHub repository webjsdev/webjs (109 stars, last pushed 11d ago), licensed MIT. It adds 301 tokens to every session and 5,152 once invoked, about $0.0015 per session on Opus 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-08-30.
Other skills, from other repositories
resource-curator
Find, evaluate, and maintain high-quality external resources for JavaScript concept documentation, including auditing for broken and outdated links.
live-tutorial
Create an annotated MP4 tutorial from real screenshots of a workflow on the owner's computer. Use only when the owner explicitly asks for a tutorial video, not merely when they ask to watch an action happen live.
javascriptcore-garbage-collector
JSC GC reference for Bun. Use for use-after-free, JS object leaks, "collected too early", or when touching WriteBarrier, visitChildren, visitAdditionalChildren, JSRef, JSC::Strong/Weak, hasPendingActivity, ensureStillAlive, addOpaqueRoot, reportExtraMemoryAllocated, IsoSubspace, HeapAnalyzer, finalize.
implementing-jsc-classes-cpp
Implements JavaScript classes in C++ using JavaScriptCore. Use when creating new JS classes with C++ bindings, prototypes, or constructors.
implementing-jsc-classes-rust
Creates JavaScript classes using Bun's Rust bindings generator (.classes.ts). Use when implementing new JS APIs in Rust with JSC integration, prototypes, or constructors.
rust-system-calls
Guides using bunsys for system calls and file I/O in Rust. Use when implementing file operations, opening fds, or any syscall path instead of std::fs or libc.