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.
98 lines
4.1 KiB
Markdown
98 lines
4.1 KiB
Markdown
---
|
|
name: build-review
|
|
description: 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>".
|
|
disable-model-invocation: 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 <slug>."
|
|
|
|
### 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:
|
|
|
|
```yaml
|
|
---
|
|
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.
|