Publish your own work to 21st.dev and manage it from the terminal with the `21st` CLI (`@21st-dev/cli`): publish a React component to a team library, publish a CSS theme or a template listing, edit / unpublish / delete your published items, list and reopen existing component work, and read/replace y

Publish & manage on the 21st registry Publish components, themes and templates to 21st.dev, and manage what you've already published, all through the unified 21st CLI ( @21st dev/cli ). Pre flight (always) 1. Authenticate before publishing. Component publishing, inventory, checkout, metadata editing, and unpublishing accept either a 21st login session or a 21st sk … API key. Theme/template commands still require a real API key from https://21st.dev/settings/api keys , passed via api key , TWENTYFIRST TOKEN , or API KEY 21ST . 2. The CLI is the unified @21st dev/cli (bin 21st ). Don't reinvent — use it. 3. Search before publishing ( 21st search "<query " ) so you don't add a duplicate to the library. Find existing components and drafts Start here when the user asks to continue or edit old component work: 21st components drains both independently paginated collections by default, so an unfiltered run returns every accessible personal or Team component and every owned draft. Narrow it with status all draft published private or scope all personal team:<uuid . Keep the returned stable component:<id or draft:<uuid reference; do not substitute a slug. 21st open draft:<uuid resumes an editable Studio draft. 21st open component:<id creates or resumes a server owned CLI Review revision from the retained published component code and demos. The live component stays unchanged until that revision is published. Fresh covers are required, while optional video generation runs best effort in the background. no open creates or resumes the workspace and prints its URL without launching a browser. Use a local file when the source is already changed: Never replace the stable ref with a same slug guess. Only the original component author can check out code. A Team manager can still edit or unpublish a teammate's component metadata by stable ref. Checkout fails closed when retained source, dependencies, style, support files, or the default demo cannot be reproduced safely. Use the local source command above instead of weakening the checks or claiming code access. A login session can inventory personal work and Teams the user can manage. A personal key is personal only, while a Team key is restricted to that Team. New CLI Review drafts persist their authenticated personal or Team/library scope. Legacy proof backed CLI drafts are recovered into the matching authenticated scope. An older unsigned draft whose scope cannot be proven may need to be recreated. Publish a component The positional file path triggers auto detection — name from the exported component, slug from the filename, tags from imports, and a demo that is auto found or synthesised. For a new slug or an owned revision, the command validates dependencies, installs and builds the component, creates a Studio draft, opens its dedicated CLI Review , and waits. The review sidebar shows the exact Demos (N) count and keeps the selected demo beside its live preview. Studio generates the required cover first, then attempts an optional video in the background. An owned revision stays pending until it completes the same CLI Review and is published. Decide access — default to Published User says… Flag "publish", "share a link", default for any unqualified ask (none — defaults to published ) "submit for the catalog", "get featured" Publish, then run 21st submit <slug "restrict to the team library", "keep it internal" private Publishing controls access only. Catalog featuring is always a separate review action, so publishing never silently submits the component. Flag reference Flag When to use description "…" Required , 10+ chars: what it does + when to use it. Never fabricate — read the code or ask the user. name , slug , tags a,b Override auto detected name / URL slug / 1 5 tags. demo <file Demo file. Auto found ( {Comp}.demo.tsx , demos/{slug}.tsx , demos/default.tsx ) or a trivial one is synthesised. A real demo gives a much better preview. preview <img Stage an initial cover image. It replaces the generated cover but does not bypass Studio review or the required cover gate. no open Print the Studio draft URL without opening it. The draft remains available for later review. registry ui\ hooks\ blocks\ icons Target sub registry (default ui ). to <library slug Target team library (e.g. to default ). Omit for the team's default. registry dep <ref Not supported by CLI Review yet. Remove it before creating a new component or owned revision. visibility published\ private Access (default published ). For a new slug or owned revision, the command prints the Studio draft URL and reports the component URL and install line only after Studio publishes it. Pressing <kbd Ctrl</kbd +<kbd C</kbd stops the CLI from waiting but keeps the draft. Give the demo live controls (a knobs panel visitors can play with) There is no flag for this: controls come from the demo's own code. Declare one module level settings object and let the default export take props, and the publish pipeline derives a live panel next to the preview. Visitors move the knobs and "Copy code" hands them the code with their values written back into the settings literal, so a configurable demo is worth far more than a static one. Do this for anything with tunable values — particle counts, speeds, colors, sizes, labels, feature flags. Both halves are required. Settings without props (or props without settings) gets no panel, because knobs that move nothing are worse than none. What each value becomes, with labels and ranges guessed from the value itself ( particleCount "Particle Count"): Value in settings Control number slider (integer 0..3x ; a 0..1 float ratio slider) boolean switch CSS color string ( 7dd3fc , oklch(...) ) color picker array of color strings (<= 12) editable palette other string, <= 120 chars text field nested object, mixed array, long string nothing — flatten it into top level keys instead Rules worth knowing before writing the object: at most 24 controls; keys must be plain identifiers and never key , ref , constructor , prototype , or proto ; values must be literals the pipeline can read (no imported constants, computed expressions, or spreads in the settings object); Expo / native demos get no panel at all. Inferred labels and ranges are guesses and are meant to be corrected. In CLI Review, the Controls block renders the same panel a visitor will see — check it, then rename labels and tighten min/max/step there before the final publish. Editing them never changes the values: those are always re read from the code you actually shipped. Required agent review for a new slug or owned revision The build gate catches undeclared packages, install failures, unresolved imports, and compile errors. It cannot prove that the rendered UI, interactions, or colors are visually correct. Before allowing the final publish: 1. Make the component and demo self contained. Declare every imported npm package in the nearest package.json ; do not leave unresolved local or alias imports. Confirm the CLI build succeeds before continuing. The current CLI command sends one component file and one demo; additional local files and 21st.json are not accepted yet. 2. Use portable Tailwind semantic tokens such as bg primary , text primary foreground , bg background , and border border . In custom CSS or arbitrary properties, use Tailwind v4 theme variables such as var( color primary) and var( color muted foreground) . 3. Never write oklch(var( primary)) , hsl(var( primary)) , or otherwise assume the storage format of raw variables such as primary . A project may store a channel tuple while Studio stores a complete CSS color. For opacity, use utilities such as bg primary/20 or color mix() with var( color primary) . 4. When Studio opens, use the dedicated CLI Review . Confirm its Demos (N) count, select every demo, and inspect the right side live preview. Exercise every meaningful state and verify both light and dark themes, including that the semantic primary color resolves correctly. If the demo declares settings , work the Controls panel too: every knob must visibly change the preview, and its label and range must make sense. 5. If the preview is blank, throws, has unresolved dependencies, or has wrong colors, fix the source and run 21st publish again. Do not hardcode the source project's brand color just to make the preview pass. 6. Wait for the automatically generated Cover before final publish. Cover generation has first priority and the cover remains a hard publish gate. The optional video is best effort in the background: publish never waits for it and includes it only if ready. Replace either asset manually if the generated result is not representative. Generated media is not a substitute for reviewing the live component. Updating vs a new component Inventory first. Use 21st open component:<id to create or resume a reviewed revision from the retained published code and demos. If the source is already changed locally, run 21st publish <file component component:<id instead. The current live version stays unchanged until the revision completes CLI Review and is published. If the user meant a new component but the slug collides, confirm before proceeding and suggest a different slug . Hard rules for agents Never fabricate a description or publish a file with API keys, secrets, or unsaved edits. For existing work, inventory first and use its stable ref; do not guess from a slug. Always search first, ship a useful demo (controllable via settings whenever it has tunable values), verify the build and dependencies, complete the live preview and theme token review above, and wait for the required cover before final publish. Publish a theme A theme is a CSS file that must define both a :root and a .dark block of token values. It publishes as a public community theme. To generate that CSS from the current project's design tokens instead of writing it by hand, use the 21st design sync skill. Publish a template A template is a metadata listing (URLs, not files). It lands in draft for moderation. Edit & delete your published items Notes: template

21st-registry