unique/.claude/skills/daily-pipeline/SKILL.md

name, description, disable-model-invocation

name	description	disable-model-invocation
daily-pipeline	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.	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.