| name | designtools-core |
| description | The pinned facts and permissions the designtools suite is built on. Not usually invoked directly; designtools-start reads it to begin each new project. Consult when questions arise about pinned dependency versions, Claude Code permissions, or how to bump and test the stack. Holds versions.json, settings.json, and the smoke test. It ships no project source — the project is generated from the conventions in designtools-frontend. |
designtools-core: the pinned facts
There is no starter repo, no template, and no copied project source — not even config. A project is generated from the conventions in designtools-frontend: the agent writes index.html, tsconfig.json, vite.config.ts, base.css, the app shell, and the first screen to spec. Freezing those as files to copy is the same mistake as shipping a component set — a frozen artefact that can't adapt to the project and rots on a shelf. In a spec-driven world the spec is the asset; the code is disposable.
So this skill holds only what the agent genuinely cannot derive from convention: two pinned facts and a test.
What this skill holds
- versions.json — the dependency pins. Which React, which Base UI, and therefore which import paths are known-good is a moving fact with a training cutoff; the agent can't reliably infer it. This is the spec for dependencies, the single bump-point, and the smoke-test target — not a file copied into the project. designtools-start reads it to write each project's
package.json.
- settings.json — the Claude Code permissions.
acceptEdits plus an allow list for the commands the suite runs, so a designer is not asked to approve pnpm install. The one file copied verbatim into each project (.claude/settings.json) and offered for ~/.claude/settings.json by designtools-setup — permission policy should be exact and auditable, not regenerated.
- scripts/smoke.sh — the whole maintenance ritual. It carries a minimal reference app inline (a test fixture, never shipped into a project) and proves the pinned stack still installs, type-checks, and builds.
What's pinned, and what isn't
Dependency versions are pinned facts — bumped on purpose in the manifest. Permissions are pinned policy — copied exact. Everything else is generated:
- The project source —
index.html, base.css, config, the app shell, screens — is generated by the agent from the conventions in designtools-frontend (base styles and the scale, the document <head>, project config). Generated per project, so it can adapt; nothing to maintain here.
- Colour is generated from the brand seed by designtools-tokens (deterministic OKLCH, contrast-checked). A tool the agent runs, not a file on a shelf.
- Components are composed from Base UI primitives on demand (designtools-frontend). No frozen set — styling is the app and should differ per project.
The pattern throughout: pin the facts the agent can't know, hand it tools for the maths it's bad at, and trust it to generate the rest from convention.
Maintaining the stack
The only standing tax: bump versions.json on purpose, then run scripts/smoke.sh. It writes a reference app the way designtools-start would — package.json from the manifest, config and base styles to convention, tokens generated — installs, type-checks, and builds, and fails if anything is broken. Update lastVerified when you do.
Base UI note: the package is @base-ui/react (stable since v1.0, Dec 2025). Verify component import paths at base-ui.com when bumping; the smoke test will catch a break.
