--- name: cluster-finds description: Batch-cluster every existing find item in src/content/find/ into 4-7 thematic 'finds' superposts. Use when the user wants to bring the find pool up to date all at once — ("re-cluster the finds", "build superposts for everything", "spread the new finds across themed posts"). For drafting one superpost from a single theme, use build-finds instead. disable-model-invocation: true --- # cluster-finds Bulk version of `build-finds`. Reads the entire `src/content/find/` pool, partitions it into themed clusters, and writes one `src/content/finds/-.mdx` superpost per cluster. The audience-facing site treats `finds` as the primary discovery vehicle for individual `find` items, so the goal is *coverage*: by the end of the run, almost every find that deserves a home should have one. Invoke from inside the `unique.rzen.dev` repo. ## Inputs - `src/content/find/*.mdx` — the full pool to cluster. - `src/content/finds/*.mdx` — already-written superposts. Their `items[]` lists are the prior clustering — read these to know which finds already have a home and what themes have been used. - Optional argument: a number of clusters to target (default: model's call, usually 4-7). - Optional argument: a list of theme phrases to seed clustering around. ## Procedure ### 1. Read the pool Read the frontmatter and body of every find. Note the `name`, `subtitle`, `topics`, `tags`, and the body's stated *virtue* (the specific thing that makes the item delightful). Tags and topics are hints, not the answer — the body usually tells you what cluster a find actually belongs to. Also read every existing finds file's `items[]` array — these are pre-clustered and should not be re-clustered into a new redundant theme. They can still be *re-used* in a new cluster if the new theme genuinely calls for them (see overlap rules). ### 2. Partition into clusters Aim for 4-7 clusters. Each cluster should: - Hang off **one specific editorial angle**, phrasable in 4-8 words ("Pocket carry", "The morning kitchen ritual", "Travel as a kind of attention"). Avoid generic buckets ("Tools", "Apps") — those are tag pages. - Hold **3-8 items**. Below 3 the grid feels thin; above 8 it stops being scannable. - Be **distinct from existing finds posts** in angle, even if a couple of items repeat. Coverage check: after partitioning, every find should appear in at least one cluster (existing or new). If a find genuinely fits no theme, leave it uncovered and report it — don't pad a cluster with a misfit. ### 3. Overlap rules Re-use is allowed but rationed. Set a soft budget: at most ~20% of items across all new posts may be repeats from existing posts or from other new posts in this same run. Concretely, for a 25-item pool, that's ~5 reuses total. Track repeats as you draft. When choosing which items to repeat: only repeat a find when the second theme genuinely illuminates a different facet of it. "It also kind of fits over here" is not enough. ### 4. Confirm with the user Before writing any files, show a compact plan: ``` Cluster A — "" (N items) - : - ... Cluster B — "" (N items) ... Overlap with existing posts: appears in + ; ... Uncovered finds: ``` Wait for the user to confirm, refine, swap, or merge clusters. Do not write files until they sign off. ### 5. Write each superpost Same file format as `build-finds`. For each cluster, write `src/content/finds/-.mdx`: ```yaml --- title: "" date: YYYY-MM-DD tags: [daily-finds, , ] description: "" blurb: "" items: - - - ... --- > ``` Body rules (same as `build-finds`): - 1-2 sentence intro paragraph in a blockquote. No headings, no list items, no numbered candidates — the grid handles the items. - Audience-facing language. Never write "today's pick", "candidates", "winners". - Vary the opening across the batch. With 4-7 posts going out the same day, repeating "Today's catch" five times feels mechanical. ### 6. Verify - Every slug in every `items[]` must exist at `src/content/find/.mdx`. Confirm before declaring done. - Run `npm run build`. If any superpost fails to compile, fix and re-run. ### 7. Update the log Append to `daily-finds.log.md`: ``` ## YYYY-MM-DD — cluster run Wrote superposts from a pool of finds. Reuses across posts: (budget: ~20%). Uncovered finds: . Posts created: - -: (N items) - <date>-<slug-B>: <title> (N items) - ... ``` ## Notes - This skill complements, doesn't replace, `build-finds`. After a cluster run, `build-finds` is still the right tool for ad-hoc, single-theme posts on top of new captures. - If two themes you're considering have heavy overlap (≥50% same items), they're really one theme — merge them and pick the stronger framing. - Date all posts with the run date, not staggered — these are siblings written together, and the home feed will sort them naturally by `title`. - Don't edit existing finds posts when running this. If an existing post overlaps with a new cluster you're proposing, either keep the new cluster (overlap-tolerated) or drop it from the plan; do not retroactively rewrite history.