Toolcraft

MIT-licensed, source-owned React/TypeScript architecture for building focused canvas-and-controls creative applications with coding agents.

Recommendation

Use Toolcraft when the product is a real creative or design application: the user manipulates visual output on a canvas, needs meaningful controls, and may need upload, history, pan/zoom, layers, playback/keyframes, image export, or video export. Examples include procedural graphics, image stylizers, shader or Three.js tools, animation controllers, and constrained brand-asset generators.

Do not route an ordinary website, dashboard, settings page, single animated component, or small developer overlay here. Use the existing design system and component-source routes for those jobs. Use Fieldwork — Visual Design IDE to inspect and iterate an existing product UI, and use HyperFrames when the deliverable is a deterministic authored video rather than an interactive design tool.

Create a new Toolcraft project only for an explicit project request:

npx @pixel-point/toolcraft create

The generated application includes editable runtime and UI source rather than hiding the system behind a package. That makes it inspectable and forkable, but also means adopting it is an architectural decision rather than adding one UI component. Pin the source revision, inspect generated dependencies and local contracts, and keep the generated integrity/verification boundary intact. Source: Toolcraft README and starter contracts at 4b1e415b; Pixel Point Toolcraft article, 2026-06-30

What the bookmark understated

The saved post calls Toolcraft an open-source kit and UI library. Its linked repository goes substantially deeper:

• a typed defineToolcraft / ToolcraftApp product composition boundary;
• source-owned canvas, controls, toolbar, upload, history, pan/zoom, radar, optional layers, timeline, keyframes, image export, and video export;
• local agent routing and decision contracts;
• application schemas, product-readiness declarations, control inventories, acceptance mappings, and performance envelopes;
• unit, contract, browser, acceptance, export-decoding, integrity, kernel, and performance proof;
• six example applications plus a neutral starter.

The reviewed 11.7-second post video visibly moves among 3D decal/model work, a pixel-mosaic image transformation tool, and a liquid/shader-like effect while preserving the same editor grammar. The media therefore supports the product category, but the repository contracts and executable tests—not the demo reel—support the architectural claims. Source: local video and contact-sheet review, X 2083840902779556202, 2026-08-12

Durable design-app contracts

Runtime shell and product output stay separate

Product code supplies typed schema, product state, commands, and output. It does not rebuild the canvas shell, panels, toolbar, timeline, layers, or built-in controls. canvasContent contains product output only; application chrome does not leak into the export surface. Generated host/runtime files are signed and checked, while product modules remain editable and independently inspectable.

This is the main distinction from assembling a design app out of a component shelf: the shell has one owner and the product has explicit extension points. Source: starter/docs/toolcraft/core/runtime-boundary.md@4b1e415b

One operation has one primary interaction surface

Before implementing an operation that could live on the canvas or in a panel, Toolcraft requires a typed ownership decision. Direct selection or spatial manipulation may belong on the canvas while exact values, modes, constraints, collections, and commands belong in the panel. The same capability cannot be recreated in both places with different chrome. Related operations may use both surfaces only when their typed capabilities are actually different.

Controls are selected from the product value model before appearance. Compound owners such as gradients, font pickers, curves, collections, and orientation gizmos remain atomic; custom controls require evidence that a built-in cannot represent the need. Source: starter/docs/toolcraft/core/control-selection.md@4b1e415b

Animation intent is not artifact intent

Every motion-bearing product classifies animation as playback, keyframes, custom reference timeline, or autonomous decoration. Product transport stays in the top timeline instead of being duplicated in the control panel. A seamless loop is forward-only by default, and duration edits change loop length rather than product design.

Animation, playback, keyframes, or a timeline do not imply video export. Image export starts as the product default; video export exists only when the user explicitly asks for video delivery, and image remains unless explicitly removed. Preview transport and artifact delivery are separate decisions. Source: starter/docs/toolcraft/core/timeline-animation.md and core/setup-export.md@4b1e415b

References are studied as behavior

A reference port begins with a complete feature inventory and an explicit transfer mode. Source/runtime behavior, controls, output, state, reset, persistence, export, and transport map to acceptance IDs. Figma work reads the actual node/component/variable structure before screenshot QA. Video, GIF, and screen-recording work records timecoded frames, frame-to-frame transitions, behavior decomposition, and acceptance mapping before code.

A single screenshot or style summary cannot establish reference behavior. Source: starter/docs/toolcraft/core/reference-study.md@4b1e415b

Proof is observable and protected

Acceptance proof binds a real visible product entity to a real operation and a persistent outcome. Export proof decodes a non-empty artifact and checks typed dimensions/content rather than accepting that a download event fired. Generic helpers cannot claim specialized timeline or export evidence. Product code cannot import, assemble, or forge protected evidence channels.

The normal delivery boundary is one bare verify:delivery: complete functional proof for the first product delivery and affected functional proof thereafter. Measured performance needs request authority and exact affected paths; a full performance matrix requires explicit operator approval. This prevents every edit from turning into a slow benchmark loop while preventing a screenshot or build from masquerading as product proof. Source: starter/e2e/app-browser-acceptance-evidence.spec.ts, starter/src/app/acceptance/validation-pipeline.test.ts, and starter/docs/toolcraft/core/performance.md@4b1e415b

Skills and repository size

The pinned repository contains 36 SKILL.md files, but content hashing shows only six unique helper procedures—brainstorming, browser verification, Figma inspection, Figma implementation, systematic debugging, and plan writing—each repeated across six generated examples. Keep their Toolcraft-specific rules in the generated app. Do not install or count them as 36 distinct global capabilities; Kevin's incumbent planning, browser, Figma, debugging, and design skills already own those general jobs.

Pinned evidence at 4b1e415b records 3,841 blobs, 490 directories, 88.9 MB of blob content, 507 conventionally named test files, 36 skill manifests, seven package manifests, six examples, and one starter. The repository was MIT with 534 stars at capture. Size and popularity justify deliberate evaluation; they do not prove product fit or authorize installation. Source: frozen repository evidence captured 2026-08-12

Local routing

Timeline

• 2026-08-12 | Deep-reviewed the saved post, website, primary article, 11.7-second demo, exact repository revision, neutral starter, canonical local workflow, decision contract, core runtime/control/timeline/export/reference/ performance modules, six unique skill bodies, package scripts, acceptance tests, and local routing. Promoted Toolcraft as a distinct creative-app capability, not a general component library or automatic install. Source: X 2083840902779556202; pixel-point/toolcraft@4b1e415b