unique/.claude/skills/cluster-finds/SKILL.md

---
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/<date>-<slug>.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 — "<theme>" (N items)
  - <slug>: <name>
  - ...
Cluster B — "<theme>" (N items)
  ...

Overlap with existing posts: <slug> appears in <existing-post> + <new cluster>; ...
Uncovered finds: <list, or "none">
```

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/<YYYY-MM-DD>-<theme-slug>.mdx`:

```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 meta description.>"
blurb: "<One short editorial sentence; appears in the home feed.>"
items:
  - <slug>
  - <slug>
  - ...
---

> <One audience-facing sentence or two that names what links these finds. Vary the opening — don't reuse 'Today's catch' for every post in the run. Read like a magazine standfirst, not a checklist.>
```

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/<slug>.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 <N> superposts from a pool of <M> finds.
Reuses across posts: <count> (budget: ~20%).
Uncovered finds: <list, or "none">.

Posts created:
- <date>-<slug-A>: <title> (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.