Paper Report Delivery
Use this skill to implement or maintain an end-to-end daily paper report workflow.
Do this
- 1. Read
references/workflow.md first. - Keep the pipeline end-to-end: collection, selection, readable output, archive, delivery.
- Prefer Telegram-only proxying via
channels.telegram.proxy when Telegram API needs Clash. - Treat Telegram message delivery and Telegram document delivery as separate reliability paths.
- Prefer this delivery order:
- split HTML delivery
- retry for a bounded window
- Telegram message chunk fallback
- 6. Keep local artifacts even when remote delivery fails.
Reusable scripts
Use these bundled scripts when they fit:
- Build a readable single-file HTML report with embedded images.
- Convert a readable report JSON into Telegram-sized message chunks.
- Retry Telegram sending for unstable transport.
- Try split HTML for up to 30 minutes, then fall back to Telegram message chunks.
Implementation rules
- - Keep HTML as the best-reading artifact.
- Keep Telegram message chunks as the most reliable delivery artifact.
- Archive HTML, PDF, and markdown even when only Telegram text is delivered.
- Do not assume Telegram document delivery is stable.
- If Telegram is unreachable, finish artifact generation and leave cached delivery files behind.
When editing an existing repo
- - Integrate into the repo’s main pipeline entrypoint instead of creating a disconnected side script.
- Add flags for skipping fetch, skipping send, and archive-only mode.
- Keep delivery logic explicit and observable in logs.
- If Telegram transport is flaky, add retries before changing report content.
Publishing hygiene
Before public release:
- - Remove hard-coded local paths
- Remove hard-coded Telegram targets and group names
- Replace fixed dates with dynamic
YYYY-MM-DD handling - Keep transport settings configurable
Packaging
After the skill is complete, package it with the local package_skill.py helper from the OpenClaw skill-creator skill.
纸质报告投递
使用此技能来实现或维护一个端到端的每日纸质报告工作流。
操作步骤
- 1. 首先阅读 references/workflow.md。
- 保持管道的端到端完整性：收集、筛选、可读输出、归档、投递。
- 当Telegram API需要Clash时，优先通过 channels.telegram.proxy 进行仅Telegram代理。
- 将Telegram消息投递和Telegram文档投递视为独立的可靠性路径。
- 优先采用以下投递顺序：
- 拆分HTML投递
- 在有限时间窗口内重试
- Telegram消息分片回退
- 6. 即使远程投递失败，也要保留本地工件。
可复用脚本
在适用情况下使用以下捆绑脚本：
- - scripts/buildreadablehtml.py
- 构建包含嵌入图片的可读单文件HTML报告。
- - scripts/buildtelegrammessages.py
- 将可读报告JSON转换为Telegram消息大小的分片。
- - scripts/sendtelegramretry.sh
- 针对不稳定的传输环境重试Telegram发送。
- - scripts/sendhtmlthen_fallback.py
- 尝试拆分HTML投递最多30分钟，然后回退到Telegram消息分片。
实现规则
- - 保持HTML作为最佳阅读工件。
- 保持Telegram消息分片作为最可靠的投递工件。
- 即使只投递了Telegram文本，也要归档HTML、PDF和Markdown。
- 不要假设Telegram文档投递是稳定的。
- 如果Telegram不可达，完成工件生成并保留缓存的投递文件。
编辑现有仓库时
- - 集成到仓库的主管道入口点，而不是创建独立的侧边脚本。
- 添加跳过获取、跳过发送和仅归档模式的标志。
- 保持投递逻辑在日志中明确且可观察。
- 如果Telegram传输不稳定，在更改报告内容之前先添加重试机制。
发布规范
公开发布前：
- - 移除硬编码的本地路径
- 移除硬编码的Telegram目标和群组名称
- 将固定日期替换为动态的 YYYY-MM-DD 处理
- 保持传输设置可配置
打包
技能完成后，使用OpenClaw skill-creator 技能中的本地 package_skill.py 辅助工具进行打包。
