← Corpus / content-farm / spec
Github Splash Page for Content Farm
An in-repo Astro site that turns the content-farm pseudomonorepo into a public landing page — hero, plugin gallery, changelog and context-v rendering — deployed for free off GitHub Pages while we wait for a real marketing surface.
- Path
- specs/Github-Splash-Page-for-Content-Farm.md
- Authors
- Michael Staton
- Augmented with
- Pi on Claude Opus 4.7 (1M context)
- Tags
- Spec · Astro-Knots · Github-Pages · Content-Farm
Github Splash Page for Content Farm
Locked decisions
- Location:
content-farm/splash/at the pseudomonorepo root. Namedsplash(notsite, notapps/<name>) to leave linguistic space for a future custom-domain marketing site without renaming this one. - Deploy URL:
https://lossless-group.github.io/content-farm/— preferred over a custom domain so external pages can point back to the GitHub Pages URL. - Build trigger: push to
main. Aligns with the development → main → master tier model: things land onmainwhen they’re noteworthy enough to publish. - Plugin gallery: hand-curated by coding agents; no algorithmic manifest pulling. Agents will edit the curated list when the plugin set changes.
- Gallery source-of-truth: an Astro content collection at
splash/src/content/plugin-highlights/*.md. One markdown file per plugin; YAML frontmatter carries the display props (title, lede, repo URL, icon, status, tags, etc.). Theorderproperty (integer) drives sort. On ties, fall back to alphabetical by filename — never throw. The body of each .md is rendered as the long-form description (LFM where applicable).
Prior art
lossless-monorepo/context-v/habits/Maintain-a-Github-Splash-Page-for-each-Repo.md— the habit this spec implements. Calls for splash + changelog + context-v rendering, with LFM.ai-labs/memopop-ai/apps/memopop-site/— first instance of the pattern. Astro + Tailwind,base: '/memopop-ai/', content collections globbing../../changelog/. LFM not yet wired in.lossless-monorepo/site/src/pages/projects/gallery/content-farm.astro— existing gallery copy. Source for hero text (“Content Farm: a Suite of Plugins for Obsidian — Streamlined content creation and data preparation for AI-powered workflows”) and the alternating-side feature pattern.
Phase 1 — what got built
Layout improvised (per “just go” direction): asymmetric 6-col grid where featured: true cards span 4 columns and others span 2; falls to single-column on narrow viewports. Hover state uses pointer-tracked radial highlight via vanilla JS — no framework.
Sections on the index: hero, plugin gallery, four-card philosophy, latest-changelog teaser (renders only when entries exist), notes CTA.
LFM punted to a follow-up. Markdown rendering uses Astro’s built-in render(entry).Content. The prose class in detail pages is the styling target where LFM-rendered components will eventually plug in. Frontmatter schema is lenient (z.preprocess) so adding LFM-specific fields later won’t break existing files.
context-v rendering scope: defaults to “everything except publish: false” — list view groups by top-level subdirectory (specs, blueprints, plans, prompts, chores, reminders, explorations, issues, habits) with a stable sort order. Files at the root of context-v/ fall into a “general” group.
Build trigger wired: .github/workflows/pages.yml at content-farm/.github/workflows/, triggered on push to main, deploys via actions/deploy-pages@v4. Submodules fetched recursively in case a future iteration surfaces plugin-level changelogs.
File layout (Phase 1)
content-farm/
├── splash/
│ ├── astro.config.mjs # base: '/content-farm/'
│ ├── package.json # astro + @astrojs/tailwind + tailwindcss
│ ├── README.md # local dev / deploy / curation notes
│ ├── tsconfig.json
│ ├── public/favicon.svg # gradient-stroked content-farm mark
│ └── src/
│ ├── content.config.ts # plugin-highlights, changelog, context-v collections
│ ├── content/plugin-highlights/
│ │ ├── image-gin.md (featured)
│ │ ├── cite-wide.md (featured)
│ │ ├── perplexed.md (featured)
│ │ ├── lmstud-yo.md
│ │ ├── grab-reference.md
│ │ ├── plunk-it.md
│ │ ├── file-transporter.md
│ │ ├── filestarter.md
│ │ └── obsidian-git.md
│ ├── layouts/BaseLayout.astro # tokens, fonts, mesh background
│ ├── components/PluginCard.astro # pointer-tracked hover, status pill
│ └── pages/
│ ├── index.astro
│ ├── changelog/index.astro
│ ├── changelog/[...slug].astro
│ ├── context-v/index.astro
│ └── context-v/[...slug].astro
└── .github/workflows/pages.yml # build splash + deploy on push to main
Phase 1 acceptance
pnpm install --ignore-workspacesucceeds (parent monorepo’s pnpm-workspace.yaml does not include content-farm; ignore-workspace flag is required)pnpm buildproduces 8 pages from current content (1 index, 1 changelog list with empty state, 1 context-v list, 5 context-v detail pages — including this spec)- All routes resolve under
/content-farm/base path
Follow-ups (for future phases)
- Content roll-up from submodules (priority). The
/changelogand/context-vlistings currently surface only content-farm’s own files. The intent is to roll up each plugin submodule’schangelog/andcontext-v/into the same feeds via the GitHub Content API at build time, with provenance on each card so a reader can filter to a specific plugin. Authenticated calls keyed off.gitmodules(url =→{owner}/{repo},branch =→ref). Token fromGITHUB_TOKENin CI, a local PAT in dev. Seepseudomonorepos/references/content-rollup.mdfor the loader sketch and failure modes. - LFM integration. Add
@lossless-group/lfmas a dep and wire the renderer for.prosecontent. Once thelfmskill ships, follow that for component-trigger syntax. - Plugin-modules pages. Optional: per-plugin detail page that aggregates the plugin’s own README + changelog (read from the submodule directory). Subsumed by roll-up if we also expose
/changelog?from=<plugin>filters. - OG image generation. Static OG card generated at build time per-page. Currently only the global one is emitted.
- Refactor candidate. This is the second instance of the splash pattern (memopop-site is the first). When a third repo wants the same thing, generalize a template — likely as an
astro-knots/sites/stub or a CLI scaffold.