initial: four-collection content pipeline for unique.rzen.dev
A small Astro + MDX blog for delightful, daily-use finds. The architecture separates capture from publication and supports reuse: - find/ captured items, hidden from indexes - finds/ editorial superposts referencing find slugs in a grid - reviews/ full-length writeups; can graduate from a find via fromFind - posts/ regular essays Three project-local skills under .claude/skills/ drive the pipeline: daily-finds (capture-only sweep across sources.json), build-finds (draft a thematic superpost), build-review (graduate a find). sources.json carries 47 curated feeds with per-source fetch strategy (webfetch / curl / skip) so Cloudflare-blocked sites and Reddit JSON endpoints are handled deterministically. /sources renders a 3-column card stream with a "Recent finds" cross-reference per source. Seeds: 17 reviews and one superpost referencing 5 finds.
This commit is contained in:
@@ -0,0 +1,98 @@
|
||||
---
|
||||
name: build-finds
|
||||
description: Draft a 'finds' superpost (editorial roundup) for unique.rzen.dev. Selects find items from src/content/find/, groups them under a theme, and writes a new file at src/content/finds/. Use when the user runs /build-finds, asks to "draft today's finds post", "build a roundup", or "make a catch".
|
||||
disable-model-invocation: true
|
||||
---
|
||||
|
||||
# build-finds
|
||||
|
||||
Author one editorial superpost (collection: `finds`) that references existing find items. Each superpost has a theme, a short blurb, and an `items` array listing find slugs. The grid layout is rendered by the page template — this skill only writes the MDX.
|
||||
|
||||
Invoke from inside the `unique.rzen.dev` repo.
|
||||
|
||||
## Inputs
|
||||
|
||||
- `src/content/find/*.mdx` — the available pool of finds.
|
||||
- `src/content/finds/*.mdx` — existing superposts (used to detect already-referenced finds).
|
||||
- Optional argument: a theme phrase (e.g. "single-virtue tools", "things-disguised-as-other-things").
|
||||
- Optional argument: an explicit list of find slugs the user wants in the post.
|
||||
|
||||
## Procedure
|
||||
|
||||
### 1. Determine candidate pool
|
||||
|
||||
- If the user provided explicit slugs: use those.
|
||||
- If the user provided a theme phrase only: scan all finds, surface the 8–12 that best fit the theme.
|
||||
- If neither: scan recent (last ~14 days) finds that are **not yet referenced** by any existing superpost (read every `items[]` array; subtract). From the unreferenced pool, propose 1–3 thematic clusters of 5–10 finds each, with a candidate theme phrase per cluster.
|
||||
|
||||
Re-use is allowed — a find can appear in multiple superposts under different themes. But by default, prefer surfacing **unreferenced** finds first; only reach for re-uses when the theme genuinely calls for them.
|
||||
|
||||
### 2. Confirm the cluster
|
||||
|
||||
If proposing clusters, show the user:
|
||||
|
||||
```
|
||||
Cluster A — "<theme phrase>"
|
||||
- <slug>: <name>
|
||||
- <slug>: <name>
|
||||
- ...
|
||||
|
||||
Cluster B — "<theme phrase>"
|
||||
...
|
||||
```
|
||||
|
||||
Wait for the user to pick a cluster (or refine). Don't write anything until confirmed.
|
||||
|
||||
### 3. Write the superpost
|
||||
|
||||
File: `src/content/finds/<YYYY-MM-DD>-<theme-slug>.mdx` (theme-slug = kebab-case of the theme phrase, lowercase, ~30 chars max).
|
||||
|
||||
Frontmatter:
|
||||
|
||||
```yaml
|
||||
---
|
||||
title: "<Theme phrased as a noun phrase, max ~60 chars>"
|
||||
date: YYYY-MM-DD
|
||||
tags: [daily-finds, <topic-tag-1>, <topic-tag-2>]
|
||||
description: "<One-line description for meta tags. Reuse the title if nothing better.>"
|
||||
blurb: "<One short editorial sentence; appears as the post's secondary line in the home feed.>"
|
||||
items:
|
||||
- <slug>
|
||||
- <slug>
|
||||
- ...
|
||||
---
|
||||
```
|
||||
|
||||
Body: a brief audience-facing intro paragraph (1–2 sentences max) — open with "Today's catch" or a close variant; name what links these finds; vary the wording day to day. **No** numbered candidates, no headings inside the body, no list items — the grid renders from `items[]`.
|
||||
|
||||
Example body:
|
||||
|
||||
```mdx
|
||||
> Today's catch from a morning sweep across the daily feeds. Five small things, each one built around exactly one virtue — a single sound, a single diagnostic, a single disguise, a single object made, a single quiet joke.
|
||||
```
|
||||
|
||||
### 4. Verify
|
||||
|
||||
- Confirm every slug in `items[]` exists at `src/content/find/<slug>.mdx`. If any is missing, abort and report — never reference a non-existent find.
|
||||
- Run `npm run build` to confirm the new superpost compiles.
|
||||
|
||||
### 5. Update the log
|
||||
|
||||
Append to `daily-finds.log.md`:
|
||||
|
||||
```
|
||||
## YYYY-MM-DD — superpost: <theme>
|
||||
|
||||
Slug: <date>-<theme-slug>
|
||||
Items referenced:
|
||||
- <slug>
|
||||
- <slug>
|
||||
...
|
||||
```
|
||||
|
||||
## Notes
|
||||
|
||||
- Default to 5 finds per superpost. Use 3 for tighter themes, up to 8 if the theme really supports it. Beyond 8 the grid stops being scannable.
|
||||
- The body is for the audience, not the user. Never write "pick one", "candidates", "today's pick" — those are internal terms.
|
||||
- Never edit existing find files when building a superpost. The find body and metadata are stable; the superpost only references them.
|
||||
- If a find that's referenced has been graduated to a review (its frontmatter has `promotedTo`), it can still appear in the superpost — the grid card simply links to the find page, which itself links forward to the review.
|
||||
Reference in New Issue
Block a user