Migrate every find from src/content/find/<slug>/ to src/content/find/<year>/<month>/<slug>/ — all 289 existing finds moved into 2026/05/. The find content-collection loader gets a new leafSlug generateId so ids (and therefore URLs at /find/<slug>/) stay flat; src/lib/find-hero.ts switches to a recursive **/hero glob. Bundle items[], promotedTo/fromFind keys, /sources cross-refs, and category/tag pages all keep working unchanged. Skill docs (daily-finds, build-review, build-bundle, cluster-bundles), README, and CHANGELOG updated for the new on-disk path. Also: 67 new finds from the 2026-05-09 capture run (Web Curios 8, MoMA 7, r/macapps 7, r/dadjokes 6, icanhazdadjoke 6, Wallpaper* Travel 5, Snow Peak 5, Kottke 3, Boutique Homes 3, etc.); felo-ergonic-screwdriver-set rolled back per editorial decision.
6.0 KiB
name, description, disable-model-invocation
| name | description | disable-model-invocation |
|---|---|---|
| build-review | Graduate a find item to a full review for unique.rzen.dev. Reads src/content/find/<year>/<month>/<slug>/index.mdx, expands the body into a full review, writes src/content/reviews/<slug>/index.mdx, and links the two via fromFind / promotedTo. Use when the user runs /build-review <slug>, says "review this find", or "graduate <slug>". | true |
build-review
Convert one captured find into a full review. Both records persist — the find stays put as the historical capture, the review becomes the canonical long-form treatment, and the two link to each other.
Invoke from inside the unique.rzen.dev repo with a find slug as the argument.
Inputs
src/content/find/<year>/<month>/<slug>/index.mdx— the source find (must exist; abort otherwise). The slug is unique across the wholefind/tree, so locate it viafind src/content/find -type d -name "<slug>"if you don't already know the year/month.src/content/reviews/<slug>/index.mdx— must NOT exist (abort if a review with the same slug is already there; ask the user to disambiguate).
Note on hero assets: the find's hero, when present, sits at src/content/find/<year>/<month>/<slug>/hero.<ext> next to its index.mdx. The review's hero goes at src/content/reviews/<slug>/hero.<ext> (flat — reviews are not date-bucketed).
Procedure
1. Read the find
Parse frontmatter. Note: name, subtitle, link, linkText, source, topics, tags, plus the body.
If promotedTo is already set, abort: "This find has already been promoted to ."
2. Suggest a hero asset
Look at the external link and propose a hero asset — a screenshot, demo gif, or product photo from the maker's site.
- Mac apps: an App Store screenshot or hero image from the developer's site.
- Physical products: the maker's product photo.
- Travel destinations: a Wikipedia or Wikimedia Commons photo (free-to-use only).
Tell the user what you'd download and where to place it (src/content/reviews/<slug>/hero.<ext> — colocated with the review's index.mdx). Pause for approval before downloading.
3. Expand the body
Take the find's 2-3 sentence body and expand it to a full review:
- Lead with a
>blockquote summary (1-2 sentences) — this renders as the accent-bordered lead per the existing review style. - 3-5 paragraphs covering: what it is, the specific problem it solves, the concrete details that make it earn its place, and any honest limitations.
- Reference the hero asset inline if downloaded (
). - Don't pad. If the find body is already complete, the review is just it + a blockquote summary + maybe one paragraph on context.
- Match the voice of existing reviews under
src/content/reviews/— informative, concise, no sales tone.
4. Write the review
File: src/content/reviews/<slug>/index.mdx.
Frontmatter:
---
name: "<from the find>"
subtitle: "<from the find — required for reviews>"
date: YYYY-MM-DD # today (the review date), not the find's date
category: <pick from existing categories or propose a new one>
tags: <merge the find's tags with any review-specific additions>
link: "<from the find>"
linkText: "<from the find, if set>"
description: "<short meta description>"
source: "<from the find>"
fromFind: "<find slug>"
---
If the find had no subtitle, generate one — it's required on reviews.
5. Update the find
Edit src/content/find/<year>/<month>/<slug>/index.mdx frontmatter: add promotedTo: <review-slug>.
(Slug usually matches the find's slug, so promotedTo and the find's filename match.)
6. Register the hero in src/lib/hero.ts (REQUIRED if a hero asset exists)
This is the step that has bitten us repeatedly. The home grid and category cards do NOT auto-discover review hero assets — they only show a hero if the review's slug is a key in the heroes record exported by src/lib/hero.ts. Skipping this step ships a review whose grid card is empty.
For a review with a static image hero (hero.png, hero.jpg, hero.webp):
- Add an
importline near the top, alphabetically grouped with the other image imports. The variable name is the slug in camelCase. Example for slugtablepro:import tablepro from '../content/reviews/tablepro/hero.png'; - Add an entry to the
heroesrecord, alphabetically by key:tablepro: { kind: 'image', src: tablepro },
For a review with a video hero (.mp4), put the import in the second (video) import group and the record entry uses kind: 'video'. Match the existing pattern.
If the review legitimately has no hero asset (rare — e.g. text-only reviews like snewpapers-newspaper-archive, sindre-sorhus-older-mac-apps), explicitly note it in the log entry from step 8 ("no hero asset — text-only review") so the omission is intentional and traceable.
7. Verify
- Run
npm run build. Confirm:/reviews/<slug>/exists, shows the source badge and "← First surfaced…" backlink to the find page./find/<slug>/shows the "→ Read the full review" callout pointing to the review.- Any bundle that references the find still renders fine; the find card on the grid remains.
- Visit
/grid/(or/) and confirm the new review's tile renders with its hero — not blank. If the tile is empty, step 6 was skipped.
8. Update the log
Append to daily-finds.log.md:
## YYYY-MM-DD — review: <slug>
Graduated from find captured on <find-date>, source: <source>.
Notes
- The find's slug and the review's slug should match. Same slug = same item across the pipeline; cross-references stay simple.
- Don't move or delete the find. Both records persist. The find is the historical capture; the review is the long-form treatment.
- Never auto-write a review without showing the user the proposed body first. This is editorial work; the skill's job is to draft, not to publish unilaterally.
- If multiple finds describe the same underlying thing, the user should consolidate them manually before running this skill.