Daily Hot Report
Use this skill for the recurring daily hot-list workflow: fetch current hot topics, write the full report to a Feishu child doc, and send a short Feishu group summary that links to the full doc.
Default Scope
- Platforms by default: Douyin, Weibo, Zhihu, Xiaohongshu.
- Child doc title format:
YYYY-MM-DD - Full report goes into the child doc.
- Group message stays short and links to the full doc.
- Do not modify the Feishu root page by default.
- The closing joint summary is for Douyin + Weibo + Zhihu only.
If the current repo or workspace has a local hot-report convention file, follow that local scope and format over this skill default.
Main Rule
There are only two modes for this workflow:
- Initialization
- Normal daily run
Do not mix them.
Initialization
Treat the task as initialization only when:
- The user explicitly asks to initialize, configure, set up, or repair the workflow environment.
- The environment is obviously incomplete for a normal run, and the user then explicitly agrees to initialize/configure it.
During initialization:
- user identity is allowed, but only for the one-time authorization step
- bot identity is also used
- the agent must ask the user to confirm:
- which Feishu group should receive the summary
- which Feishu wiki/doc page should be the directory root
- which app bot ID should be used
- do not send the user to the Feishu web UI to grant root-document bot edit
permission; the agent must do that with
lark-clior API
Read these files only when doing initialization:
- references/initialization.md
- references/config-spec.md
- references/setup-feishu-resources.md
- references/setup-lark-cli.md
Normal Daily Run
If the task is not initialization, it is a normal daily run.
During a normal daily run:
- use bot identity only
- do not rely on user identity
- do not rely on macOS keychain-backed user auth
- do not run setup or troubleshooting helpers as preflight gates
- if required runtime config is missing or malformed, fail the run instead of silently switching into setup
Runtime bot auth must follow this model:
- obtain the bot token directly from
LARK_APP_IDandLARK_APP_SECRET - use that runtime token directly with Feishu OpenAPI
- do not translate runtime bot auth into
lark-cliprofile operations
Normal daily path:
- Read
daily-hot-report.env. - Validate only the runtime prerequisites needed for this run.
- Fetch current platform data.
- Read the fetched hot-list data and perform the analysis in the outer Agent.
- Create or reuse the daily child doc.
- Render the full report into Feishu
docxblocks and write it by OpenAPI. - Send the short group summary.
Read these files only when needed during a normal run:
- references/output-design.md
- references/runtime-script-interface.md
- references/runtime-auth-model.md
- references/runtime-api-path.md
- references/config-spec.md
- references/troubleshooting.md
references/output-design.md is the place for the intended reader-facing
format of the final deliverables: the short group summary and the full Feishu
child document.
references/runtime-script-interface.md is the place for the reference
script’s boundary: the script may fetch hot lists and publish a completed
report, but the analysis itself belongs to the outer Agent.
references/runtime-api-path.md is the place for the exact runtime OpenAPI
payload shapes that have already been validated in a real daily run. Prefer
that file over guessing low-level Feishu docx block fields.
Optional reference script:
Rules for this script:
- it is a convenience reference, not the workflow contract
- do not force future runs to use it
- do not move the editorial analysis step into the script
- when the script and the written skill guidance diverge, update or ignore the script and follow the documented runtime API path
Automation Creation
When the user asks to create a recurring automation, do not just assume the target platform’s background execution environment can run this workflow.
Before creating the automation, assess whether the recurring run is likely to have:
- outbound network access and DNS
- local access to the env file
- ability to obtain a bot token from
LARK_APP_IDandLARK_APP_SECRET - ability to call the required Feishu APIs from that bot token
If platform evidence already suggests background network or DNS is restricted, surface that as a serious blocker or risk instead of presenting the automation as safely unattended.
Read this file when creating or reviewing automations:
Feishu Delivery Rules
- The reader-facing design of both deliverables is documented in references/output-design.md.
- Runtime message/document payload details are documented in references/runtime-api-path.md.
- Do not use webhook as the primary path.
- If Feishu publishing fails, do not treat a local-only Markdown file as a successful result.
Source Priority
Use the most stable structured sources first.
Priority:
- Official structured endpoints when accessible.
- Reliable RSSHub or equivalent structured feeds.
- Public hot-list APIs such as
60s. - Official pages or browser extraction when structured sources are insufficient.
Known fallback endpoints:
https://60s.viki.moe/v2/weibo
https://60s.viki.moe/v2/zhihu
https://60s.viki.moe/v2/douyin
https://60s.viki.moe/v2/rednote
Use current data only. Do not rely on model memory for hot topics.
Output Design
The design-level definition of the final outputs lives in references/output-design.md.
Use that file when deciding what a human reader should see in:
- the short Feishu group summary
- the detailed Feishu child document
Use references/runtime-api-path.md only for implementation-layer payload
shapes and send/write mechanics.
Failure Handling
- If one platform fails, continue with the others and note that in the report.
- If all structured sources fail and browser tooling is available, recover with official pages.
- If Feishu delivery fails, report the run as failed.
- Do not silently downgrade to local-only success in automation contexts.