@urbicon-ui/design-content

The version-pinned bundle of Urbicon UI design knowledge plus a package-relative locator for it. This is the Knowledge plane of the design tooling (the deterministic linter/manifest/rubric Judgment engine lives in @urbicon-ui/design-engine).

Because the content ships inside this package, consumers — the remote MCP server, the urbicon CLI, a CI hook — resolve it from their own install location with no monorepo sibling-path assumptions, and the knowledge is automatically coherent with the installed library version.

What's in the bundle

The content/ directory is a build artifact (git-ignored in dev, regenerated by docs:gen:all / build, shipped on publish):

| File / dir | Contents | | --- | --- | | component-catalog.json | All components (props, variants, slots, tags) + recipes (with code) + tag index | | <group>/<slug>/llm.txt | Per-component LLM documentation (overview / examples / variants / api / slots) | | design-system/principles.md | Design principles, by topic | | design-system/patterns/*.md | Layer-4 composition patterns (dashboard, form-page, …) | | guides/llms-full-template.md | Source for the seven guide resources | | icons.json | Icon metadata (name → label / categories / keywords / component) | | meta.json | Build provenance { version, builtAt, contentHash } |

API

import {
  getCatalogPath,
  getComponentLlmPath,
  getContentDir,
  getDesignSystemDir,
  getIconsPath,
  getTemplatePath,
  loadContentMeta
} from '@urbicon-ui/design-content';

The functions return absolute paths into the bundle (a thin, dependency-free locator); consumers do the reading/parsing. loadContentMeta() reads meta.json, or returns null when the bundle has not been generated yet.

Overriding the bundle location

Set URBICON_CONTENT_DIR to point the locator at a different bundle — used in monorepo dev/tests against a freshly generated content/, or to serve an alternate content set.

License

MIT