Grove

Structured knowledge tends to get entered more than once. The same project ends up described on a website, in a README table, in a spreadsheet, and in a search snippet — each drifting from the others at its own pace.

Grove makes the file the only place that description lives. You keep YAML records, optional Markdown bodies, and taxonomy files in a git repository. One build reads them and writes a static site with search and filters, plus every derived output around it: sitemap.xml, robots.txt, JSON-LD, Open Graph images, JSON datasets, and llms-full.txt for machine readers.

There is no server, no database, and no CMS. A rename or a delete propagates to every output on the next build instead of leaving a dead page behind.

pnpm dlx @grove-dev/cli@latest init my-space
cd my-space
pnpm dev

A record is one YAML file at data/records/<slug>.yml, with an optional Markdown body at content/records/<slug>.md. The slug must match the filename.

kind: project
slug: astro
name: Astro
description: A web framework for content-driven sites.
category: frameworks
repoUrl: https://github.com/withastro/astro
stacks: [typescript, go]
platforms: [web]
difficulty: intermediate
codebaseSize: large
bestFor:
  - content sites
  - docs sites
whyListed:
  - Strong content collections model
  - First-class MDX support
caveats:
  - Newer than Next.js; smaller plugin ecosystem

name, slug, and kind are required. Everything else — category, repoUrl, stacks, platforms, difficulty, codebaseSize, bestFor, whyListed, caveats — is optional but drives the filters, the ranking, and the detail page.

From that single file the build emits a detail page, rows in every browse and filter index, a sitemap entry, JSON-LD, an OG card, a JSON dataset entry, and a line in the AI-readable text output. Writing that record once, in one place, is the entire point.

A directory is only as useful as the reasoning behind what is in it. Collections live at data/collections/<slug>.yml and pair a query with the curator's note about it.

slug: top-flutter
kind: curated
title: Top Flutter apps
description: Hand-picked Flutter projects demonstrating strong engineering
query:
  stacks: [flutter]
  categories: [productivity, finance]
  excludeStatuses: [archived]
ranking:
  preset: quality
editorial:
  selectionNote: Re-curated for the 2026 launch
  lastReviewedAt: '2026-04-01'

Query fields are ANDed — a record has to satisfy stacks, categories, licenses, minStars, and the rest at once — while array values match on any. Ranking presets are quality, active, curated, recency, and stars.

The editorial block is the part most publishing tools omit: why these entries, chosen on what basis, last checked when.

The hard part of a directory is not publishing it. It is the entry that quietly stopped being true.

grove sync github pulls repository metadata and derives a health block into data/health.yml — status, maturity, tier, visibility, cleanupCandidate, staleReason, confidence, and reasons. Status comes from measured facts, not memory:

Three further states — historical, quiet, unavailable — are editor-only, because some entries are deliberately frozen and no heuristic should overwrite that.

grove cleanup turns the derived signals into a human review queue. The machine decides what looks stale; a person still decides what to do about it.

Everything a maintainer does repeatedly is a command, so it runs in CI as easily as on a laptop.

grove import matters more than it looks: most of these sites start life as a hand-maintained Markdown list, and the first job is getting that list into records without retyping it.

The four are versioned in lockstep. The UI is deliberately not among them.

Pages and components ship as a shadcn registry. grove init installs them into the generated project as source, and records a hash for every file it wrote. grove update later diffs upstream against those hashes, so it can bring in new UI without ever overwriting a file you changed. Customising a site never means forking the pipeline.