---
name: daily-pipeline
description: The full unattended daily run for unique.rzen.dev — capture (daily-finds) → bundle (build-bundle auto) → graduate reviews (build-review auto) → set the pick of the day → build, commit, and push — ending with a digest. Use when the user runs /daily-pipeline, asks to "run the pipeline", "do the daily run", or when a scheduled/headless session needs the whole chain.
disable-model-invocation: true
---

# daily-pipeline

One command, whole day: everything from source sweep to a deployable commit, no confirmation gates. Each stage is an existing skill run in its autonomous mode — this skill is just the conductor plus the commit/digest discipline around it.

Invoke from inside the `unique.rzen.dev` repo. Requires a clean-ish working tree (uncommitted changes unrelated to the pipeline should be left untouched — stage only what each step produced).

## The chain

### 0. Preflight

- `git status` — note any pre-existing dirty files; never stage or commit them.
- Read the tail of `daily-finds.log.md` — when was the last capture run, the last weekly catch, the last cluster run.
- If today's capture run already happened (log has a `YYYY-MM-DD — capture run` entry for today), skip to step 2 rather than double-capturing.

### 1. Capture — run `daily-finds`

Follow `.claude/skills/daily-finds/SKILL.md` in full (scan → filter → write → shortlist + Amazon lookup → nominate → source maintenance → log). It runs unattended by design.

**Commit** (matching repo conventions):
`content: YYYY-MM-DD capture run — <N> finds across <M> productive sources`
Stage: the new find folders, `daily-finds.log.md`, `candidate-sources.md`, and `sources.json` if maintenance touched it.

### 2. Bundle — run `build-bundle` in auto mode

- Default: one themed bundle drawn from the unbundled shortlist pool (auto mode picks the strongest cluster itself). If the day's shortlist supports no honest theme, skip — don't force one.
- **Weekly catch check**: if no "week's catch" bundle exists for the trailing 7 days and unbundled shortlisted finds are accumulating, also run `build-bundle weekly`.
- **Backlog check**: if the unbundled pool has grown past ~25 shortlisted finds, run `cluster-bundles` in auto mode instead of a single bundle this run.

**Commit**: `site: bundle — <title>` (or `site: bundles — <t1>, <t2>` / `site: cluster run — <N> bundles`).

### 3. Reviews — run `build-review` in auto mode

- Take the capture run's **review candidates** (the top of the shortlist, marked in the log). Graduate **several per run — how many is your judgment call** (typically 2–4). Quality over cadence still rules: every graduation must clear the bar on its own, and zero is fine on a thin day. Prefer candidates with strong media and a real story; the fact-check step is mandatory.
- If today's capture was thin but a prior day's log lists ungraduated review candidates, those are fair game.

**Commit per review or combined**: `site: review — <Name> (graduates from find)` / `site: reviews — <A>, <B> (graduate from finds)`.

### 4. Pick of the day

Make an explicit pick decision **every run** — the pick is a daily editorial call, not a side effect of publishing reviews:

- Candidates: reviews graduated this run plus the existing review pool.
- "Strongest" = best hero visual + broadest audience appeal; when torn, the one whose virtue is most immediately legible from the tile.
- New reviews usually win (freshness matters on a daily site), but a weak new review must not displace a strong current hero.
- If the current hero has held for several days, lean toward rotating to another strong review even when nothing graduated — the homepage shouldn't look frozen.
- Keeping the current pick is a valid outcome, but it's a decision: say why in the digest.

Write `src/data/pick.json` → `{"hero": "<review-slug>"}`.

**Commit** (only when the pick changed): `site: pick of the day — <Name>`.

### 5. Verify + push

- `npm run build` must pass (it will also have been run by the sub-skills; this is the final gate). If it fails, fix what the pipeline broke; never push a red build.
- `git push origin main`. If the push fails (auth, network), leave the commits local and flag it in the digest.
- Deployment is automatic downstream: in scheduled runs, a lab CI job (`publish-unique-daily`) redeploys unique.rzen.dev from `main` after this pipeline succeeds — nothing to do here, but it means whatever is on `origin/main` goes live.

### 6. Digest

End with a compact, human-readable digest — this is the only thing the user should *need* to read:

```
Daily pipeline — YYYY-MM-DD

Captured:   <N> finds (<M> productive sources), shortlisted <K>
Bundle:     "<title>" (<n> items) [+ week's catch / cluster run if run]
Reviews:    <Name> (<slug>), <Name> (<slug>) — or none
Pick:       <Name> — or held: <current> (<one-line why>)
Amazon:     <n> links added
Sources:    <n> maintenance changes; <n> new nominees awaiting vetting
Attention:  <anything needing the user: rejected graduations, blocked sources,
             failed push, nominee backlog> — or "nothing"
Pushed:     yes/no (<commit range>)
```

## Ground rules

- **Never pause for input.** Every judgment call is yours; make it, log it, surface it in the digest. The user vetoes after the fact — that's the operating model.
- **Granular commits** in the repo's established message style (see `git log`), one per stage, so any stage is individually revertable.
- **Don't touch** pre-existing uncommitted changes, `src/` code, or `sources.json` beyond what daily-finds' maintenance step allows.
- **Degrade gracefully.** A stage that fails or yields nothing doesn't abort the chain — note it in the digest and continue (except a red `npm run build`, which blocks the push).
- Candidate-source vetting and adding new sources to `sources.json` stay with the user. If `candidate-sources.md` has 10+ unvetted nominees, nudge in the digest's Attention line.