# Getting Started Initium gives your shadcn project a shared design direction, installable styles, production-ready blocks, and agent skills that help AI tools build with the same constraints your team uses. This guide is the shortest path from an existing app to a working Initium setup. ## What You Need - A React, Next.js, or compatible app that can use shadcn. - shadcn initialized in the project. - Access to the Initium app: the [Style Builder](https://app.initium.sh/), the [Strategy Builder](https://app.initium.sh/strategy), and the [Blocks browser](https://app.initium.sh/blocks). - An `INITIUM_LICENSE_KEY` if you want to install pro blocks or the Initium skill pack. If your app does not have shadcn yet, start with [Registry Setup](./install-shadcn-and-registry.md). ## Free And Pro Access | Item | Access | Notes | | --- | --- | --- | | Style Builder exports | Free | Generates a custom registry URL for your selected style preset. | | `DESIGN.md` | Free | Exported from the Style Builder and used as visual guidance for AI tools. | | Strategy Builder exports | Free | Generates `STRATEGY.md` for audience, offer, positioning, and page structure. | | Base Initium styles | Free | Installable as `@initium/initium-styles`. | | Styled buttons and forms | Free | Installable through the Initium registry namespace. | | Pro blocks | Pro | Require `INITIUM_LICENSE_KEY`. | | Initium skills | Pro | Installed as `@initium/initium-agent` and require `INITIUM_LICENSE_KEY`. | Free registry items can be installed without a license key. Pro items return an authorization error until your project has `INITIUM_LICENSE_KEY` available. ## 1. Initialize shadcn If your project already has `components.json`, shadcn is already initialized. If not, initialize it first: ```bash npx shadcn@latest init ``` Choose settings that match your app. Initium is installed through the shadcn registry system, so shadcn must be working before you install Initium items. ## 2. Add The Initium Registry Add the Initium registry namespace to your project's `components.json`: ```json { "registries": { "@initium": { "url": "https://app.initium.sh/r/styles/{style}/{name}.json", "headers": { "Authorization": "Bearer ${INITIUM_LICENSE_KEY}" } } } } ``` Keep the authorization header even if you start with free items. Free installs still work, and pro installs will work once the license key is available. The `{style}` placeholder is filled in by the shadcn CLI from your project's `style` setting. Initium components are built on Base UI, and projects on a `base-*` style (the default for new shadcn projects) receive them directly. Projects on a `radix-*` or legacy style receive the Radix build of the registry, which is maintained for existing customers but no longer receives new blocks. ## 3. Install Your Style For a custom style, open the Style Builder, choose your colors, fonts, type scale, radius scale, buttons, and forms, then copy the generated shadcn install command. The command uses a generated registry URL: ```bash npx shadcn@latest add "https://app.initium.sh/r/preset?code=..." ``` You can also install the base Initium style utilities: ```bash npx shadcn@latest add @initium/initium-styles ``` Install styles before blocks so classes such as `wrapper`, `tagline`, `paragraph`, `heading-xl`, and `heading-lg` are available. Rich text article blocks additionally install the `@initium/typeset` stylesheet as a dependency; import it after Tailwind in your global CSS (`@import "./typeset.css";`). ## 4. Export Your AI Assets From the Style Builder, export `DESIGN.md`. From the Strategy Builder, export `STRATEGY.md`. Place both files in your project root while you work: ```txt DESIGN.md STRATEGY.md ``` You do not have to commit these files. Treat them as working files that your AI tool can read before generating or revising UI. ## 5. Install The Initium Skill Pack If you have a license key, install the Initium skill pack: ```bash npx shadcn@latest add @initium/initium-agent ``` This installs the skill into: ```txt .agents/skills/initium/ ``` Use the skill when your AI tool supports project skills. If it does not, tell the tool to read `.agents/skills/initium/SKILL.md`. ## 6. Install Blocks Install blocks through the same registry namespace: ```bash npx shadcn@latest add @initium/hero-section-1 ``` Use the Blocks browser to choose the exact block name. Pro blocks require `INITIUM_LICENSE_KEY`. ## 7. Start A Chat With Your AI Tool Start by telling your AI tool what to read: ```txt Read DESIGN.md and STRATEGY.md from the project root. Follow the installed Initium skill if available. Use Initium blocks for major sections and keep the installed style preset intact. ``` Then ask for a specific page or section. The more specific your target audience, offer, proof, and conversion goal are, the better the result will be. ## Package Manager Notes Examples use `npx shadcn@latest`. If your project prefers another package manager, use the matching shadcn runner: ```bash pnpm dlx shadcn@latest add @initium/hero-section-1 yarn dlx shadcn@latest add @initium/hero-section-1 bunx --bun shadcn@latest add @initium/hero-section-1 ``` --- # Registry Setup Initium installs through the shadcn registry system. Before adding styles, blocks, or skills, make sure shadcn works in your project and that `components.json` knows about the Initium registry. ## Existing shadcn Projects If your project already has a `components.json` file, you can add Initium directly. Open `components.json` and add the `@initium` registry: ```json { "registries": { "@initium": { "url": "https://app.initium.sh/r/styles/{style}/{name}.json", "headers": { "Authorization": "Bearer ${INITIUM_LICENSE_KEY}" } } } } ``` Keep your existing `style`, `tailwind`, `aliases`, and other shadcn settings. Only add the `registries` entry or merge it with your existing registries. The `{style}` placeholder is filled in automatically by the shadcn CLI from your project's `style` setting. Projects on a `base-*` style (the current default) receive Base UI components; projects on a `radix-*` or legacy style (`default`, `new-york`) receive the Radix build of the registry. If you configured Initium before the Base UI transition with the older `https://app.initium.sh/r/{name}.json` URL, it keeps working and always serves the Radix build — no change required. ## New Projects If your project does not have shadcn yet, initialize shadcn first: ```bash npx shadcn@latest init ``` After shadcn creates `components.json`, add the Initium registry entry shown above. ## Free Blocks The first block of every marketing block category is free. Blocks marked with the "Free" badge in the [blocks browser](/blocks) install without a license key, together with everything they depend on (Initium styles, the media component, and placeholder logos). Copy the install command from any free block's preview card, for example: ```bash npx shadcn@latest add @initium/hero-section-1 ``` The remaining blocks in each category and all example pages are pro items and require a license key. ## License Key Free Initium items can be installed without a license key. Pro blocks and the Initium skill pack require `INITIUM_LICENSE_KEY`. For local development, set the key in your shell or in your local environment file: ```bash INITIUM_LICENSE_KEY=your_polar_license_key ``` Do not commit real license keys to your repository. ## Verify The Registry Install a free item first to verify the registry is configured correctly: ```bash npx shadcn@latest add @initium/initium-styles ``` Then install a pro item if you have a license key: ```bash npx shadcn@latest add @initium/hero-section-2 ``` If the free item works but the pro item fails with an authorization error, the registry is configured correctly and the issue is the license key. ## Install Command Variants Examples in these docs use `npx shadcn@latest`. Use your project's preferred package manager if needed: ```bash pnpm dlx shadcn@latest add @initium/initium-styles yarn dlx shadcn@latest add @initium/initium-styles bunx --bun shadcn@latest add @initium/initium-styles ``` ## What This Enables After setup, your project can install: - Custom style presets exported from the Style Builder. - Base Initium styles with `@initium/initium-styles`. - Free styled buttons and forms. - The first block of every marketing category for free, such as `@initium/hero-section-1`. - Pro blocks such as `@initium/hero-section-2`. - The Initium skill pack with `@initium/initium-agent`. --- # Styles Initium styles define the visual system your project and AI tools should follow: colors, fonts, type scale, radius scale, buttons, forms, and layout utilities. Install styles before installing blocks. Blocks can depend on shared Initium utilities such as `wrapper`, `tagline`, `paragraph`, `heading-xl`, and `heading-lg`. ## Recommended: Export A Custom Style Use the Style Builder when you want a style preset that matches your selected visual direction. 1. Open the Style Builder. 2. Choose your colors, fonts, type scale, radius scale, button style, form style, body style, and tagline style. 3. Preview the style. 4. Copy the generated shadcn command. The generated command installs from a preset URL: ```bash npx shadcn@latest add "https://app.initium.sh/r/preset?code=..." ``` The exact URL is generated by the Style Builder. Do not type or edit the `code` value by hand. ## Export DESIGN.md After choosing a style, export `DESIGN.md` from the Style Builder. Place it in your project root while you work: ```txt DESIGN.md ``` Use `DESIGN.md` as visual source material for AI tools. It tells the tool which style decisions are intentional, including colors, typography, radius, button treatment, form treatment, spacing, and overall feel. You do not have to commit `DESIGN.md`. Treat it as a working file unless your team wants to version design direction in the repository. ## Base Style Pack You can also install the base Initium style utilities: ```bash npx shadcn@latest add @initium/initium-styles ``` Use this when you want the shared utilities without relying on a custom Style Builder export. ## Typeset For Rich Text Rich text article blocks style their body content with the [shadcn typeset](https://ui.shadcn.com/docs/typeset) stylesheet. It installs automatically as a dependency of any `rich-text-section-*` block, or on its own: ```bash npx shadcn@latest add @initium/typeset ``` This adds `app/typeset.css` to your project. Import it after Tailwind in your global CSS file: ```css @import "tailwindcss"; @import "./typeset.css"; ``` Then wrap rendered HTML or markdown in the `typeset` class. The stylesheet derives from your theme tokens, so it follows your fonts and dark mode automatically, and the file is yours to edit. ## Styles Include Scales In Initium docs, "Styles" is the umbrella term. Type scale and radius scale are parts of the style system: - Type scale controls the relationship between headings, paragraphs, and supporting text. - Radius scale controls the shape language used by cards, buttons, forms, and containers. - Button and form styles control the default interactive feel of the UI. - Body and tagline styles control the texture of marketing sections. You do not install scales as separate products. They are included in the style preset you export or install. ## Before Installing Blocks Before installing a block, confirm that your style setup is in place: ```bash npx shadcn@latest add @initium/initium-styles ``` Or install your generated Style Builder preset: ```bash npx shadcn@latest add "https://app.initium.sh/r/preset?code=..." ``` Then install the block you want from the Blocks browser. --- # Blocks Initium blocks are shadcn-compatible React sections and page pieces. Install them through the `@initium` registry namespace after your project has shadcn and Initium styles configured. ## Before You Install Make sure you have: - Initialized shadcn in your project. - Added the Initium registry to `components.json`. - Installed an Initium style preset or the base style pack. - Set `INITIUM_LICENSE_KEY` if the block is a pro item. Install the base style pack if you have not installed styles yet: ```bash npx shadcn@latest add @initium/initium-styles ``` ## Install A Block Use the Blocks browser to choose the exact block name, then install it with shadcn: ```bash npx shadcn@latest add @initium/hero-section-1 ``` The CLI adds the block source code and any required dependencies to your project. Blocks are built on Base UI and delivered for your project's `style` automatically. Projects on a `base-*` style receive the current Base UI build; projects on a `radix-*` or legacy style receive the frozen Radix build, which stays available for existing customers but no longer receives new blocks. ## Free And Pro Blocks Some registry items are free. Pro blocks require a valid license key: ```bash INITIUM_LICENSE_KEY=your_polar_license_key ``` If you can install `@initium/initium-styles` but a pro block fails with an authorization error, your registry setup works and the license key needs attention. ## Install Examples ```bash npx shadcn@latest add @initium/hero-section-1 npx shadcn@latest add @initium/button-default npx shadcn@latest add @initium/form-elements-default ``` Use the Blocks browser as the source of truth for available block names. The docs show representative commands instead of duplicating the full block catalog. ## After Installing Import the installed block into your route or component and pass your real content through the supported props. Keep the installed style preset intact. If a block looks unstyled, install Initium styles first and confirm the target project is using the global CSS file configured by shadcn. --- # Skills The Initium skill pack teaches AI coding agents how to plan, write copy, choose blocks, and build pages with Initium styles and strategy files. Install it when your AI tool supports project skills or can read project-level instruction files. ## Requirements Before installing the skill pack, make sure your project has: - shadcn initialized. - The Initium registry configured in `components.json`. - `INITIUM_LICENSE_KEY` available, because the skill pack is a pro registry item. ## Install Through shadcn Install the skill pack from the Initium registry: ```bash npx shadcn@latest add @initium/initium-agent ``` The registry installs the skill into: ```txt .agents/skills/initium/ ``` The entrypoint is: ```txt .agents/skills/initium/SKILL.md ``` Supporting workflow docs are installed into: ```txt .agents/skills/initium/references/ ``` ## How To Use The Skill If your AI tool discovers project skills automatically, ask it to use the Initium skill. If the tool does not discover skills automatically, tell it: ```txt Read .agents/skills/initium/SKILL.md before changing UI code. Follow the Initium workflow for strategy, copy, block selection, implementation, and QA. ``` For best results, also place `DESIGN.md` and `STRATEGY.md` in the project root while you work. ## Manual Install Fallback Use manual install only when your project or tool cannot install through the shadcn registry. The manual install shape should match the registry output: ```txt .agents/skills/initium/SKILL.md .agents/skills/initium/references/ ``` After copying the files, tell your AI tool to read `.agents/skills/initium/SKILL.md`. Blocks and styles still install through the Initium registry. Manual skill installation does not replace shadcn setup or license requirements for pro registry items. --- # AI Workflow Initium works best when your AI tool has two sources of truth: - `DESIGN.md` for visual direction. - `STRATEGY.md` for audience, offer, positioning, and page structure. Place both files in your project root while you work. You do not have to commit them. ```txt DESIGN.md STRATEGY.md ``` ## What Each File Does `DESIGN.md` tells the AI tool how the interface should look. It captures your selected style preset, color direction, typography, type scale, radius scale, button style, form style, spacing, and overall visual rules. `STRATEGY.md` tells the AI tool what the page should communicate. It captures the business, audience, offer, pain points, proof, objections, conversion goal, and suggested structure. Use both files together. A page can look polished with only `DESIGN.md`, but it will be more generic without `STRATEGY.md`. A page can be strategically clear with only `STRATEGY.md`, but it may drift visually without `DESIGN.md`. ## Generic AI Workflow Start a new chat and ask the tool to read the files before writing code: ```txt Read DESIGN.md and STRATEGY.md from the project root. Treat them as source material for this page. Use Initium blocks for major sections. Keep the installed Initium style preset intact. Do not invent proof, testimonials, logos, metrics, awards, guarantees, or customer names. ``` Then ask for a specific outcome: ```txt Build a landing page for the primary offer in STRATEGY.md. Use installed Initium blocks where possible. Match the visual direction in DESIGN.md. Ask before filling in missing proof or claims. ``` If the Initium skill pack is installed, add: ```txt Follow .agents/skills/initium/SKILL.md before changing UI code. ``` ## Cursor Place `DESIGN.md` and `STRATEGY.md` in the project root, then ask Cursor: ```txt Read DESIGN.md, STRATEGY.md, and .agents/skills/initium/SKILL.md if it exists. Use Initium blocks and styles to build the requested page. ``` Cursor can use the installed skill when project skills are enabled. If it does not pick the skill up automatically, reference the skill path directly. ## Claude Code Ask Claude Code to read the project files explicitly: ```txt Read DESIGN.md and STRATEGY.md first. If .agents/skills/initium/SKILL.md exists, follow it as the workflow. ``` Then give it one page or section at a time. ## Codex Attach or reference `DESIGN.md` and `STRATEGY.md` at the start of the task: ```txt Use DESIGN.md for visual rules and STRATEGY.md for page strategy. Do not create UI until you have read both files. ``` If the project includes the Initium skill files, point Codex at `.agents/skills/initium/SKILL.md`. ## v0 Use `DESIGN.md` and `STRATEGY.md` as prompt context: ```txt Use the attached DESIGN.md as the visual system. Use the attached STRATEGY.md as the page brief. Generate a page that can be implemented with Initium and shadcn components. ``` When moving code back into your app, install the matching Initium styles and blocks through shadcn. ## Lovable Add `DESIGN.md` and `STRATEGY.md` as project context or paste the relevant sections into the prompt: ```txt Follow this design direction and strategy brief. Keep the page specific to the offer. Use shadcn-compatible structure and avoid unsupported claims. ``` Use the Initium registry in your code project when you install the final styles and blocks. ## Replit Add `DESIGN.md` and `STRATEGY.md` to the project root, then prompt Replit: ```txt Read DESIGN.md and STRATEGY.md from the repository. Use them before editing the UI. ``` If the skill pack is installed, ask it to read `.agents/skills/initium/SKILL.md`. ## Windsurf Place the files in the root and reference them in your first message: ```txt Use DESIGN.md as the visual source of truth. Use STRATEGY.md as the page strategy. Follow .agents/skills/initium/SKILL.md if present. ``` Keep the task narrow: one page, one section, or one revision pass per chat. ## Machine-Readable Documentation AI tools can read this documentation directly without scraping HTML: - [`/llms.txt`](https://initium.sh/llms.txt) lists every docs page with a short description. - [`/llms-full.txt`](https://initium.sh/llms-full.txt) bundles the full documentation as one markdown file. - Every docs page is available as raw markdown by appending `.md` to its URL, for example `https://initium.sh/docs/getting-started.md`. The registry catalog itself is also machine-readable: - [`https://app.initium.sh/r/registry.json`](https://app.initium.sh/r/registry.json) is the full catalog — every block, style, and preset with its name, description, categories, and tags. No authentication required. - [`https://app.initium.sh/api/registry/search?q=pricing`](https://app.initium.sh/api/registry/search?q=pricing) searches the catalog by section type, tag, or text and returns ranked JSON results with install commands. Point your agent at these URLs when it needs Initium setup or registry details that are not already in your project. ## Keep The Files Current Regenerate `DESIGN.md` when you change the visual direction in the Style Builder. Regenerate `STRATEGY.md` when the offer, audience, positioning, pricing, proof, or conversion goal changes. Start new AI chats after major changes so the tool reads the latest files instead of relying on older context. --- # Troubleshooting Most Initium setup issues come from one of five places: shadcn is not initialized, `components.json` is missing the registry, the license key is unavailable, styles were not installed before blocks, or the AI tool cannot see `DESIGN.md` and `STRATEGY.md`. ## shadcn Is Not Initialized Initium installs through shadcn. If your project does not have `components.json`, initialize shadcn first: ```bash npx shadcn@latest init ``` After initialization, add the Initium registry to `components.json`. ## The Registry Namespace Is Not Found If a command like this fails because `@initium` is unknown: ```bash npx shadcn@latest add @initium/initium-styles ``` Check that `components.json` includes the Initium registry: ```json { "registries": { "@initium": { "url": "https://app.initium.sh/r/styles/{style}/{name}.json", "headers": { "Authorization": "Bearer ${INITIUM_LICENSE_KEY}" } } } } ``` If your file already has a `registries` object, merge `@initium` into it instead of replacing other registries. ## Free Items Work But Pro Items Return 401 This usually means the registry is configured correctly, but the license key is missing or invalid. Set the key in your local environment: ```bash INITIUM_LICENSE_KEY=your_polar_license_key ``` Then retry the pro install: ```bash npx shadcn@latest add @initium/hero-section-1 ``` Do not commit real license keys to your repository. ## Installed Components Use Radix Instead Of Base UI The registry serves two builds and picks one based on the `style` in your `components.json`: - `base-*` styles (the default for new shadcn projects) receive the current Base UI build. - `radix-*` and legacy styles (`default`, `new-york`) receive the frozen Radix build, kept for existing customers. It no longer receives new blocks. - The older style-less URL `https://app.initium.sh/r/{name}.json` always serves the Radix build, so pre-existing setups keep working unchanged. If you expected Base UI components but received Radix ones, check that your `components.json` uses a `base-*` style and the `{style}` registry URL shown above. If a block exists for Base UI but the install reports it as missing, your project is likely resolving the frozen Radix build. ## Blocks Look Unstyled Install Initium styles before installing or using blocks: ```bash npx shadcn@latest add @initium/initium-styles ``` Or install the generated Style Builder preset: ```bash npx shadcn@latest add "https://app.initium.sh/r/preset?code=..." ``` Also confirm that shadcn is configured to write CSS to the global stylesheet your app actually imports. ## The Style Builder Preset URL Fails Copy the full command from the Style Builder instead of editing the URL manually. Generated preset URLs look like this: ```bash npx shadcn@latest add "https://app.initium.sh/r/preset?code=..." ``` Keep the URL quoted. The `code` value is generated and should not be changed by hand. ## AI Tool Ignores DESIGN.md Or STRATEGY.md Place the files in the project root while you work: ```txt DESIGN.md STRATEGY.md ``` Then explicitly ask the tool to read them: ```txt Read DESIGN.md and STRATEGY.md from the project root before editing UI. Use DESIGN.md for visual direction and STRATEGY.md for page strategy. ``` If you installed the Initium skill pack, also point the tool at: ```txt .agents/skills/initium/SKILL.md ``` Start a new chat after regenerating either file so the tool does not rely on old context. ## The Skill Pack Does Not Run Automatically Some AI tools do not auto-discover project skills. If the skill is installed but not used, reference it directly: ```txt Read .agents/skills/initium/SKILL.md and follow its workflow before changing UI code. ``` The skill pack should be installed at: ```txt .agents/skills/initium/ ``` If that folder is missing, reinstall the skill pack: ```bash npx shadcn@latest add @initium/initium-agent ``` The skill pack is a pro item and requires `INITIUM_LICENSE_KEY`. ## Still Stuck Verify the setup in this order: 1. `components.json` exists. 2. `components.json` includes the `@initium` registry. 3. A free item such as `@initium/initium-styles` installs. 4. `INITIUM_LICENSE_KEY` is available for pro items. 5. Initium styles are installed before blocks. 6. `DESIGN.md` and `STRATEGY.md` are in the root when using AI tools. --- # Blog # shadcn registries explained: installing blocks you own Published: 2026-08-12 · Canonical: https://initium.sh/blog/shadcn-registries-explained Almost everything written about the shadcn registry system is written for people who want to publish one. That leaves the more common situation underexplained: you found a block library, the install command starts with `npx shadcn@latest add`, and you would like to know what that command is actually about to do to your repo. This post is the consumer-side explainer. What a registry is, what happens during an install, what the `@namespace` prefix means, and why this distribution model turns out to be a good fit for coding agents. ## What is a shadcn registry? The official docs describe the registry system as a distribution system for code. A registry can distribute components, hooks, pages, config files, rules, and other files to any project, and it is not limited to React ([shadcn/ui docs](https://ui.shadcn.com/docs/registry)). Mechanically, a registry is a set of JSON files served over HTTP. There is an index (`registry.json`) that lists what the registry offers, and one JSON file per item. Each item describes itself with a name, a type (`registry:ui`, `registry:block`, and so on), the source files it carries, and the dependencies it needs. Registry authors generate these files with `npx shadcn@latest build`, which flattens the source into static JSON, typically served from `/r/` on the author's domain ([getting started guide](https://ui.shadcn.com/docs/registry/getting-started)). That is the whole infrastructure. No package server, no lockfile entries, no publish pipeline. Any URL that serves valid registry JSON is a registry, which is why the ecosystem is decentralized: shadcn/ui runs one, and so can anyone else. ## How is this different from installing an npm package? An npm package lives in `node_modules`. You import it, you don't edit it, and the maintainer controls what next week's version looks like. A registry item is the opposite: the CLI fetches the item's JSON, reads the source files inside it, and writes them into your project as plain files. A hero section lands in your components directory as a `.tsx` file you can open, rename, and rewrite. The practical consequences: - **You own the code.** There is no dependency to update or get broken by. After the install, the files are yours, versioned in your git history like everything else you wrote. - **Customization is editing, not configuration.** You change a block by changing the file. No wrapper components, no theme override APIs. - **The tradeoff is real.** There are no automatic updates. If the registry author improves a block later, you either re-add the item and reconcile it with your edits, or keep your version. If you have ever vendored a dependency deliberately, the model is familiar. Registries make vendoring the default and give it tooling. ## What happens when you run npx shadcn add? Take a concrete command: ```bash npx shadcn@latest add @initium/hero-section-1 ``` The CLI resolves the name to a URL, fetches the item JSON, and then walks its dependency tree before writing anything. Registry items declare two kinds of dependencies: - `dependencies`: npm packages the item needs, installed with your package manager as usual. - `registryDependencies`: other registry items, referenced by name (`button`) or by address on another registry (`@acme/data-table`). Dependencies can cross registries. A block on one registry can depend on a primitive from another, and the CLI sorts the whole graph so items install in the right order and files aren't written twice ([namespace docs](https://ui.shadcn.com/docs/registry/namespace)). This is why installing one hero section can legitimately bring a button, a media component, and a couple of utility files with it: the block declared them, and the CLI resolved them. Where files land is controlled by your `components.json` aliases, so a registry item written for one project layout installs cleanly into yours. ## What does the @namespace prefix mean? The `@initium` in the command above is a namespace: a shorthand you map to a URL template in your `components.json`. The `{name}` placeholder gets replaced with the item name at install time: ```json { "registries": { "@acme": "https://registry.acme.com/r/{name}.json" } } ``` With that entry, `npx shadcn@latest add @acme/button` resolves to `https://registry.acme.com/r/button.json`. Namespaces are decentralized. There is no central authority handing them out; a namespace means whatever your `components.json` says it means. Paid and private registries use the object form, which supports headers with environment variable expansion. This is how the Initium registry is configured: ```json { "registries": { "@initium": { "url": "https://app.initium.sh/r/styles/{style}/{name}.json", "headers": { "Authorization": "Bearer ${INITIUM_LICENSE_KEY}" } } } } ``` The `${INITIUM_LICENSE_KEY}` is read from your `.env.local` at install time, so the key never lives in a committed file. The same pattern covers company-internal registries behind a token. Setup details for this specific registry are in the [registry setup docs](/docs/install-shadcn-and-registry). ## How do you inspect an item before installing it? Since a registry install writes files into your repo, it is worth looking before you run `add`. The CLI ships inspection commands ([getting started guide](https://ui.shadcn.com/docs/registry/getting-started)): ```bash # what does this registry offer? npx shadcn@latest list https://registry.acme.com/r/registry.json # what exactly is in this item: files, dependencies, targets? npx shadcn@latest view @acme/login-form ``` `view` prints the item's full payload, including every file it will write and every dependency it will pull. For a registry you haven't used before, one `view` tells you more than the marketing page: how the code is structured, whether it drags in packages you don't want, and whether the author's conventions match yours. ## Why do registries work so well with agents? Registries turned out to be a natural fit for AI coding agents, for a reason worth understanding: the registry item is structured data. An agent doesn't have to scrape a docs site or guess at an import path. It can search a registry, read an item's description and dependency list, and install it with one deterministic command. shadcn/ui ships an MCP server that packages exactly this. It connects your assistant to any registry configured in `components.json`, so prompts like "find me a login form and add it" resolve through real registry data rather than the model's memory ([MCP docs](https://ui.shadcn.com/docs/mcp)). Setup for Claude Code is one command: ```bash npx shadcn@latest mcp init --client claude ``` There is a second-order effect here. Because installed blocks are plain files in your repo, the agent can also edit them after installing, and that is where quality gets decided. An agent with access to good blocks still needs rules for how to use them: which sections to combine, how much headline it may write, when to stop adding. That layer is what agent skills are for, and it's covered in [what agent skills are](/blog/what-are-agent-skills) and, end to end, in the [zero-to-website walkthrough](/blog/zero-to-full-website-with-initium). ## What to check before adopting a third-party registry A short, boring checklist, in order of importance: 1. **Read one item with `view` before installing anything.** Code quality is visible in the payload. 2. **Check the dependency footprint.** Good registry items lean on your existing stack; suspicious ones pull a package per feature. 3. **Confirm the license covers your use.** Registry items are source files in your repo, so the license question is about code ownership, not package usage. 4. **Install one free or trivial item first.** It verifies your `components.json` wiring and shows you where files land before you commit to a page's worth of blocks. Registries reward this diligence more than npm does, because whatever you install becomes code you maintain. ## Where to go from here The fastest way to make all of this concrete is to install something. The first block in every Initium marketing category is free and installs without a key, together with everything it depends on: ```bash npx shadcn@latest add @initium/hero-section-1 ``` Browse the [blocks library](/blocks) to pick one, or start from the [registry setup guide](/docs/install-shadcn-and-registry) if your `components.json` isn't wired up yet. Ten minutes of installing and reading the files that arrive will teach you more about the registry model than any explainer, this one included. --- # From zero to a full website with Initium: a walkthrough Published: 2026-08-10 · Canonical: https://initium.sh/blog/zero-to-full-website-with-initium This is the full path from an empty folder to a deployed marketing site built with Initium: a Next.js app, a style preset, real strategy files, installed blocks, and an AI coding agent that assembles the page without wrecking it. Every command below is the actual command, in the order you run it. Most walkthroughs of this kind cover the mechanics: scaffold, install, deploy. The mechanics are the easy half. The steps that decide whether the result looks designed are the ones in the middle, where you give the agent a visual direction and a page strategy before it writes any code. Those get the most attention here. ## What you need before starting Three things: - Node and a package manager. Examples use `npx`; swap in `pnpm dlx`, `yarn dlx`, or `bunx --bun` if that's your setup. - An AI coding agent, if you want one assembling the page. Claude Code, Cursor, Codex, and Windsurf all work with the same files; the [AI workflow docs](/docs/ai-workflow) have per-tool notes. - An `INITIUM_LICENSE_KEY` if you want pro blocks and the skill pack. Everything up through step 4 works without one: the style preset, base styles, `DESIGN.md`, and `STRATEGY.md` are free. ## Step 1: scaffold the app and initialize shadcn Start with a Next.js app and initialize shadcn in it: ```bash npx create-next-app@latest my-site cd my-site npx shadcn@latest init ``` `init` creates `components.json`, the file that tells the shadcn CLI how your project is wired: style, Tailwind config, path aliases. New projects default to a `base-*` style, which is what Initium's current components are built for. If you're adding Initium to an older project on a `radix-*` or legacy style, that still works; the registry serves a Radix build for those projects. ## Step 2: connect the Initium registry Add the `@initium` namespace to `components.json`: ```json { "registries": { "@initium": { "url": "https://app.initium.sh/r/styles/{style}/{name}.json", "headers": { "Authorization": "Bearer ${INITIUM_LICENSE_KEY}" } } } } ``` The `{style}` placeholder is filled in by the shadcn CLI from your project's `style` setting, so the registry serves components that match your project's component library. Keep the authorization header even if you're starting free: free installs ignore it, and pro installs start working the moment the key exists in your environment. Verify the wiring with a free item: ```bash npx shadcn@latest add @initium/initium-styles ``` If that lands, the registry is configured. If a pro item later fails with an authorization error, the problem is the license key, not the setup. ## Step 3: install a style preset before any blocks Order matters here. Blocks reference utility classes from the style layer (`wrapper`, `tagline`, `heading-xl`, `paragraph`), so the styles have to exist before the first block installs. Open the [Style Builder](https://app.initium.sh/), pick colors, fonts, type scale, radius, button and form styles, and copy the generated install command: ```bash npx shadcn@latest add "https://app.initium.sh/r/preset?code=..." ``` The preset is a one-time export into your CSS, not a runtime dependency. After installing you own the tokens and can edit them directly. The point of choosing them in the builder first is coherence: every value is picked against every other value, which is exactly what an agent improvising CSS variables per component never gives you. ## Step 4: export DESIGN.md and STRATEGY.md This is the step that most zero-to-deployed guides skip, and it's the one that determines whether the finished page reads as designed or generated. From the Style Builder, export `DESIGN.md`. From the [Strategy Builder](https://app.initium.sh/strategy), export `STRATEGY.md`. Put both in the project root: ```txt DESIGN.md STRATEGY.md ``` `DESIGN.md` captures the visual rules: the preset you chose, typography and spacing decisions, what the agent may and may not restyle. `STRATEGY.md` captures what the page has to communicate: audience, offer, pain points, real proof, objections, conversion goal, and a suggested section order. The strategy file forces a useful confrontation before any code exists: what proof do you actually have? If the honest answer is "none yet", the answer goes in the file, and the page gets built without fake logos and invented testimonials. An agent left to improvise fills silence with fabricated proof; an agent reading `STRATEGY.md` knows the proof budget is zero and structures around it. The [SaaS landing page structure post](/blog/saas-landing-page-structure) covers what that structure looks like when sections are missing their usual ingredients. You don't have to commit either file. Treat them as working inputs the agent reads at the start of every session. ## Step 5: install the skill pack With a license key, install the Initium agent skill: ```bash npx shadcn@latest add @initium/initium-agent ``` This lands in `.agents/skills/initium/`, with `SKILL.md` as the entrypoint and workflow references alongside it. Where `DESIGN.md` says what the site looks like and `STRATEGY.md` says what it argues, the skill says how the agent should work: plan first, write copy against the strategy, choose blocks to fit the argument, implement, then QA. If your tool discovers project skills automatically, it picks the skill up on its own; if not, one line in your prompt pointing at `SKILL.md` does it. The [agent skills post](/blog/what-are-agent-skills) covers how that loading mechanism works. ## Step 6: install blocks Browse the [Blocks browser](https://app.initium.sh/blocks), pick sections that fit the structure in `STRATEGY.md`, and install them by name: ```bash npx shadcn@latest add @initium/hero-section-1 ``` The CLI writes the source into your project, dependencies included. From that moment the block is your code: no wrapper package, no upstream to break you, nothing to eject from later. You can install blocks yourself or let the agent do it during the build. Installing a first block manually is worth it once, to confirm the pro path works end to end. ## Step 7: brief the agent and build the page Start a fresh chat so the agent reads current files rather than stale context. The opening brief is short: ```txt Read DESIGN.md and STRATEGY.md from the project root. Follow .agents/skills/initium/SKILL.md before changing UI code. Build the landing page for the primary offer in STRATEGY.md. Use installed Initium blocks for major sections and keep the style preset intact. Ask before filling in missing proof or claims. ``` Then work one page or section at a time. Narrow tasks keep the agent inside the constraints; "build the whole site" invites it to improvise in the gaps. The order of the previous six steps is what makes this step boring, in the good sense: the agent is assembling from a fixed palette, a fixed argument, and a fixed workflow, so its choices are selection rather than invention. When you revise, revise against the files. "Make the hero tighter per the headline rules in the skill" gets a better edit than "make it pop", because the agent has a rule to check its output against. ## Step 8: QA and deploy Before shipping, sweep for the usual failure points: every claim on the page traces to something real in `STRATEGY.md`, headlines fit their blocks at mobile widths, dark mode holds if your preset defines it, and metadata exists for every route. Deployment is standard Next.js: push to a Git host, connect the repo to your hosting platform, add `INITIUM_LICENSE_KEY` to the environment if any build step needs it, and go live. Nothing about Initium changes this part, which is the point. The output is a plain Next.js app that deploys anywhere Next.js deploys. One post-launch habit worth keeping: when the offer, audience, or proof changes, regenerate `STRATEGY.md`; when the visual direction changes, regenerate `DESIGN.md`; then start a fresh agent session. The files are only a source of truth while they're true. ## Where the time actually goes Counting commands, the whole path is roughly ten of them. The real work is in step 4, deciding what the site argues, and that work exists whether or not you do it deliberately. Skip it and the agent does it for you, badly, at generation time. Do it first and every downstream step gets easier to judge, because there's something concrete to judge against. If you want to walk this path with the docs open, [getting started](/docs/getting-started) covers the same setup with per-step troubleshooting, and the free tier (style presets, base styles, both strategy files) is enough to feel whether the workflow fits before a license key enters the picture. --- # How to structure a SaaS landing page, section by section Published: 2026-08-05 · Canonical: https://initium.sh/blog/saas-landing-page-structure Most section-order advice arrives as a list: hero, logos, features, testimonials, pricing, FAQ, CTA. The list is roughly right and almost useless, because it tells you nothing about why a section sits where it does, or what to do when your page doesn't have the ingredients the list assumes. This is the same order with the reasoning attached, plus the part that guides usually skip — how to actually assemble it, and how to know when you've added a section too many. ## What sections does a SaaS landing page need? A working default, top to bottom: 1. **Navbar** — product name, three or four links, one CTA. 2. **Hero** — what the product does, who it's for, primary action. 3. **Credibility strip** — logos, or a single stat you can actually stand behind. 4. **Problem** — the situation the reader is in before your product. 5. **How it works** — three to five steps, in the reader's order of operations. 6. **Features** — two or three sections, each carrying one benefit. 7. **Proof** — testimonials or a case study. 8. **Pricing** — or a pricing summary that links to the full page. 9. **FAQ** — the objections that survived everything above. 10. **Closing CTA** — the same action as the hero, worded the same way. 11. **Footer**. Eleven entries, but not eleven equal sections. The hero and the first two below it do the heavy lifting; the rest exists to catch readers who need more before they act. ## Why this order? The sequence is not aesthetic. It's the order in which a reader's objections arrive. Someone landing from a search result or a shared link is asking, in order: *What is this? Is it for someone like me? Do other people use it? Do you understand my problem? How does it work? What does it cost? What's the catch?* Each section answers one of those, and answering out of order costs you the reader. Pricing before "how it works" asks for a purchase decision before the reader knows what they'd be buying. Testimonials before the problem section are testimonials about a product the reader hasn't understood yet — they read as noise. The FAQ sits second-to-last because an FAQ near the top is an admission that the page above it failed. The one position worth defending in every version of this page: the closing CTA repeats the hero CTA verbatim. Same verb, same object. A reader who scrolls the whole page and finds a differently-worded action at the bottom has to re-decide what they're agreeing to. ## Where does attention actually go? The order matters more at the top than the bottom, and that's measurable rather than folkloric. Nielsen Norman Group's eyetracking analysis of over 130,000 fixations found that 57% of page-viewing time falls above the fold, and 74% falls within the first two screenfuls — with users rarely going beyond the third ([Scrolling and Attention](https://www.nngroup.com/articles/scrolling-and-attention/)). Attention past that point follows a long tail. Two consequences for structure: Your hero and the section immediately after it carry most of the page's total attention. That's where the specific claim goes — not the generic one, not the one you're saving for the features section. And the sections in your third screenful and beyond are for readers who are already interested. They're not persuading anyone from cold. That changes what belongs there: depth, specifics, objection handling — not another restatement of the value proposition in different words. ## How many sections is too many? Blocks are cheap to add, which is exactly the problem. A library of sections makes it easy to build a fourteen-section page where a seven-section page would have said the same thing. Two tests. **The distinct-claim test.** Every section must make a claim no other section makes. If you can delete a section and lose nothing but length, it was padding. Three feature sections that each say "it's fast, flexible, and easy" in different layouts are one feature section wearing three costumes. **The weight test.** Sections are not free. Largest Contentful Paint measures the render time of the largest image, text block, or video in the viewport, and the target is 2.5 seconds or less at the 75th percentile of loads ([web.dev](https://web.dev/articles/lcp)). A hero image competing with three below-the-fold images for bandwidth is a structural problem, not a tuning problem. Fewer sections above the fold, lazy-loaded media below it. Seven to nine sections covers most SaaS products. Past that, you're usually solving a copy problem by adding layout. ## What if you don't have proof yet? This is where the standard section list breaks down for early products, and where most pages go wrong in a way that's hard to recover from. The advice implicit in every landing page guide is: put logos here, put testimonials there. If you don't have customers yet, the temptation is to fill the slot anyway — placeholder logos, a composite testimonial, a metric you extrapolated. Every one of those is detectable, and being caught costs more than the empty section would have. The alternative is to change what goes in the slot rather than fake its contents. Proof doesn't have to be social: - A short demo video or an interactive sandbox is product proof. - Documentation depth is proof — a link to real docs signals a real product. - Open metrics you genuinely have (GitHub stars, downloads, changelog cadence) are proof. - Specificity is proof. A page that describes the reader's workflow precisely enough demonstrates understanding no testimonial conveys. And when none of those exist yet, delete the section. A seven-section page with nothing invented reads better than a nine-section page with two hollow ones. ## How do you assemble it from blocks? The structure above maps onto section blocks directly. In a shadcn project with the Initium registry configured, each section is one install: ```bash npx shadcn@latest add @initium/lp-navbar-1 npx shadcn@latest add @initium/hero-section-1 npx shadcn@latest add @initium/logo-section-1 npx shadcn@latest add @initium/feature-section-3 npx shadcn@latest add @initium/pricing-section-2 npx shadcn@latest add @initium/faq-section-1 npx shadcn@latest add @initium/cta-section-4 ``` The CLI writes the source into your project along with its dependencies, so the sections are yours to edit rather than a component you configure from outside. The [blocks documentation](/docs/blocks) covers registry setup and the license key for pro items; the Blocks browser is the source of truth for exact names. Two assembly notes that matter more than block choice. Pick blocks for the story, not individually. A block that looks strongest in isolation often fights the section above it — two consecutive centered sections with the same visual weight flatten into one long stretch. Alternate: centered hero, left-aligned feature, split feature, centered CTA. And size your copy to the block before you write the page. Each block has a headline length it was designed around. Copy written first and pasted in second is how you get headlines that wrap to three lines in one section and leave a gap in the next. ## How do you keep the structure once an agent edits the page? The structure survives the first build and then degrades. Someone asks a coding agent to "add a section about the new integration," and the agent adds it wherever it fits syntactically — often between the problem section and how-it-works, breaking the sequence you reasoned about. The fix is to make the structure legible to the agent instead of holding it in your head. Initium's workflow uses two files in the project root: `DESIGN.md` for visual direction and `STRATEGY.md` for audience, offer, objections, and page structure. An agent that reads both before writing code has your section order as an input rather than a pattern it has to infer from the existing markup. The [AI workflow docs](/docs/ai-workflow) cover the prompts and per-tool setup. Encoded further, this becomes an [agent skill](/blog/what-are-agent-skills) — the section-order logic, the headline budgets, and the no-invented-proof rule as instructions the agent loads whenever it touches UI code. That's the difference between a page that was structured once and a page that stays structured. If you want the blocks with those rules already attached, [getting started](/docs/getting-started) walks through registry setup and the first page. --- # Why AI-built marketing sites look generated (and how to fix it) Published: 2026-08-02 · Canonical: https://initium.sh/blog/marketing-sites-that-look-designed Every dev who has asked a coding agent for a landing page knows the result: technically fine, visually forgettable. The spacing is uneven, the headline is generic, and every section looks like it came from a different site. ## The three tells of a generated site 1. **No rhythm.** Sections stack without alternation — no zigzag, no breathing room budget. 2. **Copy sized wrong for the layout.** Headlines overflow their blocks or leave awkward gaps. 3. **Invented proof.** Fake testimonials and made-up metrics that erode trust on sight. ## What "designed" actually means A designed page follows a system: one style preset, a headline budget per block, and sections chosen for the story they tell in sequence — not for how impressive each looks alone. ```bash npx shadcn@latest add @initium/hero-section-1 ``` Initium ships that system as blocks, style presets, and agent skills — so the agent assembling your page follows the same rules a designer would. --- # What are agent skills? Design rules your agent follows Published: 2026-08-02 · Canonical: https://initium.sh/blog/what-are-agent-skills Agent skills are folders of instructions that a coding agent loads only when the task calls for them. The format is a directory with a `SKILL.md` file inside it, and that file is the whole contract — metadata at the top, instructions below. Most explanations stop at the file format. The more useful question is what belongs in a skill, and the answer is broader than "how to process a PDF": a skill is also where you put the judgment calls you keep making by hand. ## What is an agent skill, exactly? A skill is a folder containing a `SKILL.md` file with YAML frontmatter (`name` and `description`, at minimum) and markdown instructions. It can bundle anything else it needs alongside that entrypoint — scripts, reference documents, templates: ```txt my-skill/ ├── SKILL.md # required: metadata + instructions ├── references/ # optional: documentation loaded on demand ├── scripts/ # optional: executable code └── assets/ # optional: templates, resources ``` The format was developed by Anthropic and released as an [open standard](https://agentskills.io), and it is now read by a long list of agents and editors beyond Claude Code. A skill you write once is portable across the tools your team already uses. In Claude Code, where the folder lives determines who gets it. `~/.claude/skills//SKILL.md` is personal and applies to all your projects; `.claude/skills//SKILL.md` is committed to the repo and applies to that project only. The directory name becomes the command, so `.claude/skills/deploy-staging/` gives you `/deploy-staging`. ## How does an agent decide to load a skill? Through progressive disclosure, in three stages. The distinction matters because it determines what a skill costs you. **Level 1 — metadata.** At startup, the agent loads only the `name` and `description` from every available skill, roughly 100 tokens each. This is the listing it matches your request against. **Level 2 — instructions.** When a request matches a description, the agent reads `SKILL.md` from disk and its body enters context. Anthropic's guidance puts this level under 5k tokens. **Level 3 — bundled files.** Reference documents load when the instructions point to them and the task needs them. Scripts run through bash, so only their output costs tokens, never their source. The practical consequence: you can install many skills without paying for them. Until one triggers, it costs you a name and a description. A skill can bundle an entire API reference and that reference stays free until something reads it. One caveat worth knowing before you write a long skill. In Claude Code, once a skill's rendered content enters the conversation, it stays there for the rest of the session — the file is not re-read on later turns. Every line in the body is a recurring cost, not a one-time one. Write standing instructions, not a narration of steps. ## Skills or CLAUDE.md — which one holds this rule? This is the question that trips people up, and the split is cleaner than it looks. `CLAUDE.md` holds facts that are true for every session in this repo: the package manager, the test command, the directory layout, the conventions that apply whether you are fixing a typo or shipping a feature. It loads every time, so it should stay short. A skill holds a procedure. The signal that something has outgrown `CLAUDE.md` is that a section of it has turned into steps — first do this, then check that, then verify. Move it into a skill and it stops costing context on the sessions that don't need it. The failure mode of getting this wrong is quiet. Procedures pile up in `CLAUDE.md`, the file grows past what the agent reliably attends to, and the rules at the bottom stop being followed without anything reporting an error. ## What goes in the frontmatter? Two fields carry real weight, and both have limits worth knowing. ```yaml --- name: reviewing-migrations description: Reviews database migration files for reversibility, locking risk, and data loss. Use when the user adds or edits a migration, or asks to review schema changes. --- ``` `name` is capped at 64 characters and accepts lowercase letters, numbers, and hyphens only. It cannot contain the reserved words "anthropic" or "claude". Gerund form (`reviewing-migrations`, `analyzing-spreadsheets`) reads well in a listing, though noun phrases work too. `description` is capped at 1,024 characters and is the single highest-leverage line in the file. It is the only thing the agent sees when deciding whether your skill applies, so it needs to state both what the skill does *and* when to use it — including the words a person would actually type. Write it in third person: the description is injected into the system prompt, and mixing points of view ("I can help you...") degrades matching. Two symptoms map directly back to this field. A skill that never fires usually has a description missing the keywords people use. A skill that fires when you don't want it usually has a description that is too broad — narrow it, or add `disable-model-invocation: true` so it only runs when you type `/name`. Claude Code adds optional fields on top of the standard — `allowed-tools` to pre-approve tools for the invoking turn, `context: fork` to run the skill in its own subagent, `paths` to limit activation to matching files. All of them are optional. Only `description` is genuinely recommended. ## What separates a skill that works from one that doesn't? Three things, in rough order of impact. **Assume the model is already competent.** Anthropic's authoring guidance is blunt about this: only add context the agent doesn't already have. An explanation of what a PDF is, or why migrations need reversibility, is tokens spent teaching something already known. State the decision, not the background. **Match specificity to fragility.** Where several approaches are valid and context decides, give direction and let the agent choose. Where the operation is fragile and a specific sequence must hold, give the exact command and say not to vary it. The mistake is applying one register everywhere — rigid instructions for open-ended work produce brittle output, loose instructions for fragile work produce broken output. **Keep the body short and the references flat.** The recommendation is a `SKILL.md` body under 500 lines, with detail split into separate files. Keep those references one level deep from `SKILL.md` — an agent that follows a reference to a reference tends to preview files rather than read them, and preview means incomplete. ## Can a skill encode design decisions, not only capabilities? Most published skills add a capability the agent lacked: read this file format, call this API, run this deployment. That framing undersells the format. A skill can equally well constrain quality — encoding the judgment that separates output that [looks designed from output that looks generated](/blog/marketing-sites-that-look-designed). Design rules are a good fit for the format because they are procedural, they are the same every time, and they are exactly what an agent has no way to infer from your repo. A marketing page has constraints a general-purpose model will not guess at: - **A headline budget.** Every heading fits on at most two visual lines in its block. Size the copy to the budget, not the block to the copy. - **Section rhythm.** Adjacent sections alternate — text and media swap sides, centered layouts alternate with split ones — so the page reads with movement instead of monotony. - **Even measure across a row.** List and grid item descriptions stay similar in length, so text lines land evenly. - **No invented proof.** When a claim has no evidence behind it, soften the claim or ask for evidence. Never manufacture a metric or a testimonial. None of these are capabilities. They are constraints, and each one is a decision a designer would make without being asked. Written into a skill, they apply on every page the agent touches, including the ones you edit six months from now. The same reasoning extends past design. Copy rules, accessibility requirements, the sections your funnel actually needs — anything you keep correcting by hand after the agent finishes is a candidate. ## Installing a skill pack you didn't write Skills are files, which means they can ship through a registry like any other component. Initium's skill pack installs through shadcn: ```bash npx shadcn@latest add @initium/initium-agent ``` That places the entrypoint at `.agents/skills/initium/SKILL.md` with its supporting documents in `.agents/skills/initium/references/` — the progressive disclosure pattern applied to a real workflow. The entrypoint sequences the build (setup, strategy, copy, blocks, QA) with a gate at each step; the references hold the style rules, copywriting constraints, and block selection guidance that load only when that step is reached. If your agent discovers project skills automatically, it picks the pack up from there. If it doesn't, point it at the entrypoint directly: ```txt Read .agents/skills/initium/SKILL.md before changing UI code. ``` Because the format is an open standard, the same folder works whether your team is on Claude Code, Cursor, or something else — the rules travel with the repo rather than with one person's setup. The [skills documentation](/docs/skills) covers installation requirements and the manual fallback if your project can't install through the registry. --- # Changelog ## Style presets install on every shadcn framework (2026-08-12) The style preset export is no longer Next.js-only. The same install command now works across every framework the shadcn CLI supports. ## One command, six frameworks `npx shadcn@latest add ` installs your theme, button, and form components into Next.js, Vite, React Router, TanStack Start, Astro, and Laravel projects. The CLI detects the framework and puts every file where that project expects it. ## Fonts that install themselves Presets no longer ship a generated `app/layout.tsx`. Fonts are delivered as registry font items instead: - On **Next.js**, the CLI patches your existing layout in place with `next/font`, keeping your providers and classes intact. - On **every other framework**, it installs the matching fontsource package and wires `--font-sans` and `--font-heading` into your CSS. Variable fonts resolve to their variable package automatically; static fonts keep their selected weights on Next.js. ## Local fonts Local font files cannot ship through a registry, so the CLI now prints ready-to-paste `@font-face` rules and variable assignments right after install. Mixed presets still auto-install their Google font slot. Presets that default to dark mode also print a one-line note to add the `dark` class to your root element. ## Coming Soon sections and newsletter CTA blocks (2026-08-11) Eight new landing page blocks: a whole new category for pre-launch sites, and newsletter signup variants in the CTA family. ## New category: Coming Soon Sections Five sections for sites that are not live yet, from a bare placeholder to a full pre-launch page: - **`coming-soon-section-1`** (free): centered launch countdown with an email notify form. - **`coming-soon-section-2`**: minimal full-viewport placeholder with your logo, headline, and notify form. - **`coming-soon-section-3`**: split two-column layout with countdown, CTA, and image. - **`coming-soon-section-4`**: full-viewport dark hero over a background image, with countdown and notify form. - **`coming-soon-section-5`**: waitlist signup with a social links row for following progress while you build. The three countdown blocks share a **`countdown-timer`** component that installs automatically as a dependency. It ticks live, accepts a `targetDate` prop, and defaults to fourteen days from load, so demos never show an expired clock. It renders identical placeholders on server and client, avoiding hydration mismatches. ## Newsletter CTA blocks Three CTA variants built for newsletter capture, each with an email field, a Subscribe button, and a small reassurance caption below the form: - **`cta-section-8`**: centered signup on a muted background. - **`cta-section-9`**: rounded card with text beside the form. - **`cta-section-10`**: rounded card with an image column. All labels, placeholders, and the caption are props, so agents can adapt the copy without touching markup. ## Free blocks Following the first-block-free rule, `coming-soon-section-1` is free, which brings the free tier to 24 blocks: the first block of every landing page section category. The frozen Radix registry tier is unchanged. ## Installable style guide (2026-08-07) A new **Style Guide** example is available in the blocks browser, next to the other page examples. Install it into your project with `npx shadcn@latest add @initium/style-guide` and it documents your theme from the inside: - **Everything resolves live from your CSS.** Color swatches show the actual `oklch` values of every semantic token (foreground tokens preview on their paired background), the type scale table measures size, line height, weight, and tracking at the current viewport, and the radius and spacing scales report real pixel values. Change your theme and the style guide follows. - **Seven sections behind a scroll-spy sidebar**: logo (on light and dark), colors, typography, radius, layout metrics, a button variant-by-size matrix, and form controls in default, invalid, and disabled states. - **A working top bar** with your project logo, a full-text search that jumps to any token or label on the page (arrow keys included), and a theme toggle that previews your palette in both modes. - **One install, eight blocks**: the page composes a shell and seven section blocks, all pulled in automatically as registry dependencies, and every token card copies its `var(--token)` on click. The style guide follows the standard section wrapper width, so it lines up with the layout rules in the style editor preview, and in your app it simply inherits whatever theme surrounds it. ## Button text weight control (2026-08-03) The style editor gets a **Button text weight** select, right below the Buttons style picker. - **Default keeps things as they are** — each button style's built-in weights (medium, with a lighter ghost variant in some styles) stay untouched, and existing presets, share URLs, and exports are unchanged. - **Picking a weight applies it uniformly** to every button variant. The options come from the weights your selected body font actually ships, so the preview and the exported site always render a real face. - **The choice travels everywhere**: the live preview and blocks previews update immediately, the exported preset emits a `--font-button-weight` token and rewrites the button component's weight classes to use it (so it stays tweakable after install), `next/font` downloads the extra weight, and DESIGN.md documents the chosen weight for agents. ## New timeline and FAQ blocks, restructured agent skill pack (2026-07-29) Two new landing page blocks and a rework of the Initium agent skill pack. ## New blocks - **`timeline-section-5`** — a scroll-driven process timeline: a sticky intro column with CTA beside step cards on a 2px progress rail. The rail fills as the page scrolls (the fill front tracks the middle of the viewport) and each step's dot activates when the line reaches it, with dots measured against their badge so alignment holds at every breakpoint. - **`faq-section-6`** — FAQs organized into six categories. A vertical category tab list sits beside the accordion on desktop and collapses into a select on mobile, with both controls driving the same state. Each category opens with its first question expanded. ## Agent skill pack The `@initium/initium-agent` pack was restructured around a single gated workflow — setup, strategy, copy, build, QA, visuals — with a checkable completion gate per step: - The skill now carries frontmatter with trigger descriptions, so agents that auto-discover project skills can fire it on their own. - New `custom-sections.md` reference: how to build a bespoke section that passes as a registry block when no Initium block fits — shared prop names, the section skeleton, and a stock-styling-first rule for resolving conflicts between mockups and the design system. - The visuals explorator is now a standalone skill at `.agents/skills/visuals-explorator/`, so image-prompt exploration can be invoked directly as well as from the Initium workflow. - Style rules were consolidated: the headline budget (two-line headings) and zigzag rhythm (alternating section layouts) are defined once and referenced everywhere else. The frozen Radix registry tier is unchanged. ## Rich text sections now use shadcn typeset (2026-07-29) Rich text article sections are now styled by [shadcn typeset](https://ui.shadcn.com/docs/typeset), replacing the Initium `prose` utility. - A new free `typeset` registry item ships the stock shadcn typeset stylesheet as `app/typeset.css`. Import it after Tailwind in your global CSS: `@import "./typeset.css";`. - All `rich-text-section-*` blocks now declare `@initium/typeset` as a registry dependency, so installing a block brings the stylesheet with it. Their article bodies use the `typeset` class instead of `prose-block`. - The `prose` utility and `prose-block` class were removed from `initium-styles`. Existing installs keep working — the prose CSS you installed stays in your project — but re-installing styles no longer includes it. Wrap article content in `class="typeset"` going forward. - Typeset styles derive from your theme tokens and three variables (`--typeset-size`, `--typeset-leading`, `--typeset-flow`), so it follows your fonts and dark mode automatically. You own the file and can edit it freely. - The frozen Radix registry tier is unchanged. ## Style Editor preview and get-code improvements (2026-07-06) The Style Builder preview now reflects your selections more faithfully, and the get-code flow is easier to use. - The live preview picks up typography, button, and form choices immediately, so what you see is what installs. - The generated shadcn install command is easier to copy and includes your full preset configuration. - Links across preview blocks now use a consistent button-link pattern for correct semantics and focus styles. ## Base UI components and a style-aware registry (2026-07-05) Initium components are now built on Base UI, and the registry serves the right build for your project automatically. - All blocks, buttons, and form elements migrated from Radix UI primitives to Base UI. - The registry URL is now style-aware: `https://app.initium.sh/r/styles/{style}/{name}.json`. The shadcn CLI fills in `{style}` from your `components.json`, so projects on a `base-*` style receive Base UI components. - Projects on a `radix-*` or legacy style receive a frozen Radix build, and the older `https://app.initium.sh/r/{name}.json` URL keeps working unchanged, so existing installs are not affected. - The Initium agent skill and documentation were updated for Base UI and the style-aware registry. ## New initium.sh site with docs and llms.txt (2026-07-03) Initium now has a dedicated home at [initium.sh](https://initium.sh), separate from the app at [app.initium.sh](https://app.initium.sh). - Full documentation covering setup, the registry, styles, blocks, skills, AI workflows, and troubleshooting. - Machine-readable docs for AI agents: [`/llms.txt`](https://initium.sh/llms.txt), [`/llms-full.txt`](https://initium.sh/llms-full.txt), and a raw markdown version of every docs page at `/docs/{slug}.md`. - Host-based routing keeps the app, registry, and marketing site on their own domains. ## Five new style presets (2026-07-01) Five new presets landed in the Style Builder, each with its own color direction, typography pairing, and component styling. - **Wisteria** — deep purple on a warm sage background with 3D buttons. - **Grove** — a dark green, editorial direction with Lora serif headings. - **Pistachio** — light pistachio greens with playful Fredoka headings. - **Regent** — dark slate with a gold primary and Libre Caslon Display headings. - **Broadside** — Big Shoulders display headings, zero radius, and clipped buttons for louder brands. Every preset exports the same way: install it with one shadcn command, then export `DESIGN.md` so your AI tools follow the same direction. ## Skyline preset and richer style options (2026-06-25) The Style Builder gained a new preset and finer control over how styles come out. - **Skyline** — a new preset with a bright blue primary, Onest typography, 3D buttons, and pill taglines. - Border and foreground color schemes let presets control more of the interface than background and primary colors alone. - New font options and additional type sizes across presets. - Improved logo handling in style previews. ## Initium Agent skill pack (2026-06-22) The Initium Agent skill pack is now available as a pro registry item. - Install it with `npx shadcn@latest add @initium/initium-agent`. - It places a skill into `.agents/skills/initium/` with reference guides for setup, workflow, copywriting, block selection, block usage, style rules, and SEO. - Works with any AI tool that supports project skills — and any tool that can read markdown, via a pointer to `SKILL.md`. - Strategy and design markdown exports can now be downloaded directly from the app. --- # Legal # Privacy Policy This policy explains what information Initium collects when you use the marketing site at `initium.sh`, the app at `app.initium.sh` (the Style Builder, Strategy Builder, and Blocks browser), and the Initium registry, and what we do with it. The short version: Initium does not require an account, does not use tracking cookies, and collects as little as possible. Purchases are handled by Polar, our merchant of record, so we never see your payment details. ## Information We Collect **Usage analytics.** We use Vercel Analytics to understand aggregate traffic — page views, referrers, approximate location derived from IP, device and browser type. It is cookieless: it does not use cookies or persistent identifiers and does not track you across sites. **Server logs.** Like any web service, our hosting provider (Vercel) processes IP addresses and request metadata to serve pages and protect the service. Standard server logs are retained only for a short period. **Purchase information.** When you buy an Initium license, checkout is handled by [Polar](https://polar.sh), our merchant of record. Polar collects your name, email address, and payment details under [Polar's privacy policy](https://polar.sh/legal/privacy). We receive your license status and order details from Polar, never your payment card data. **License key validation.** When you install a pro item from the registry, your tooling sends your license key with the request. Our server validates it against Polar and holds a short-lived, in-memory record of the validation: a one-way hash of the key (cached for up to 15 minutes so repeat installs are fast) and a rate-limit counter keyed on IP address, hashed key, and user agent (kept for about one minute). Nothing about your installs is written to a database. **Information you send us.** If you contact us directly, we receive whatever you include in your message. ## Information We Do Not Collect - We do not require or offer user accounts, so we hold no account data. - We do not collect payment card details — Polar processes all payments. - We do not use advertising trackers, session recording, or fingerprinting. - Your Style Builder and Strategy Builder work stays in your browser (see Local Storage below) — we do not receive or store your designs or strategy content on our servers. ## Cookies and Local Storage **Cookies.** Initium does not set tracking or advertising cookies. Because we use cookieless analytics and have no login, the sites work without any cookie banner-worthy storage. **Local storage.** The app uses your browser's local storage to remember preferences and work in progress — for example your Style Builder selections, Strategy Builder drafts, theme choice, and sidebar state. This data never leaves your browser; clearing your browser storage removes it. **Shared style links.** When you share a style from the Style Builder, your selections are encoded into the link itself. Share links contain only style settings, no personal data. ## How We Use Information - To operate, secure, and improve the sites and registry. - To validate licenses and deliver pro registry items you have purchased. - To understand aggregate usage so we can prioritize improvements. - To respond when you contact us. We do not sell your information, and we do not share it with third parties except the service providers named in this policy (Vercel for hosting and analytics, Polar for payments and license management), each acting under their own privacy terms. ## Data Retention Analytics data is aggregate and not tied to you. License validation records live in server memory for minutes, not in a database. Purchase records are retained by Polar for as long as required for tax and accounting purposes. ## Your Rights Depending on where you live (for example under the GDPR or CCPA), you may have rights to access, correct, or delete personal information. Because we hold almost no personal data ourselves, most requests are best directed to Polar for purchase-related data; contact us for anything else and we will help. ## Changes to This Policy We will update this page when our practices change and revise the "last updated" date above. Significant changes will be noted in the [changelog](/changelog). ## Contact For privacy questions, reach out via email hi@shadcndesign.com. --- # Terms of Service These terms govern your use of the Initium marketing site at `initium.sh`, the app at `app.initium.sh` (the Style Builder, Strategy Builder, and Blocks browser), the Initium registry, and the products we sell (together, the "Service"). By accessing the Service, you agree to be bound by these terms and all applicable laws, and you are responsible for compliance with any applicable local laws. If you do not agree with any of these terms, do not use the Service. The short version: use the free tools as much as you like, follow the [License Agreement](/legal/license-agreement) for anything you purchase, and don't abuse the Service. ## Products and Licensing Initium sells Pro Blocks (React and Tailwind CSS components built for shadcn/ui) and Skills (instruction files for AI coding agents). Your rights to install, use, and build with these products are defined by the [License Agreement](/legal/license-agreement), which you accept when you purchase. If these terms and the License Agreement ever appear to conflict about what you may do with the products, the License Agreement controls. Style and Strategy are free tools. The `DESIGN.md` and `STRATEGY.md` files they generate from your input are yours to use, modify, and distribute without restriction. ## Purchases and Payments Purchases are processed by [Polar](https://polar.sh), our merchant of record. Polar handles checkout, payment, taxes, and receipts under [Polar's own terms](https://polar.sh/legal/terms). We never see or store your payment card details. Prices are shown at checkout and may change at any time. A purchase grants you a license as described in the License Agreement; it does not transfer ownership of the products to you. ## Refunds Because the Pro Blocks and Skills are digital products delivered immediately and cannot be returned, all sales are generally final. If something is wrong with your purchase — you were charged incorrectly, the product doesn't work as described, or you bought the wrong license — contact us within 14 days of purchase and we will make it right. Refunds are not available where a license has been revoked for breach of the License Agreement. ## License Keys Initium does not use accounts. Your license key is your proof of purchase and your access to the pro registry. You are responsible for keeping it confidential: do not share it, publish it, commit it to a public repository, or give it to people not covered by your license. We may revoke keys that are leaked, shared, or used in breach of the License Agreement. ## Ownership and Intellectual Property Initium and its licensors retain all right, title, and interest in and to the Service and the products, including all source code, design assets, components, Skills, documentation, branding, and related intellectual property rights. Purchasing a license grants you the limited rights described in the License Agreement and nothing more. You own the End Products you create, excluding the components and Skills themselves. You may not copy, scrape, or redistribute the contents of the Service except as the License Agreement allows. ## Acceptable Use You agree not to: - Attempt to gain unauthorized access to the registry, pro products, or any part of the Service, including by circumventing license validation or rate limits. - Use the Service to distribute malware, spam, or unlawful content. - Interfere with or disrupt the Service, for example by flooding it with automated requests. - Misrepresent your affiliation with Initium or use our branding without permission. ## Links to Other Websites The Service may contain links to third-party websites or services that we do not own or control, such as external documentation or tools. We have no control over, and assume no responsibility for, the content, privacy policies, or practices of any third-party sites. We recommend reading the terms and privacy policy of any site you visit. ## Termination We may suspend or terminate your access to the Service, and revoke your license as described in the License Agreement, if you breach these terms. The sections of these terms that by their nature should survive termination — including Ownership, Disclaimer, Limitation of Liability, and Governing Law — survive it. ## Disclaimer Your use of the Service and the products is at your sole risk. The Service is provided on an "AS IS" and "AS AVAILABLE" basis, without warranties of any kind, whether express or implied, including implied warranties of merchantability, fitness for a particular purpose, non-infringement, or course of performance. We do not warrant that the Service will be uninterrupted, secure, or error-free, that defects will be corrected, or that the products will meet your requirements. ## Limitation of Liability To the maximum extent permitted by law, Initium's total liability to you for any costs, damages, or other losses arising from your use of the Service or the products — including third-party claims against you — is limited to a refund of the amount you paid. In no event will we be liable for any indirect, incidental, special, consequential, or punitive damages, including lost profits, lost data, or business interruption, even if we have been advised of the possibility of such damages. ## Exclusions Some jurisdictions do not allow the exclusion of certain warranties or the limitation of liability for consequential or incidental damages, so some of the limitations above may not apply to you. In those jurisdictions, our liability is limited to the greatest extent permitted by law. ## Indemnification You agree to indemnify and hold harmless Initium from any claims, damages, or expenses (including reasonable legal fees) arising from your use of the Service or the products in violation of these terms or the License Agreement, or from the End Products you create and distribute. ## Governing Law These terms are governed by the laws of Poland, without regard to conflict of law provisions. Any disputes arising from these terms or the Service will be subject to the exclusive jurisdiction of the Polish courts. Our failure to enforce any right or provision of these terms is not a waiver of it. If any provision is held invalid, the remaining provisions remain in effect. ## Changes We reserve the right to modify or replace these terms at any time. If a revision is material, we will update the "last updated" date above and note the change in the [changelog](/changelog). By continuing to use the Service after revisions become effective, you agree to be bound by the revised terms. ## Contact Questions about these terms? Email us at hi@shadcndesign.com. --- # License Agreement Learn what you can and can't do with the Pro Blocks and Skills you get after purchasing Initium PRO. ## Summary Three rules cover almost everything below: 1. **Build anything.** Use the Pro Blocks and Skills to create unlimited websites, apps, and products for yourself or your clients, and sell them however you like. 2. **Never expose the source publicly.** The component source code must never appear in a public repository, public package registry, or anywhere third parties can extract or reuse it. This applies even inside a finished open-source application. 3. **Never turn the components into a product.** Don't repackage the Pro Blocks or Skills as a UI kit, library, registry, template, starter kit, builder, or AI generator, whether free or paid, whether modified or not. The rest of this page explains these rules in detail, with examples. ## Personal vs Team Licensing This section outlines the licensing options available and helps you determine which one fits your situation. Whether you're a solo developer, a freelancer, or part of a small product team, Initium's licensing matches how many people at your company will actually install and use the Pro Blocks and Skills. ### When to buy a Personal License? - You are the only person who will install or use the Pro Blocks and Skills, even if you build for multiple clients or projects. - You can use a Personal license inside a company or agency, as long as you remain the only person with access to the license key and the Pro Blocks/Skills files. ### When to buy a Team License? - More than one person at your company will install or use the Pro Blocks or Skills. - You need up to 5 team members to have access to the license key, the Pro Blocks code, and the Skills files. If you need more than 5 people to have access, contact us (see "Extending your license" below) and we'll put together a custom plan. ## Licensing Agreement for Pro Blocks (Code) By purchasing Initium Pro ("Item") from this website, you are granted an ongoing, non-exclusive, worldwide license to use the Pro Blocks, React and Tailwind CSS components built for shadcn/ui, under the conditions below. You may use them to create unlimited End Products for yourself or for your clients, and the End Product may be sold, licensed, sub-licensed, or freely distributed. **An End Product is:** a customized implementation of the Item, such as your unique finished website, web app, or software product, that does not allow third parties to extract or reuse the components' source code. A deployed website or compiled application qualifies, because visitors only see the rendered output. A public repository, a published package, or a product with a "view source" or code-export feature does not qualify, because the component source can be taken out of it. ### You are allowed to: - Create an End Product for a client. - Create an End Product for personal or commercial use. - Sell, license, sub-license, or distribute any number of copies of the End Product. - Modify and customize the components to fit your needs. - Combine the Item with other code and create derivative works from it. The resulting work is subject to this same license. - Use the Item multiple times, across multiple projects ("multi-use" license). - Organize the components into an internal library, private package, or private registry for your own workflow, as long as access is limited to the people covered by your license (you alone on a Personal license, up to 5 named team members on a Team license). - Let your AI coding agent (Cursor, Claude Code, Codex, v0, or similar) read, adapt, and assemble the components as part of building your End Product. ### You are NOT allowed to: - Share or distribute the source code of the Item in its original or modified form. - Include the component source code in any public repository, including open-source projects, even inside a complete, functioning application. - Publish the components to public package registries (npm, yarn, or similar), even as a package intended only for your own project, if others can install or import it. - Redistribute the Item as a starter kit, development kit, library, boilerplate, template, or shadcn registry. - Sell, resell, or distribute the components as a standalone product. - Create a website builder, app builder, page generator, or any product whose end users assemble or generate their own sites or apps from the components, whether or not the source code is exposed. This includes AI products that generate sites or apps from the components on behalf of others. - Include any feature in your End Product that lets end users view, export, or extract the component source code. - Give access to the component source code to people not covered by your license. - Create a derivative component library based on Pro Blocks for distribution. - Use our components to create and sell (or give away) your own UI kits, design systems, templates, starter kits, or component libraries, on any marketplace or channel. ### Examples of allowed usage: - Building a website, web app, or SaaS product for yourself, your company, or a client, and charging for it however you like. - Running a closed-source SaaS built with the components on top of an otherwise open-source platform or business. - Keeping the components in a private package or internal design system for your own convenience, so you can reuse them across your own projects. It must stay private: only you (Personal license) or the up to 5 team members covered by your Team license can access it. Your customers, clients, or anyone else can never install it or see its code. - Using Cursor, Claude Code, Codex, v0, or a similar AI tool to build your projects with the components. Sending the component source to these tools as part of your own development does not count as sharing or distribution. - Delivering the finished source code of a project to the client it was built for (see "Delivering work to clients" below). ### Examples of usage NOT allowed: - Publishing a public npm package that contains the components, even if it's "just for my own project," is mostly unmodified, and is never promoted as a product. If others can install it, it violates this license. - Putting an open-source application on GitHub (MIT, Apache, GPL, or any other license) with the component source code in the repository, even though the app itself is a finished product. - Creating a public shadcn registry, UI kit, template, boilerplate, or starter kit from the components, free or paid, even if modified. - Building a website builder, landing-page generator, or "describe your site and we'll generate it" AI product where end users create sites assembled from the components, even if the users never see the source code. - Adding a "download source," "export code," or "eject" feature to your product that outputs the component code. - Sharing your license key, the component files, or repository access with people not covered by your license, or participating in any form of group buy. ### Delivering work to clients Delivering the End Product's source code to the client it was built for is permitted and does not count as prohibited sharing. Your client may use, host, and modify that End Product, including with their own developers. However, your client may not extract the components from that project to use in other projects, and may not redistribute them. If your client wants to build new things with the Pro Blocks, they need their own license. ### AI agents and your responsibility You're welcome to use any AI coding tool or agent with the components, including cloud-based ones. Two things to keep in mind: - You are responsible for what your AI tools do with the components. If your agent commits the component source to a public repository, publishes it in a package, or otherwise exposes it in a way this license prohibits, that is a breach of this license by you. - An AI product or agent that you offer to others, which generates sites or apps from the components, is treated as a builder under the rules above and is not allowed. ## Licensing Agreement for Skills By purchasing Initium Pro, you are also granted a license to use Initium's Skills: `SKILL.md` and its reference files that instruct AI coding agents how to plan, style, and build with your Style, Strategy, and Blocks. This license grants an ongoing, non-exclusive, worldwide license to use the Item. You may use it to build unlimited End Products for yourself or your clients. **An End Product is:** the website, page, or application your AI agent builds while following the Skill's instructions. The Skill itself is a tool used during the build. It is not something you deliver to your end clients. ### You are allowed to: - Use the Skills to instruct any AI agent (Cursor, Claude Code, Codex, v0, or similar) on unlimited projects, for yourself or for clients. - Modify the Skill files locally to fit your own workflow. - Use the End Products the Skills help you build however you like, including selling or distributing them. ### You are NOT allowed to: - Share, publish, or redistribute the Skill files (`SKILL.md` or its references) in original or modified form, publicly or privately, outside your own licensed team. This includes committing them to any public repository or any repository shared with people not covered by your license. - Include the Skill files in work delivered to a client. Remove them (for example from `.claude/skills/` or similar agent directories) before handing over a repository. If your client wants to keep building or maintaining the project with the Skills, they need their own license. - Repackage or resell the Skills, in whole or in part, as your own "skill pack," prompt pack, template, or AI-agent product, on any marketplace or channel. - Give access to the Skill files to people not covered by your license. You are responsible for what your AI tools do with the Skill files, the same as with the Pro Blocks. If your agent commits a Skill file to a public repository or ships it inside a client deliverable, that is a breach of this license by you. ### Examples of allowed usage: - Running the Skill with Claude Code or Cursor on every client project you take on. - Editing `SKILL.md` locally so the agent follows your team's conventions. - Selling the websites and apps your agent builds while following the Skill. ### Examples of usage NOT allowed: - Committing `SKILL.md` or its reference files to a public GitHub repository, even as part of a finished project. - Handing a client a repository that still contains the Skill files. - Publishing a "prompt pack" or "agent skills bundle" that includes the Skills, original or modified, free or paid. ## Style and Strategy Style and Strategy are free and don't require a license key. The `DESIGN.md` and `STRATEGY.md` files they generate are built from your own input, so they're yours to use, modify, and distribute without restriction. ## Ownership Initium and its licensors retain all rights, title, and interest in the Pro Blocks and Skills, including the source code, design, and documentation. Purchasing a license does not transfer ownership of the components or Skills to you. You own the End Products you create, excluding the components and Skills themselves. ## Termination We may revoke your license without refund if you breach this agreement, including by sharing your license key or files with unlicensed users, publishing the components or Skills publicly, or participating in group buys. Users whose licenses are terminated for breach are not eligible to purchase again. We reserve the right to pursue DMCA takedowns and any other legal remedies available to us for unauthorized copying, sharing, or distribution of the Pro Blocks or Skills. ## Extending your license If you outgrow your Personal license and need Team access, contact us and we'll upgrade you for the difference between what you paid and the current Team price. Include: - The email address you purchased the license with. - The license you want to upgrade to. Need access for more than 5 people? Reach out the same way and we'll put together a custom plan. If you're not sure whether your use case fits this license, email us before you build. We'd rather clarify up front than debate afterwards. Contact: hi@shadcndesign.com