rzen
9858abedc2
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.
4.1 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/<slug>.mdx, expands the body into a full review, writes src/content/reviews/<slug>.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/<slug>.mdx— the source find (must exist; abort otherwise).src/content/reviews/<slug>.mdx— must NOT exist (abort if a review with the same slug is already there; ask the user to disambiguate).
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/assets/reviews/<slug>/hero.<ext> or similar). 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>.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/<slug>.mdx frontmatter: add promotedTo: <review-slug>.
(Slug usually matches the find's slug, so promotedTo and the find's filename match.)
6. 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 superpost that references the find still renders fine; the find card on the grid remains.
7. 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.