claude-directory: A Gallery of Claude-Generated UI, and What Its prompt.md Files Are Actually For

The problem is prompt provenance, not missing components

Plenty of sites publish AI-generated landing pages. What most of them omit is the input. claude-directory keeps the input: every project folder contains a prompt.md, described in the README as "the prompt you used to generate the project, dropped in the project folder." That single convention changes what the repository is good for. You are not browsing finished components so much as a set of recorded experiments, where the generated React, Tailwind or GLSL output sits next to the instruction that produced it. The intended audience is narrow and identifiable: front-end developers and designers who already use Claude or a comparable model and want to see what a given prompt style yields before writing their own. The README frames the whole collection as a reference for "anyone exploring what Claude can build on the web," and the categories bear that out. Hero sections, landing pages, shaders, UI design systems, components, portfolios, animations and loaders, 3D and games, templates. It is a study collection with a browsable front end, not a dependency you install.

Folders, not packages: the architecture is the directory tree

There is no build system shared across the repository, no monorepo tooling described, and no published package. Projects are grouped by category, and each lives in its own folder, for example ./hero-sections/aethera-cinematic-hero/. The README states the one structural rule contributors must follow: the project has to be self-contained. Stacks vary widely inside that rule. Some folders are React, TypeScript, Vite and Tailwind CSS. Others are framework-free HTML, CSS and JavaScript, such as altitude-index-h38 and helix-vault-h55. A few reach for heavier tooling, including TanStack Start with React 19 and Vite 7 in kubric-hero-landing. The primary language reported for the repository is HTML, which is consistent with a gallery where a large share of entries are plain markup. That inconsistency is the architecture. You cannot import across folders, and nothing coordinates versions between them. Each folder is a separate small project you enter, read and copy from. The repository-level machinery is limited to the directory site and a poster generation step, not to the projects themselves.

prompt.md and demo.mp4 are the two enforced artifacts

The contribution process is deliberately informal. The README says there are no issues, no templates and no ceremony, just a pull request, and that review is handled by Claude Opus. Only two things are described as non-negotiable: the prompt file and a short screen recording named demo.mp4 showing the project working. Everything else is left open, including stack choice, as long as the project sits in its own folder. That combination is the most defensible design decision in the repository. A prompt file without a recording is unverifiable, and a recording without a prompt is just a video. Requiring both means an entry has to show the instruction and the result. The weakness is that neither artifact is machine-checked in any way the README describes. Nothing states that the recording matches the current code in the folder, and nothing states that the prompt in prompt.md is the prompt that actually produced the committed output. You are trusting the contributor on both counts, which is a reasonable trade for a casual gallery and a real gap if you intend to cite an entry as evidence of what a model can do.

Getting a project running, and the poster script

The README does not give a single install command for the repository, because there is no single project to install. The workflow it implies is: pick a category folder, open the project folder inside it, and follow whatever setup that folder needs. For the React and Vite entries, that means the usual npm install followed by a dev script, but the README does not spell this out per project, so check the folder's own files before assuming. The one command the README does give is for contributors adding a recording: node scripts/generate-posters/generate-posters.mjs. According to the README, running it after placing demo.mp4 writes a poster.jpg next to the video and updates the root posters.json manifest, which the directory uses to show a placeholder image while the video loads. The script lives under scripts/generate-posters. That is the full extent of the tooling documented at repository level. If you are evaluating an entry rather than contributing one, the poster script is irrelevant to you, and the absence of a root-level dev command is the thing to plan around.

The README tells you not to trust the code, and it means it

The warning is unusually direct for a project README: every project was generated with Claude, the repository is described as entirely vibe coded, and readers are told to review the code, check dependencies, verify accessibility and responsiveness, and run local project checks before shipping anything to production. Take that at face value. Generated hero sections are exactly the category of code where the failure modes are quiet. A layout that looks correct at one viewport, a video background with no fallback, a focus order that only makes sense visually, a dependency pulled in for a single animation. None of these break a demo recording, and all of them survive into production if nobody looks. There is also no release history retrieved for the repository, no versioning scheme and no changelog described. If you copy a folder into your codebase, you own it from that moment. There is no upstream to pull fixes from, and the next commit to that folder may be a rewrite by a different contributor with a different stack.

Where the prompts came from, and why that matters for licensing

The repository is MIT-licensed, which covers the code in the folders. The README is explicit that some prompts were inspired by or adapted from public prompt and design references, and it names them: a gist by cnemri, motionsites.ai, lafys.com, designprompts.dev, 21st.dev, superdesign.dev and landinghero.ai. That disclosure is more than most galleries offer, and it is also the part that needs your attention. An MIT licence on the repository does not automatically resolve the provenance of a design that was adapted from an external reference, and the README does not state what licence or terms apply to each source. It also does not map individual folders to individual sources. If you plan to ship something derived from an entry whose prompt was adapted, check that entry's prompt.md and trace the reference yourself. This is not a reason to avoid the repository. It is a reason to treat the licence file as covering the repository's own code and not as a blanket clearance for every design in it.

Compared with shadcn/ui, the difference is distribution

The closest familiar model for what this repository is trying to be is shadcn/ui, and one entry even names it: animated-text-rotate-hero is described as a shadcn/ui animated hero integration. The difference in approach is distribution. shadcn/ui gives you a CLI that copies components into your project with a documented registry, consistent conventions and a predictable upgrade path when the upstream component changes. claude-directory gives you folders in a git repository and a README that tells you to check the dependencies yourself. Both ask you to own the code you copy. Only one of them gives you a mechanism for getting fixes later. If what you need is a button, a dialog or a form primitive that will be maintained, this repository is the wrong tool and shadcn/ui is the right one. If what you need is to see how a cinematic hero with an HLS video background was specified and generated, this repository has no real equivalent, because that is a prompt archive rather than a component library.

Maintenance cost is per folder, and it never amortises

Because there is no shared runtime, maintenance does not scale down as the collection grows. Each folder you adopt carries its own dependency set, its own build configuration and its own upgrade obligations. The React entries pin their own versions of Vite, Tailwind and animation libraries, and the framework-free entries have effectively no upgrade surface at all until a browser change breaks them. Nothing in the README describes a policy for updating old entries when a dependency goes stale, and nothing describes a compatibility matrix. The contribution bar, prompt plus recording, also means the collection can grow faster than anyone can review it, and review is described as being done by a model. That is a reasonable filter for catching a missing prompt.md. It is not a filter for catching a subtle accessibility regression in a generated hero. Budget for reading each folder you take, not for tracking the repository as a whole.

Editorial conclusion

Adopt it if you want to study how specific prompts map to generated front-end code, or if you need a starting point for a hero section or landing page and are willing to audit the result. Do not adopt it as a component library: there is no package, no versioning, no shared runtime and no release history, so nothing here upgrades. Before using any folder, open its prompt.md to see what was asked for, then check the dependencies listed for that project, confirm the accessibility and responsive behaviour yourself, and treat the README's own warning about the code as the operating instruction rather than a formality.

Official sources

1. Issues
2. License: MIT
3. Project website
4. pulkitxm/claude-directory on GitHub
5. README