resources
Resources — overview
src/data/devsnips/docs/resources/overview.md
A resource is one leaf content folder under library/ that a consumer can identify, index, and install. This page defines the full resource model: types, hierarchy, identity, what makes a folder a resource, and the rules for adding and changing them. It is the deep reference for the resource model — the sibling pages (Components, Sections, Templates, Resource structure) go per-type and per-tech.
The three types
| Type | Meaning | Registry type value |
|---|---|---|
| Component | One focused, reusable UI pattern (button, accordion, dialog). | component |
| Section | A larger page-level composition (hero, pricing, footer, …). | section |
| Template | A complete page or multi-page site. | template |
Every type exists in every technology. Types are not interchangeable — do not upscale a component request into a template, and do not merge a section into a component. The registry carries both the Capitalized category (Components/Sections/Templates) and the lowercase type. See Agent resource selection for the consume-side boundary rules.
Hierarchy
Technology React | Tailwind | Vanilla (Capitalized on disk)
↓
Resource type Components | Sections | Templates (Capitalized on disk)
↓
Family Buttons | Hero | Pricing | … (Capitalized)
↓
Variant solid-button | hero-minimal | … (kebab-case — the resource)In the registry the same hierarchy appears as fields: family records carry tech, category (Capitalized), and type (lowercase); variant records carry their own type and path.
Layout shapes that actually exist on disk (all are valid leaves):
- 2-level component:
library/Tailwind/Components/Accordions/basic-accordion/ - 3-level component (Tailwind Buttons groups):
library/Tailwind/Components/Buttons/basic-button/primary/— thebasic-button/group folder carries its ownmetadata.json+README.mdbut is not itself a resource, because it contains leaf children. - 2-level section:
library/Tailwind/Sections/Blog/minimal/ - 3-level section (multi-concept Tailwind categories):
library/Tailwind/Sections/AI-Product/model-comparison/vercel/ - Template:
library/Tailwind/Templates/meridian/
Identity and addressing
Three equivalent forms describe the same resource:
| Form | Example | Used by |
|---|---|---|
| Registry path (tech-first, trailing slash) | React/Components/Buttons/solid-button/ |
CLI, snippets-index.json, specialized indexes |
| Filesystem path | library/React/Components/Buttons/solid-button/ |
The repository on disk; direct file access |
| Family + variant | tech React → category Components → family Buttons → variant solid-button |
Identity inside the registry |
The folder name is the canonical slug. metadata.json values (slug, name, id) are descriptive; the path is authoritative for identity. The index generator strips the library/ prefix so index paths are always tech-first and portable; the CLI adds it back when downloading (library/ + registry path + filename) and requires the first path segment to be tailwind, react, or vanilla.
What counts as a leaf (a resource)
A folder is a leaf when it has metadata.json, has no direct child folder that also has metadata.json, and shows the technology's file evidence. Grouping folders (e.g. the Tailwind Buttons groups) have metadata.json but are excluded because they contain leaf children.
The index generator and the validators use deliberately different predicates:
- Index generator (
rebuild_index.py): Tailwind requires bothcode.htmlandpreview.html; React acceptscode.tsxorpreview.html; Vanilla is anymetadata.jsonfolder without a childmetadata.json. - Validators (
validate.py,deep_check.py): Tailwind and React accept either file, so a variant missing one of the pair is reported by the required-file checks instead of being silently reclassified as a grouping folder.
Per-technology file requirements
"Required" = a failure in validate.py and/or deep_check.py. "Optional" = allowed and sometimes present.
| Tech | Type | Required | Optional / notable |
|---|---|---|---|
| React | Component | code.tsx, preview.html, metadata.json, README.md |
code.jsx parity build (missing → warning, not error) |
| React | Section | code.tsx, preview.html, metadata.json |
No README.md, no code.jsx |
| React | Template | preview.html, metadata.json, AGENTS.md |
full Vite/TS project: index.html, package.json, src/**, README.md |
| Tailwind | Component | code.html, preview.html, metadata.json, non-empty README.md |
code.html is a snippet (no DOCTYPE/CDN); preview.html is a full page |
| Tailwind | Section | code.html, preview.html, metadata.json |
README.md optional but must be non-empty when present |
| Tailwind | Template | preview.html, metadata.json, AGENTS.md |
README.md, pages/**, assets/** |
| Vanilla | Component | metadata.json |
code.html + README.md are the universal convention but not machine-enforced |
| Vanilla | Section | metadata.json |
code.html, README.md (non-empty when present) |
| Vanilla | Template | metadata.json, AGENTS.md, preview.html or non-empty pages/, plus README.md |
modular pages/, css/, js/, assets/ |
The full file contract with real examples lives in Resource structure.
Metadata
Every leaf has metadata.json. The schema is NOT uniform across technologies — that is intentional and historical. Do not invent fields; copy the shape of a sibling in the same family.
Hard rules:
typeis mandatory in every technology and must match the folder bucket (componentunderComponents/,sectionunderSections/,templateunderTemplates/).validate.pycross-checks this and fails on a mismatch.- The registry does not copy every metadata key.
rebuild_index.pyreads onlyname,description,tags,features, andstyle/stylesfor each variant, and falls back to the previous index for anything absent — so removing a curated field frommetadata.jsondoes not necessarily erase it from the index.
The per-technology field reference lives in Metadata.
The template AGENTS.md
Every template root carries a resource-level AGENTS.md — guidance for adapting that template (its structure, pages, constraints). It is:
- Required and validated —
validate.pyandrebuild_index.pyboth enforce that it exists and is non-empty. - Distinct from the repository root
AGENTS.mdand fromagents/. See AGENTS.md context files. - Installed by the CLI when it appears in the registry
filesmanifest.
Completeness and installability
A resource is complete when:
- its leaf files satisfy its tech+type requirement above;
- its
metadata.jsonis valid and has a matchingtype; - it is present in
snippets-index.json(regenerate withrebuild_index.py); validate.pypasses.
A resource is installable only if its registry files manifest contains at least one file whose extension is .html, .jsx, .tsx, .js, .ts, or .css — or a README.md/AGENTS.md. That is exactly the filter the CLI applies. metadata.json and preview.html never reach an install destination, so a resource whose only artifact is preview.html is discoverable but not installable.
Adding, modifying, removing
- Adding. Pick the tech + type, create
library/<Tech>/<Type>/<Family>/<kebab-slug>/with the required file set, copymetadata.jsonfrom a sibling, then runrebuild_index.pyandvalidate.py. Never createUtilities/,Resources/,Snippets/,Pages/, orTools/—validate.pyrejects them. - Modifying. Editing content in place does not change identity — keep the folder name and
slug. Changes toname/description/tags/features/styleflow into the index on regeneration; changingiddoes not (IDs are preserved). - Removing. Delete the leaf folder and regenerate. The generator cross-validates index↔disk and refuses to write on mismatch, so a stale entry is caught immediately. Record the reason in
CHANGELOG.mdwhen removing a published resource.
Full procedures: Creating resources.
Pages in this section
| Page | Content |
|---|---|
| Components | The component type, per technology. |
| Sections | The section type, per technology. |
| Templates | The template type, per technology. |
| Technologies | What each technology means, its conventions and limits. |
| Resource structure | The exact file contract per tech + type, with real examples. |
Go deeper
This page is the human-facing resource model. The canonical, implementation-anchored specification (with the enforcing code paths for every rule and the full per-technology metadata key sets) is maintained for agents in agents/resources/resources.md.
Related
- Registry schema — how resources appear in
snippets-index.json. - Metadata — the
metadata.jsonfield reference. - Terminology — family, variant, leaf, registry path.