菜单
Ingest AI newsletters from ClawEmail into a local wiki, extract reusable workflows, and produce bilingual daily digests. Use when operating a newsletter-driven second-brain setup with mail-cli, Hermes, and markdown notes.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Set up Hermes Agent Feishu/Lark gateway from CLI, including dependency install, TERM=dumb interactive setup, QR/manual credential flow, gateway restart, and daily cron delivery verification. Use when configuring Hermes with Feishu/Lark or troubleshooting Feishu setup.
Operate Claw Email mailboxes via mail-cli. Use for reading, searching, sending, and managing claw.163.com mailboxes and newsletter sub-mailboxes.
Verify a ClawEmail mail-cli setup, test end-to-end send/read flow, and distinguish between mail-cli readiness, OpenClaw email-channel enablement, and Hermes skill integration.
Create polished Feishu/Lark docx reading versions for scheduled digests with real outline headings, wiki archive links, and verification. Use when a digest/newsletter/wiki cron must produce a Feishu doc, not just a message or markdown dump.
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.
Produce concise Chinese digests of the current Hugging Face Daily Papers weekly page. Use when asked to summarize/trend top papers from huggingface.co/papers/week/current or the Weekly tab on Hugging Face Papers.
| name | newsletter-second-brain |
| description | Ingest AI newsletters from ClawEmail into a local wiki, extract reusable workflows, and produce bilingual daily digests. Use when operating a newsletter-driven second-brain setup with mail-cli, Hermes, and markdown notes. |
| version | 1.0.0 |
| author | Hermes Agent |
| license | MIT |
| metadata | {"hermes":{"tags":["newsletter","clawemail","wiki","digest","bilingual","workflow","second-brain"]}} |
Use this skill when the user has a ClawEmail/newsletter mailbox and wants to:
mail-cli read body output is noisy and too HTML-heavyDo NOT rely on naive HTML stripping from mail-cli read body for newsletter ingest. It often preserves footer junk and can miss the true article structure. A dedicated parser that walks headings/paragraphs/list items produces much better source notes.
mail-cli configured with a newsletter profile~/wiki)WIKI_PATH and ideally OBSIDIAN_VAULT_PATH pointing at that wiki~/.hermes/scripts/newsletter_extract.pyIf the user already has a multi-vault project wiki, prefer the project's canonical vault structure over a standalone ~/wiki bootstrap directory.
In real usage on this machine, the better long-term destination was:
/Users/leiyuxuan/Documents/PyCharm_Project/wiki/_global/Users/leiyuxuan/Documents/PyCharm_Project/wiki/_global/wiki//Users/leiyuxuan/Documents/PyCharm_Project/wiki/_global/raw/For cross-project AI/newsletter/workflow knowledge, route into _global rather than a project-specific vault.
If you bootstrap in ~/wiki first, either migrate into the canonical vault later or make ~/wiki a symlink to that canonical location.
~/wiki/
SCHEMA.md
index.md
log.md
raw/articles/
concepts/
queries/
workflows/
Use mail-cli --profile newsletter mail list --fid INBOX --limit 20 --json to identify candidate emails.
Prioritize items about:
Preferred pattern:
python ~/.hermes/scripts/newsletter_extract.py <message-id>
The parser should:
mail-cli --profile newsletter read body --id <id> --jsonh1/h2/h3/h4/p/li{heading, items}Important: this worked much better on Beehiiv/Substack mail than raw text extraction.
Save a parsed snapshot to raw/articles/YYYY-MM-DD-source-slug.md with frontmatter like:
---
source_url: unknown
ingested: YYYY-MM-DD
updated: YYYY-MM-DD
source_type: newsletter-email-parsed
sender: sender@example.com
subject: Subject line
email_date: YYYY-MM-DD HH:MM:SS
message_id: <mail id>
extractor: ~/.hermes/scripts/newsletter_extract.py
---
Then store sectioned markdown under ## Parsed structure.
Save a summary to queries/<slug>-summary.md.
The best summary format in practice was:
If extraction quality is partial, say so explicitly instead of pretending to have full coverage.
A key lesson from this workflow: newsletter value often compounds more from reusable workflow examples than from the top headline.
Promote repeated patterns into dedicated concept/workflow pages such as:
Use a strict bilingual template. Keep both English and Chinese for every major section.
Recommended structure:
## English
### Selection note
### 1. [signal]
- what happened
- why it matters
- watch next
### 2. [signal]
...
### Reusable workflow ideas
## 中文
### 选择说明
### 1. [信号]
- 发生了什么
- 为什么重要
- 后续观察点
### 2. [信号]
...
### 可复用 workflow 想法
## Bottom line / 总结
Every ingest should update:
index.mdlog.mdIf you create concept/workflow pages, add them to the appropriate index section as well.
raw/articles/YYYY-MM-DD-source-topic.mdqueries/daily-newsletter-digest-YYYY-MM-DD.mdqueries/source-topic-summary.md for genuinely heavyweight/high-signal items worth separate display; otherwise fold newsletter items into the daily digestworkflows/<workflow-name>.mdconcepts/<concept-name>.mdFor this user's _global newsletter workflow, keep wiki/queries/ root sparse. The user now prefers Chinese and English digest content archived separately, not as one long combined bilingual page.
Default daily layout:
wiki/queries/daily-newsletter-digest/en/daily-newsletter-digest-YYYY-MM-DD.en.mdwiki/queries/daily-newsletter-digest/zh/daily-newsletter-digest-YYYY-MM-DD.zh.mddaily-newsletter-digest-YYYY-MM-DD.md unless the user explicitly asks for a single combined view.For daily archives, keep generated markdown free of read_file display prefixes such as 12|..., verify no root combined file was created, and verify newsletter raw snapshot frontmatter sha256 against the exact body after the closing frontmatter delimiter.
The daily digest pair should cover the same underlying sources:
~/.hermes/scripts/aihot_context.py; preserve sourceName/source and sourceUrl/url attribution for every AI HOT item, and treat AI HOT summaries as LLM-generated aggregation that should be verified against original URLs before citation~/.hermes/scripts/fetch_cn_ai_sources.py, which uses Jina Reader (https://r.jina.ai/http://r.jina.ai/http://https://www.jiqizhixin.com/articles) because direct /, /articles, and /rss often return a data-service shell in browser/cron contextsFeishu-facing daily newsletter documents should be Chinese-only, with English archives remaining in the wiki. Separate standalone pages are reserved for heavyweight items that deserve independent tracking.
When the daily digest cron asks for a Feishu docx reading version, create one Chinese-only document titled 每日 AI Newsletter Digest｜YYYY-MM-DD via Feishu docx OpenAPI:
FEISHU_APP_ID and FEISHU_APP_SECRET from /Users/leiyuxuan/.hermes/.env without printing secrets.POST https://open.feishu.cn/open-apis/auth/v3/tenant_access_token/internal.POST https://open.feishu.cn/open-apis/docx/v1/documents and payload {"title": "每日 AI Newsletter Digest｜YYYY-MM-DD"}.POST /open-apis/docx/v1/documents/:document_id/blocks/:document_id/children?document_revision_id=-1.1. 今日总览; H2 1.1 一句话结论, 1.2 三条主线, 1.3 今天建议阅读顺序2. Newsletter 主线：从模型能力到工作系统; H2/H3 for source, technical points, Hermes judgment3. AI HOT 高信号雷达; group items by theme instead of a flat news feed, and explicitly down-rank low-signal items4. 我的判断与后续跟进5. 来源 attribution 与归档
Feishu API block mapping: H1 block_type:3/heading1, H2 4/heading2, H3 5/heading3, paragraph 2/text, bullet 12/bullet, ordered 13/ordered, quote 15/quote.document_id to form a stable URL. If FEISHU_DOMAIN in .env is just feishu, normalize the final report URL to https://feishu.cn/docx/<document_id> rather than feishu/docx/<id>.Recommended cleanup layout:
wiki/queries/ root: sparse navigation/index or exceptional query pages only.wiki/queries/daily-newsletter-digest/en/: daily English digest archive.wiki/queries/daily-newsletter-digest/zh/: daily Chinese digest archive.wiki/queries/heavyweight/: exceptional standalone query pages for high-signal topics worth long-term separate display.wiki/queries/archive/: ordinary historical summaries, early experiments, self-tests, and pages superseded by daily digests.wiki/status/: operational status files such as newsletter-confirmation-monitor-latest.md; do not keep status/monitor files in queries/.When reorganizing, also update index.md, log.md, wiki/workflows/newsletter-operations-map.md, relevant wikilinks, and any cron prompts that write to moved paths.
When the user wants old combined bilingual daily digests separated by language:
wiki/queries/daily-newsletter-digest-*.md.## English through before ## 中文 → English archive.## 中文 through before ## 中文 AI 资讯简报 or ## Bottom line / 总结 → Chinese archive.## 中文 AI 资讯简报（量子位 / 机器之心） stays in the Chinese archive.## Bottom line / 总结 is split into English bottom line and Chinese summary when possible.wiki/queries/daily-newsletter-digest/en/daily-newsletter-digest-YYYY-MM-DD.en.mdwiki/queries/daily-newsletter-digest/zh/daily-newsletter-digest-YYYY-MM-DD.zh.mdwiki/queries/archive/combined-daily-newsletter-digest/ instead of deleting it, so old links can be recovered.index.md to list .en and .zh archive entries, not root combined links.log.md entry documenting the dates processed, archive roots, and legacy combined-file location.wiki/queries/ root has no daily-newsletter-digest-YYYY-MM-DD.md files.archive/combined-daily-newsletter-digest/.1| were introduced into index/log/generated pages.A good cron setup used two pieces:
newsletter_digest_context.py that outputs the recent inbox list as compact JSON.newsletter_extract.py for each selected messagelog.mdIf you want consistent quality, force the cron output to follow a saved digest template file.
Hermes cron jobs do not fire automatically unless the Hermes gateway is actually running.
On macOS, the reliable pattern was:
hermes cron status says the gateway is runningA useful self-test is to create a one-shot cron job that writes a tiny file into the target wiki directory. This isolates scheduler health from digest complexity.
If the wiki has a canonical project-vault path, do not rely on ~/wiki in the cron prompt just because a symlink exists.
Use explicit output paths such as:
/Users/leiyuxuan/Documents/PyCharm_Project/wiki/_global/wiki/queries/daily-newsletter-digest-YYYY-MM-DD.md/Users/leiyuxuan/Documents/PyCharm_Project/wiki/_global/wiki/workflows/bilingual-daily-digest-template.md/Users/leiyuxuan/Documents/PyCharm_Project/wiki/_global/log.md/Users/leiyuxuan/Documents/PyCharm_Project/wiki/_global/raw/articles/This avoids hidden dependence on compatibility symlinks and makes the automation easier to reason about.
If you also run a confirmation-monitor cron job, do not leave it on deliver=origin without a resolved target.
A more reliable pattern is to make it write to a fixed status file in the canonical vault, for example:
/Users/leiyuxuan/Documents/PyCharm_Project/wiki/_global/wiki/status/newsletter-confirmation-monitor-latest.mdThe monitor should overwrite that file on each run with:
This makes the monitor inspectable even when no chat-origin delivery target exists.
For the daily digest, deliver=local is good for silent wiki-only operation, but if the user expects the digest to appear in the current chat, update the cron job to deliver=origin or send a short confirmation with send_message after verifying the file. For this machine, daily-newsletter-digest is configured with deliver=feishu; successful delivery can also be verified by a send_message/cron message_id and last_delivery_error: null.
When the user asks where to see today's latest content:
date. Do not assume the date from prior turns; in long sessions the calendar day may have changed.*YYYY-MM-DD*.md, especially wiki/queries/daily-newsletter-digest-YYYY-MM-DD.md, wiki/everlyme/daily-lens/Everlyme-Daily-Lens-YYYY-MM-DD.md, and raw/articles/YYYY-MM-DD-*.md.cronjob list for the digest job's last_run_at, last_status, next_run_at, and last_delivery_error. Also check related daily jobs such as everlyme-daily-lens when the user asks “今日该完成的任务”.cronjob run <job_id>.~/.hermes/sessions/session_cron_<job_id>_YYYYMMDD_*.json until a final assistant response or the file appears.Important nuance: cronjob run may schedule an immediate/near-future run, and last_run_at / last_status may lag or remain unset while the output file has already been created. Treat the canonical vault file and log entry as the source of truth for content availability, not only the cron status fields.
If daily-newsletter-digest or a companion daily task fails with last_activity=initializing / inactivity timeout, recover the day's artifacts manually instead of only reporting failure:
date to determine the exact target day.python ~/.hermes/scripts/newsletter_digest_context.py to inspect newsletter candidates.python ~/.hermes/scripts/fetch_cn_ai_sources.py YYYY-MM-DD and verify the raw Chinese snapshot has a valid sha256 in frontmatter; if absent, add a body hash over content after the closing frontmatter delimiter.~/.hermes/hermes-agent/venv/bin/python ~/.hermes/scripts/newsletter_extract.py <message-id> so the same environment used by cron is exercised. Save raw snapshots under _global/raw/articles/YYYY-MM-DD-<slug>.md._global/wiki/queries/daily-newsletter-digest/en/daily-newsletter-digest-YYYY-MM-DD.en.md and _global/wiki/queries/daily-newsletter-digest/zh/daily-newsletter-digest-YYYY-MM-DD.zh.md; update _global/index.md and _global/log.md.everlyme-daily-lens also failed, create _global/wiki/everlyme/daily-lens/Everlyme-Daily-Lens-YYYY-MM-DD.md, update wiki/everlyme/Everlyme Daily Lens Index.md, and append a log entry. Be careful not to rewrite files using line-numbered read_file output; use patch or clean Path.read_text()/write_text().search_files + read_file, then send a concise Feishu summary with the file paths and main themes.Pitfall: API keys or strings beginning with sk- may appear in chat during debugging. Treat them as secrets: do not repeat, store, or use them; tell the user to revoke/rotate the key.
Important nuance: cronjob run may schedule an immediate/near-future run, and last_run_at / last_status may lag or remain unset while the output file has already been created. Treat the canonical vault file and log entry as the source of truth for content availability, not only the cron status fields. If a manual run is in progress and cronjob list has not updated yet, inspect ~/.hermes/sessions/session_cron_<job_id>_YYYYMMDD_*.json to see whether the cron agent is actively making tool calls, writing files, or stuck; poll both the expected output file and that session file before declaring failure.
A real failure mode: the daily digest cron can show last_status: error and no output file because the cron agent idled during initialization before any tool call, e.g. Job 'daily-newsletter-digest' idle for 786s (inactivity limit 600s) | last_activity=initializing | iteration=0/90 | tool=none. In that case, content was not generated at all, so Feishu delivery cannot have happened. Distinguish this from delivery-only failures such as Feishu/Lark DNS/WebSocket errors, where content may exist locally but sending failed.
For day-to-day use, maintain a single workflow entry page inside the canonical vault, for example:
/Users/leiyuxuan/Documents/PyCharm_Project/wiki/_global/wiki/workflows/newsletter-operations-map.mdThat page should list:
For this machine, the user-facing Obsidian/Finder shortcut is:
/Users/leiyuxuan/Documents/PyCharm_Project/wiki/ai-news-vault → symlink to /Users/leiyuxuan/Documents/PyCharm_Project/wiki/_global/wiki/Users/leiyuxuan/Documents/PyCharm_Project/wiki/_global/wiki/Home.mdUse this shortcut for daily browsing, while keeping cron prompts and automation writes pointed at the canonical full paths under _global. Raw sources, index.md, and log.md remain in the full vault root (/Users/leiyuxuan/Documents/PyCharm_Project/wiki/_global), not inside the shortcut.
A single operations-map page plus a named shortcut vault drastically reduces the cognitive overhead of resuming the system after a break.
newsletter_extract.py: the script may return only sparse sections while mail-cli --profile newsletter read body --id <id> --json still contains the real newsletter body. If the structured extractor output is too short or missing expected headings, fall back to mail-cli read body --json, strip <style>/<script>/<head> blocks, insert line breaks around block tags (p/div/tr/td/h*/li/a/br), then save a raw snapshot with an explicit “partial/noisy extraction” note.execute_code with subprocess.run([...], capture_output=True, text=True) and parse/clean in-process.