general
DevSnips Content Structure Specification
src/data/devsnips/docs/COMPONENT_STRUCTURE.md
This document defines how DevSnips organizes components, sections, templates, variants, and metadata. The structure is designed so every useful piece of content can be addressed independently by the repository and the indexer.
Design goals
DevSnips treats individual variants as first-class content. A variant should be:
- independently discoverable
- independently indexable
- easy to copy and reuse
- understandable without opening unrelated files
- stable enough to receive a permanent URL later
A family groups related variants. A content type describes the size and purpose of the content.
Repository architecture
DevSnips/
├── Tailwind/
│ ├── Components/
│ ├── Sections/
│ └── Templates/
├── Vanilla/
│ ├── Components/
│ ├── Sections/
│ └── Templates/
└── React/
├── Components/
├── Sections/
└── Templates/Tailwind and Vanilla
Tailwind and Vanilla have three first-class content types:
| Directory | type |
Purpose |
|---|---|---|
Components/ |
component |
One focused reusable UI pattern. |
Sections/ |
section |
A larger page-section composition. |
Templates/ |
template |
A complete page or substantial page experience. |
Vanilla Sections/ holds the 65 neo-brutalist page sections across 16
families (Hero, Navigation, Features, Logos, Statistics, Products, Pricing,
Testimonials, Team, Process, Content, Gallery, FAQ, CTA, Contact, Footer);
Vanilla/Sections/sections-index.html and sections-showcase.html are the
browsing galleries. Vanilla Components/ keeps the legacy component
collection (including the legacy navigation sub-families).
React
React uses three content types: Components/, Sections/, and Templates/.
React component variants ship a TypeScript-first code.tsx + runnable
preview.html (+ code.jsx parity build, README.md); React section variants
ship code.tsx + preview.html; React templates are full Vite/TypeScript
projects with preview.html. React content follows the same family/variant
model, index registration, and validation as the other technologies.
Forbidden content collections
Do not create technology-level Utilities/, Resources/, Snippets/, Pages/, or Tools/ collections. If something is a reusable UI pattern, it should have an appropriate component, section, or template classification. Repository tooling belongs under scripts/tooling/.
Family and variant model
A family is a group of related UI patterns, such as Buttons, Cards, Navigation, or Pricing.
A variant is one concrete implementation inside a family, such as primary-button, icon-button, or pricing-comparison.
The preferred structure is:
<Technology>/<ContentType>/<Family>/<variant>/For example:
Tailwind/Components/Buttons/primary-button/
├── code.html
├── preview.html
├── metadata.json
└── README.mdVanilla components use a single self-contained source file:
Vanilla/Components/Buttons/3d-button-effect/
├── code.html
├── README.md
└── metadata.jsonThe directory name is the canonical component id/slug. The single primary component source file is always named code.html (inline <style> + <script>, copy-paste self-contained).
Templates are different because they may contain multiple pages and supporting files:
Tailwind/Templates/<template-slug>/
├── AGENTS.md
├── metadata.json
├── preview.html
├── README.md
└── pages/
├── index.html
└── ...Every template — Tailwind, Vanilla, and React — must ship an AGENTS.md at its root: template-specific instructions for AI coding agents working with, modifying, extending, or adapting that template. It is part of the template's DevSnips metadata layer, not installable source code. The exact internal template structure may vary when the template requires it. Do not force a multi-page template into the component three-file convention.
Standard files
| File | Required for | Purpose |
|---|---|---|
code.html |
Tailwind components/sections | Clean copy-paste implementation. |
preview.html |
Tailwind components/sections | Standalone visual preview and demonstration. |
code.html |
Vanilla components | Self-contained single primary component source file (inline CSS + JS). |
metadata.json |
Indexed variants | Structured identity, classification, search, and feature data. |
README.md |
Tailwind component variants, Vanilla components, React components, templates | Human-readable usage, customization, accessibility, and implementation notes. |
AGENTS.md |
Every template | Template-specific instructions for AI coding agents working with that template. |
preview.html is a demonstration environment. It may contain CDN imports, demo content, page framing, and preview-only JavaScript. code.html should not inherit unnecessary preview scaffolding.
AGENTS.md is required for every template under Tailwind/Templates/, React/Templates/, and Vanilla/Templates/. It explains what the template is, its structure, design system, how to safely modify it, what not to change, and the quality bar to re-check. The repository validator enforces its presence structurally — python scripts/tooling/validators/validate.py fails if a template is missing it, and python scripts/tooling/indexing/rebuild_index.py refuses to write an index for a template that lacks it.
Metadata principles
Metadata is consumed by repository tooling. It should be accurate, deterministic, and consistent with the filesystem.
A Tailwind variant must declare its content type:
{
"id": "primary-button-001",
"name": "Primary Button",
"description": "A primary call-to-action button with a clear focus state.",
"type": "component",
"category": "components",
"subcategory": "buttons",
"tags": ["button", "primary", "cta"],
"responsive": true
}The exact metadata schema used by the repository may contain additional fields. When adding fields, keep their meaning consistent across entries rather than creating one-off names.
Required consistency rules
typemust match the directory for Tailwind content.- IDs should be globally unique.
- Names and descriptions should describe the actual implementation.
- Categories and subcategories should agree with the family structure.
- Tags should be lowercase and useful for search.
- Boolean fields should use actual JSON booleans, not strings.
- Do not claim support for behavior that the code does not implement.
Naming conventions
Filesystem names and IDs should use kebab-case:
pricing-comparison
animated-accordion
multi-step-formDisplay names should be human-readable:
Pricing Comparison
Animated Accordion
Multi-Step FormAvoid generic variants such as new, test, final, or version-2.
Accessibility expectations
Accessibility is part of the component quality bar.
Prefer native HTML semantics over custom ARIA. Interactive controls should be keyboard operable, have visible focus states, and expose an understandable accessible name.
Use aria-* attributes when they add semantics that native HTML cannot provide. Do not add ARIA merely to make metadata or a validator look complete.
Animations should respect prefers-reduced-motion when motion conveys meaningful movement or transition effects.
Responsive expectations
Components should remain usable across common mobile and desktop widths. Avoid fixed widths that cause horizontal overflow and make interactive targets difficult to use on touch screens.
A responsive component does not need to look identical at every viewport. It needs to preserve its hierarchy, readability, and usability.
Design tokens
When a family uses shared design tokens, keep token definitions consistent within that family and avoid unnecessary duplication.
Tailwind's section-style component work has a dedicated token reference at:
Tailwind/Components/STYLE_TOKENS.mdDo not silently introduce a second token vocabulary for an existing family unless there is a documented reason.
Indexing model
snippets-index.json is generated from repository content and provides the global machine-readable index.
The index contains family and variant records, technology information, content types, paths, descriptions, tags, features, and aggregate statistics.
After adding, moving, renaming, or deleting content, regenerate it with:
python scripts/tooling/indexing/rebuild_index.pyThen validate the repository:
python scripts/tooling/validators/validate.pyThe validator checks architecture, metadata, index-to-disk consistency, stale paths, duplicate variant paths, and content coverage.
Migration and refactoring rules
When moving existing content:
- Preserve existing IDs unless there is a documented reason to change them.
- Update metadata to match the new location and content type.
- Regenerate the index.
- Run validation.
- Search for stale paths and references.
- Update documentation and the changelog when the repository architecture changes.
Do not perform a large migration by changing folders alone. The index and metadata are part of the same data model.
Why this structure exists
This model allows DevSnips to grow without turning every category into a large monolithic file. Each variant can eventually have its own search result, metadata, preview, analytics, and canonical URL while families still provide useful organization for humans.