--- 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 — finds across 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 — ` (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 **1–2 per run** — quality over cadence; 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 - If reviews were published this run, set the strongest one as the homepage hero: write `src/data/pick.json` → `{"hero": "<review-slug>"}`. "Strongest" = best hero visual + broadest audience appeal; when torn, the one whose virtue is most immediately legible from the tile. - If no review was published, leave the pick as-is (a stale-but-good hero beats churn for its own sake). **Commit**: `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. ### 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 unchanged (<current>) 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.