project-daily-lens-cron

name	project-daily-lens-cron
description	Set up a separate project-specific daily “Lens” push via Hermes cron that complements, rather than duplicates, an existing business-intelligence or newsletter digest bot. Use when the user wants a second daily push for a company/project theme with its own wiki area, schedule, and editorial boundaries.
version	1.0.0

Project Daily Lens Cron

Use this skill when a user wants a new project-specific daily push, especially when another existing bot/digest already covers adjacent content. The key is to define editorial separation before scheduling automation.

Trigger examples

• “公司已有机器人在推相关内容，但我想让你每天也推一些补充内容。”
• “不要改我原来的每日 digest，这是第二个需求。”
• “和原来的推送错开时间。”
• “先推公司项目内容，再推原来的日报。”
• “单独沉淀到 wiki，不要混进原来的 queries 目录。”

Workflow

1. Identify existing scheduled jobs first

Always inspect current cron jobs before creating a new one:

cronjob(action="list")

Look for:

• existing daily digest names and schedules
• delivery target (origin, feishu, local, etc.)
• whether an older related job is paused or active
• delivery errors

Also check live time when choosing schedules:

date '+%Y-%m-%d %H:%M:%S %Z %z'

2. Separate the new requirement from existing digests

If the user says an existing daily push should remain unchanged, explicitly preserve it. Do not alter the old cron job, prompt, output paths, or wiki structure unless asked.

Recommended split:

• Existing digest: keep original sources, format, and wiki location.
• New project Lens: create a new cron job, new prompt, new wiki folder, and separate editorial boundary.

3. Use the “complement, don’t duplicate” editorial model

When an existing company/business-intelligence bot already covers news/signals, the new daily Lens should avoid duplicating:

• daily business-intelligence ranking
• generic industry news
• “signal judgment → project impact → recommendation” structures
• broad policy/compliance summaries
• pure paper/technical summaries

Instead focus on a complementary layer such as:

• user/customer insight
• product experiment ideas
• creative/TVC/brand translation
• bilingual slogan/app copy/campaign lines
• technology-to-user-value translation
• one internal discussion question

4. Choose a schedule that avoids collisions

If the existing daily digest runs at 10:15, schedule the new project content earlier/later, e.g. 09:30, so the user receives project/company content first and the original digest later.

Use cron syntax:

30 9 * * *

If the user says “七天都推”, clarify only if necessary. A reasonable default is “every day including weekends, indefinitely” unless they explicitly say “只试跑 7 天”.

5. Create a self-contained cron prompt

Cron sessions do not retain current-chat context, so the prompt must include:

• project background
• relationship to existing bots/digests
• forbidden overlap
• required output structure
• language rules
• information-source direction
• wiki output path
• final-response requirement

Example output structure for a project Lens:

# <Project> Daily Lens｜YYYY-MM-DD

## 1. 今日用户/创意洞察
...

## 2. 产品实验
- 假设：...
- MVP：...
- 验证指标：...
- 风险：...

## 3. TVC / 品牌转化
...

## 4. 今日可用表达
English + 中文

## 5. 今日讨论问题
...

## 6. 来源
...

6. Keep wiki output separate

Do not write project-specific Lens entries into a generic newsletter queries/ root if the user wants the existing digest structure preserved.

Recommended pattern:

<canonical_vault>/wiki/<project-slug>/daily-lens/<Project>-Daily-Lens-YYYY-MM-DD.md
<canonical_vault>/wiki/<project-slug>/<Project> Daily Lens Index.md

For this user’s canonical vault, use:

/Users/leiyuxuan/Documents/PyCharm_Project/wiki/_global/wiki/<project-slug>/daily-lens/

Create a lightweight index page documenting:

• purpose and positioning
• cron name
• schedule
• relationship to existing digest
• archive location
• entries section

7. Verify after creation

After creating the cron job:

1. Run cronjob(action="list") again.
2. Confirm the new job is enabled and has the expected next_run_at.
3. Read the created index file if any.
4. In the final user message, report:
   • cron job name and ID
   • schedule
   • relationship to existing digest
   • wiki location
   • whether the interpretation is “daily indefinitely” or “7 runs only”.

8. Retrying or rerunning a Daily Lens job

If the user says “retry / 重试 / 重跑今天”, first distinguish between a normal queued cron rerun, a partial/stalled execution, and a successful overwrite.

Recommended recovery flow:

1. Inspect recent session context if needed (session_search) to identify the job ID and expected output path.
2. Check live time and current scheduler state:
   • date '+%Y-%m-%d %H:%M:%S %Z %z'
   • cronjob(action="list")
   • hermes cron status
3. Trigger the specific job by ID. If using CLI, hermes cron run <job_id> only schedules the run for the next scheduler tick; it does not mean the job has already finished. Wait past the reported Next run time, then verify again. The cronjob(action="run", job_id=<id>) tool may return only a short acknowledgement, so do not treat lack of visible output as failure.
4. Verify the rerun by evidence, not by trigger output:
   • cronjob(action="list") shows the job’s last_run_at after the trigger time, last_status=ok, and no last_delivery_error;
   • a new /Users/leiyuxuan/.hermes/sessions/session_cron_<job_id>_<YYYYMMDD>_<HHMMSS>.json exists;
   • expected archive files have modification times after the trigger;
   • the new session’s last assistant message reports the intended archive paths.
5. If the job shows last_status=ok but the expected daily archive file is missing, treat this as a partial/stalled cron execution rather than success.
6. Search the archive folder for today’s file and any previous entries.
7. If cronjob run or hermes cron run <job_id> only moves next_run_at but does not create/update the file, inspect ~/.hermes/logs/gateway.log, ~/.hermes/logs/gateway.error.log, and ~/.hermes/sessions/session_cron_<job_id>_*.json for provider timeouts or incomplete message sequences.
8. When the run is clearly stuck on provider/network issues, manually generate the Daily Lens using the same editorial structure and write it to the expected archive path. Update the project index with direct filesystem read-modify-write, not read_file display output.
   • If cronjob(action="run") sets next_run_at to an immediate/past timestamp but no new session appears, do not keep re-triggering. Check hermes cron status and hermes logs --since 10m; if the scheduler did not consume the manual run promptly, switch to manual backfill.
   • If a pre-run script prints richer JSON than what it saves to disk, use saved disk files for durable paths but reconstruct missing standard paths deterministically when safe. Example: Follow Builders saved follow-builders-context.json may not include source_index_path; derive it as _global/wiki/queries/follow-builders/sources/follow-builders-source-index-YYYY-MM-DD.md and verify the file exists.
9. Verify content quality after a style/prompt rerun:
   • the daily markdown file exists and has the correct title/date/frontmatter;
   • the requested editorial sections are actually present, e.g. for Follow Builders: Technical research lens / 技术研究视角, Product / startup lens / 产品 / 创业视角, and Cross-lens synthesis / 双视角合成;
   • the index entry is present;
   • no read_file line-number prefixes were written into generated markdown;
   • cronjob(action="update", job_id=<id>, schedule=<normal schedule>) resets next_run_at to the next normal daily run if a retry left it pointing at an already-past timestamp.

This manual fallback is appropriate because the user wants the daily content delivered, and cron/model timeouts can otherwise leave last_status=ok while no usable wiki artifact is present.

9. Source-backed builder-signal Lens pattern

When a project Lens is based on an external public feed/repository rather than ordinary web search, use a pre-run script and raw archive so the daily push remains compact but every item can be restored later.

Recommended structure:

~/.hermes/scripts/<source_slug>_context.py
<canonical_vault>/raw/<source_slug>/YYYY-MM-DD/<source_slug>-context.json
<canonical_vault>/raw/<source_slug>/YYYY-MM-DD/<source_slug>-feed-snapshot.json
<canonical_vault>/raw/<source_slug>/YYYY-MM-DD/originals/<item_id>.original.md
<canonical_vault>/wiki/queries/<source_slug>/en/<source_slug>-YYYY-MM-DD.en.md
<canonical_vault>/wiki/queries/<source_slug>/zh/<source_slug>-YYYY-MM-DD.zh.md
<canonical_vault>/wiki/queries/<source_slug>/sources/<source_slug>-source-index-YYYY-MM-DD.md

The pre-run script should:

• fetch public feeds/APIs and save an immutable raw snapshot;
• normalize source items into stable item_id, source_type, source_url, published_at, original_language, and raw_original_path fields;
• write native-language original markdown files with a restoration policy;
• emit compact context JSON for the cron prompt;
• provide a find --date YYYY-MM-DD --query '<item_id or theme>' --full mode for original restoration.

Cron prompt requirements:

• use the pre-run script’s compact JSON as the authoritative run context, then write fresh editorial prose from it;
• write bilingual archives separately (en/ and zh/), not as one long mixed file;
• keep push delivery short: summary + filesystem paths, not full content;
• preserve native originals unchanged and translate only the counterpart version, with faithful/fluent/elegant quality (信达雅);
• update _global/index.md, _global/log.md, and any operations map with direct read-modify-write.

Verification checklist after creation or a manual run:

1. cronjob(action="list") shows the job enabled with expected schedule, delivery target, script, and last_status=ok after a test run.
2. English and Chinese daily archive files exist.
3. Source index exists and includes the restore command plus raw_original paths.
4. Raw context JSON, raw feed snapshot JSON, and per-item .original.md files exist.
5. context.item_count, len(context.items), and raw original count match unless intentionally limited.
6. Every context item has raw_original_path.
7. _global/index.md and _global/log.md contain the new source entry.
8. Run python3 -m py_compile ~/.hermes/scripts/<source_slug>_context.py.
9. Check generated markdown does not contain read_file line-number prefixes such as 12|... accidentally copied into files.
10. If writing sha256 in frontmatter, hash only the body after frontmatter or clearly define the hash target; then verify hashes after rewriting files.
11. Collapse titles/excerpts to one line before putting source text into markdown headings or list items; raw feed text often contains newlines that can break indexes.

Concrete Follow Builders setup:

Follow Builders Feishu docs must match the “AI 内容结构化阅读版” outline style, not a loose separate layout. Use actual Feishu H1/H2/H3 blocks with this directory structure:

• H1 1. 今日总览; H2 1.1 一句话结论, 1.2 三条主线, 1.3 今天建议阅读顺序

• H1 2. 技术研究视角; H2 2.1 核心判断, then technical themes with H3 信号来源 / 技术要点 / Hermes 判断

• H1 3. 产品 / 创业视角; H2 3.1 核心判断, product themes, and 3.4 双视角合成

• H1 4. 来源 attribution; each retained source has source title/account or podcast/blog, URL, raw_original path, why retained, Hermes interpretation

• H1 5. 跟进动作与归档; H2 5.1 建议跟进, 5.2 归档路径 If the day has few sources, keep the outline but do not pad with generic news. Do not insert extra numbered sections that violate the exact outline ordering, e.g. avoid adding 3.5 ... before 3.4 双视角合成. If there are more product themes than the template slots, combine related product themes under 3.3, put secondary themes in 4. 来源 attribution, or mention them inside 3.4 双视角合成 rather than creating out-of-order headings.

• Job: follow-builders-daily-lens.

• Job ID observed on this machine: 89d16900a4b5.

• Schedule: 45 10 * * *.

• Delivery: feishu.

• Script: /Users/leiyuxuan/.hermes/scripts/follow_builders_context.py.

• Archives: /Users/leiyuxuan/Documents/PyCharm_Project/wiki/_global/wiki/queries/follow-builders/{en,zh,sources}/.

• Raw originals: /Users/leiyuxuan/Documents/PyCharm_Project/wiki/_global/raw/follow-builders/YYYY-MM-DD/.

• Required editorial detail: show explicit source attribution for each signal, especially in Feishu documents: who said it / which account or podcast / source URL or raw_original path / how Hermes interpreted it. Do not present Follow Builders claims as unattributed generic conclusions.

Manual execution from pre-run script output

When a scheduled Daily Lens run provides compact pre-run script JSON directly in the prompt, do not rerun fetching unless verification fails. Treat that JSON as the authoritative run context and use the date, items, source_index_path, context_path, and snapshot_path fields to write the day’s archives.

For Follow Builders specifically:

1. Orient in _global first. On this vault, SCHEMA.md may be absent; use _global/purpose.md, _global/index.md, recent _global/log.md, plus review-queue.md / contradictions.md if present instead of blocking.
2. Read the existing source index and selected high-signal raw originals, especially the long podcast transcript and any X posts that will be cited.
3. Use the previous day’s Follow Builders EN/ZH files as a style/structure reference, but keep the new day’s synthesis independent.
4. Write both required archives directly:
   • wiki/queries/follow-builders/en/follow-builders-YYYY-MM-DD.en.md
   • wiki/queries/follow-builders/zh/follow-builders-YYYY-MM-DD.zh.md
5. Keep the English and Chinese files standalone rather than sentence-by-sentence translations. Both must include source map, generatedAt timestamps, script errors, technical research lens, product/startup lens, cross-lens synthesis, and source notes with item_id, source URL, and raw_original_path.
6. Update _global/index.md with the EN/ZH/source-index links for that date only if absent; keep wiki/queries/ root sparse by linking under follow-builders/{en,zh,sources}.
7. Append _global/log.md with the archive paths, source index, raw archive/context paths, item counts, generatedAt timestamps, errors, and the note that this remains separate from daily-newsletter-digest.
8. Verify by reading the new file headers/sections and searching for the date’s index links. Also search generated files for unresolved template fragments such as {cite or {items} and for accidental read_file line-number prefixes.
9. In cron final responses, do not call send_message; return a short Chinese summary with only the top 3 themes and archive/source-index paths. If nothing useful exists, obey the prompt’s [SILENT] rule exactly.

Feishu document delivery pattern

When the user wants daily pushes as Feishu documents rather than long Feishu messages, use a two-layer delivery model:

If the user says Feishu documents are too rough or some documents did not “land”, run a remediation audit before changing schedules:

1. Check cronjob(action="list") for relevant daily/weekly jobs and delivery targets.

2. Search the canonical wiki for today’s archive files and feishu_doc: frontmatter/body links.

3. Inspect recent cron session final messages for doc links; a job may have sent only a short Feishu message while never creating a docx.

4. For any existing wiki archive without a Feishu doc, create a Chinese-only backfill docx from the archive, verify child blocks through the docx API, add feishu_doc: <url> to the Chinese archive, append _global/log.md, and send one short Feishu notice with the backfill links.

5. Update the cron prompt so future runs explicitly create docx documents, not only final chat messages.

6. Distinguish Hugging Face weekly roundup from Hugging Face Daily Papers. If the user asks for daily Hugging Face articles, create or enable a separate daily job instead of silently relying on the weekly Friday job.

7. Wiki remains the durable knowledge/archive layer:

   • Keep existing markdown archives, raw snapshots, source indexes, and log/index updates.
   • English and Chinese archives may both exist in wiki.

8. Feishu becomes the Chinese-only reading layer:

   • Create a new docx document for each daily/weekly push.
   • Write only Chinese prose into the Feishu document. Keep English paper titles, names, product names, and technical terms when needed, but explain in Chinese.
   • Push only a short Feishu message containing the title, top themes, doc link, and caveats.
   • Do not paste long full content into the message.

For source-backed feeds such as Follow Builders and Hugging Face Papers, every Feishu document must show explicit attribution near the top:

• who said it / paper authors / account or podcast name
• original signal or contribution
• source URL or arXiv ID
• raw_original/source-index path if available
• Hermes interpretation

Do not present unattributed generic conclusions. Low-signal sources should be marked as down-ranked/omitted rather than silently mixed into the main thesis.

Known implementation pattern on this machine:

• Feishu docx creation from cron/local scripts may require explicitly loading Hermes environment configuration inside the Python process; do not assume every tool context inherits the same environment. If a Python helper reports missing Feishu app configuration while a shell check shows it is configured, load the local Hermes env file in that helper before making Feishu API calls. Never print secret values.
• Get a Feishu tenant access token via the standard internal app auth endpoint, then use it only in Authorization headers.
• Create docx with POST https://open.feishu.cn/open-apis/docx/v1/documents, payload {"title": "..."}.
• Add blocks with POST /open-apis/docx/v1/documents/:document_id/blocks/:document_id/children?document_revision_id=-1.
• The root block_id is the document_id.
• Use real Feishu docx structured blocks, not all paragraph blocks:
  • paragraph: {"block_type": 2, "text": rich_text}
  • H1: {"block_type": 3, "heading1": rich_text}
  • H2: {"block_type": 4, "heading2": rich_text}
  • H3: {"block_type": 5, "heading3": rich_text}
  • bullet: {"block_type": 12, "bullet": rich_text}
  • ordered: {"block_type": 13, "ordered": rich_text}
  • quote: {"block_type": 15, "quote": rich_text} where rich_text is {"elements":[{"text_run":{"content":...,"text_element_style":{}}}],"style":{}}.
• The user explicitly wants Feishu daily documents to be structured reading docs with a real Feishu document outline / left-side directory, not流水账/plain-text dumps and not normal paragraphs that merely contain typed numbers. Use actual heading blocks with numbered hierarchy: H1 1. 大标题, H2 1.1 小标题, H3 1.1.1 三级标题; organize conclusion → themes → evidence/source attribution → follow-up actions → archive/traceability.
• Verify by listing doc children and confirming heading block types 3/4/5 are present, not only paragraph blocks. If headings were written as normal text blocks, treat it as failed and rewrite. Batch at <=45 blocks/request and sleep briefly to avoid edit rate limits.
• User-facing URLs can be formed as https://oxpahq8s0qh.feishu.cn/docx/<document_id> or https://www.feishu.cn/docx/<document_id>.
• Verify the document through the same Docx API rather than feishu_doc_read unless actually running inside a Feishu comment context. feishu_doc_read can return Feishu client not available (not in a Feishu comment context) in cron/local sessions even when the document was created successfully.
• Verification pattern that worked in a cron/local run: call GET /open-apis/docx/v1/documents/:document_id/blocks/:document_id/children?page_size=500&document_revision_id=-1 (fallback without document_revision_id), count returned child blocks, and verify required section headings against the intended block text. For Follow Builders Feishu docs, follow the exact outline labels from the prompt: 技术研究视角, 产品 / 创业视角, 来源 attribution, and 跟进动作与归档 / 归档路径. Do not incorrectly fail a doc just because it says 来源 attribution instead of 关键来源与 attribution or 跟进动作与归档 instead of 归档与追溯. Require at least 25 blocks and heading block types 3/4/5; append the block count and pass/fail result to _global/log.md. If the create/edit/list flow succeeds, use https://www.feishu.cn/docx/<document_id> as the delivered URL.

Current Feishu app limitation discovered on 2026-05-09:

• It can create and edit docx documents.
• It cannot list Drive files or change document sharing/collaborators because permission scopes such as drive:drive, drive:drive:readonly, space:document:retrieve, docs:permission.setting:write_only, and docs:permission.member:create are missing.
• Do not fail content delivery because of this; include a caveat if the document may not be accessible until permissions are fixed.

Recommended future automation:

• For each daily/weekly cron, generate wiki archives first.
• Then generate the Chinese-only Feishu doc reading version.
• Finally deliver a short Feishu message with the doc link.
• Once Drive/permission scopes are added, extend the job to create/find folder hierarchy and set organization-readable sharing.

Pitfalls

• Do not assume you can read another company bot’s messages. If you only see merged-forward placeholders, design the new Lens as independent/complementary rather than dependent on that bot’s raw content.
• Do not mix unrelated daily pushes in the same wiki folder or message stream if the user wants them conceptually separate.
• Do not reuse the company bot’s exact structure; it creates duplicate attention cost.
• Do not set deliver=origin for cron jobs in a context where origin delivery is unresolved. Check existing working jobs for the reliable delivery target. If unsure, use the same target pattern as the latest working chat-delivered job.
• Do not create standalone query pages in wiki/queries/ for project Lens content when the user’s newsletter workflow keeps that root sparse.
• In cron delivery prompts, do not call send_message; produce the report as the final response and let the cron system deliver it. If the prompt says to be silent only when there is genuinely nothing new, still produce a normal Daily Lens when using recent user/community observations rather than breaking news.
• Some Daily Lens prompts may include a generic Feishu document outline standard even though the specific task only requires a wiki markdown archive and final cron-delivered response. Do not invent a Feishu doc creation step unless the prompt explicitly asks to create/backfill a Feishu docx or deliver a Feishu document link. If a Feishu docx is required, then use real docx heading blocks and verify block types 3/4/5 as described in the Feishu document delivery pattern.
• Web search tools may fail with authorization errors or bot checks in scheduled runs. Fallback workflow: use terminal with requests/urllib for official pages and public endpoints; try Bing RSS search (https://www.bing.com/search?format=rss&q=<urlencoded query>) or direct Bing HTML parsing from terminal when managed web_search is unauthorized; use DuckDuckGo HTML (https://duckduckgo.com/html/?q=...) from terminal if it returns usable HTML; and use browser only if needed. Google/DuckDuckGo/Brave Search in browser may hit bot-check/CAPTCHA pages, so avoid relying on them for cron runs. Cite the original public URLs. Treat Reddit/community observations as qualitative signals and state the limitation.
• If web_extract is unauthorized, try direct urllib/requests first for official pages before using browser extraction. For ordinary HTML pages, strip scripts/styles and search the resulting text for key phrases. This worked for Oura’s official Readiness Score page and yielded score-range/contributor details while web_extract returned auth errors. If an official source page only loads in the browser, use browser_snapshot(full=true) or browser_console(expression="document.body.innerText") to extract the article text. Avoid depending on Google/DuckDuckGo browser search pages in cron because they may show CAPTCHA/bot checks instead of results. For Everlyme, direct browser navigation to official brand pages can still work when search/extract fails; recent useful examples include Oura Advisor (https://ouraring.com/blog/oura-advisor/), WHOOP My Memory (https://www.whoop.com/sg/en/thelocker/my-memory-whoop/), and Apple App Store Oura reviews (https://apps.apple.com/us/app/oura/id1043837948). WHOOP Locker listing pages can reveal recent AI Coaching topics even when the exact old URL redirects.
• Reddit .json endpoints can return 403 in cron/network environments, even when search results expose thread URLs. Still try the .json endpoint with a normal User-Agent before giving up; when accessible, parse the post selftext, top comments, upvotes, and title into a compact qualitative sample rather than scraping the rendered page. For Everlyme Daily Lens, this worked for r/ouraring threads about readiness/sleep-score psychology and produced user-language examples such as scores altering mood, low-score anxiety, and treating data as non-judgmental signals. When managed web_search fails, use subreddit search JSON first to discover candidate threads, e.g. https://www.reddit.com/r/ouraring/search.json?q=Oura%20Advisor%20AI&restrict_sr=1&sort=relevance&t=all&limit=5, then fetch selected threads with https://www.reddit.com/r/ouraring/comments/<post_id>/.json?limit=10&sort=top. This is often faster and cleaner than parsing search-engine HTML. If Reddit is blocked, do not stall the Daily Lens; switch to other public user-voice sources such as Apple App Store RSS (https://itunes.apple.com/<country>/rss/customerreviews/id=<app_id>/sortBy=mostRecent/json), Google Play/Amazon/Product Hunt pages, YouTube comments if accessible, or official/community pages. For App Store review mining, first discover the app ID with iTunes Search API (https://itunes.apple.com/search?term=<query>&entity=software&country=us&limit=5), then fetch recent reviews via RSS and clearly state region/sample limitations. Known Everlyme-relevant seeds:
• Oura iOS app ID 1043837948, recent-review RSS https://itunes.apple.com/us/rss/customerreviews/id=1043837948/sortBy=mostRecent/json; useful for mining concrete complaints about flat data, AI Advisor actionability, sync/battery failures, missed-wear/nap misclassification, and praise for low-stress guidance.
• Fitbit iOS app ID 462638897, recent-review RSS https://itunes.apple.com/us/rss/customerreviews/id=462638897/sortBy=mostRecent/json; useful for mining user backlash to UI changes, removed/hidden sleep details, lost challenges/social motivation, reliability regressions, and fear that AI/extra metrics will disrupt familiar health rituals.
• Garmin Connect iOS app ID 583446403, recent-review RSS https://itunes.apple.com/us/rss/customerreviews/id=583446403/sortBy=mostRecent/json; useful for mining connection/sync, sleep-measurement, Bluetooth-permission, data-graph, and serious-athlete training/recovery feedback.
• Ultrahuman iOS app ID 1491286709, recent-review RSS https://itunes.apple.com/us/rss/customerreviews/id=1491286709/sortBy=mostRecent/json; useful for mining smart-ring long-term reliability, support, and AI-layer backlash. A concrete 2026-05-27 review titled Unnecessary AI added criticized the Jade AI as repeating information users could already read and sending “help decode body signals” alerts that could not be turned off. Pair with Oura Advisor official page to frame Everlyme’s product lesson as “AI health agents must earn the right to speak”: explain why now, expose frequency/quiet controls, and avoid merely reading dashboard data back to the user.
• Strength/muscular-load angle: useful when the day needs a user-insight topic distinct from generic AI Advisor trust. Official source: WHOOP Locker article https://www.whoop.com/sg/en/thelocker/podcast-219-behind-the-development-of-the-all-new-strength-trainer/, which frames heart-rate-only tracking as undercounting slow/heavy lifting and connects muscular load to Strain/Sleep/Recovery. Community samples accessible through Reddit JSON in one run: r/whoop/comments/1pw0jmh (Strength Trainer UX paper cuts), r/whoop/comments/1jkmhen (45 minutes lifting but 0.0 strain), and r/GarminWatches/comments/1rkm84h (HRV drop flagged as strained but without causal explanation). Frame this as qualitative evidence for “my body worked; did the system see why?” and design Everlyme output around explainable body-load cards, not just better scoring.
• Score-anxiety / “device as life judge” angle: useful when the day needs a psychological counterpoint to AI health coaching. Reddit JSON seeds that worked in cron: r/ouraring/comments/1r9xfx8 (“I’m done with my ring”: HRV/readiness/sleep scores led to fixation on bedtime, alcohol, stress spikes, social avoidance, then subscription cancellation), r/ouraring/comments/1tiiz9c (Oura not worth it because workouts/activity are missed; commenters distinguish wellness/sleep vs fitness tracking), r/whoop/comments/1sf4xjz (community analysis says the top pain is not knowing what to do with data), and r/whoop/comments/1tl93vj (Apple Watch → WHOOP switch motivated by wanting mechanical watches, fewer notifications, sleep/recovery focus). Pair with Oura Advisor official page https://ouraring.com/blog/oura-advisor/, especially claims about actionable personalized guidance, tone customization, and LLM mistakes. Frame Everlyme as restoring user agency: “explain, suggest one gentle next step, and know when to be quiet,” not just smarter scoring.

Before writing an Everlyme Daily Lens entry, read the previous day’s file and the index so the new topic does not repeat yesterday’s angle. If today’s initial source search overlaps too closely with the prior entry (for example, another Oura Advisor trust/correction angle), pivot to a sharper sub-angle or another public user-voice source such as Fitbit/Garmin App Store RSS and frame a distinct product/creative insight. Concrete pivot that worked: an Oura Google Play review about sync lag and missed nap/walk detection was too close to the recurring “AI should show what it saw/missed” trust theme, so reframe it as “data freshness / advice recency” instead: show Updated X min ago, synced/missing events, and a one-tap recheck/regenerate action. This avoids repeating evidence-gap/correction narratives while still using the same source.

If web search/search-engine scraping is low quality but one strong competitor narrative is accessible, it is acceptable to build the day around an official competitor page plus one durable user-psychology/clinical framing source, as long as the output explicitly states the source limitations and converts the insight into product/TVC/app-copy implications. Example pattern that worked: WHOOP official Healthspan/WHOOP Age/Pace of Aging page + the orthosomnia paper (https://link.springer.com/article/10.5664/jcsm.6472) to frame score anxiety. For Springer/JCSM pages, direct requests may need verify=False due certificate issues in cron; use only for extraction and cite the canonical URL. BusinessWire may time out or be blocked by managed extractors, so prefer the original brand page when available.

Concrete pattern from Everlyme/Self Agent

The user wanted to keep the original daily-newsletter-digest unchanged and add a second daily push for Everlyme/Self Agent. The correct setup was:

• Original digest unchanged at 10:15.
• New job: everlyme-daily-lens.
• Schedule: 30 9 * * * (09:30 daily, before the original digest).
• Frequency: every day including weekends, indefinitely, unless later changed to a 7-run trial.
• Editorial focus: user insight, product experiments, TVC/brand translation, bilingual expressions, discussion question.
• Wiki index: /Users/leiyuxuan/Documents/PyCharm_Project/wiki/_global/wiki/everlyme/Everlyme Daily Lens Index.md.
• Daily archive folder: /Users/leiyuxuan/Documents/PyCharm_Project/wiki/_global/wiki/everlyme/daily-lens/.