| name | dailypaper-operator |
| description | 用于操作 dailypaper 自动化早报生产线。适用于 setup、prepare、review-status、status-overview、review、approve、publish、rerun-stage、schedule、一键全流程执行、人工审核介入点、口播稿修改、验收、排障、发布检查、source_health、event_summary、freshness_summary、html_fallback_count、官方源修复 等场景。用户提到 早报、日报、dailypaper、prepare、publish、approve、review-status、status-overview、审核台、补跑、调度、视频合成、发布、口播稿、一键执行、事件聚类、LLM评分、strict、loose、stale、discovery_only 时使用。默认用中文交互；优先走命令面，必要时再回退兼容旧命令。 |
| argument-hint | 填写你的目标，例如：首次跑通项目、端到端一键执行今日早报、修改口播稿后重新合成视频、修改 review 后补跑、检查今天的产物、查看 source_health 和 freshness_summary、修官方源地址 |
| user-invocable | true |
| disable-model-invocation | false |
dailypaper 操作技能
这是一套面向当前仓库的项目级 skill，用于让大模型以中文协助用户操作整条早报生产线。
适用范围
当用户要做下面这些事时，应优先使用本 skill：
- 从零配置项目并检查命令面是否可用
- 执行
setup、prepare、review-status、status-overview、approve、publish、rerun-stage
- 打开审核台并协助用户完成审核
- 查看和解释各阶段产物与状态流转
- 解释
source_health、event_summary、freshness_summary、source_tier_summary、html_fallback_count
- 排查 RSS、官方源地址、HTML fallback、TTS、FFmpeg、发布目录相关问题
- 启动或调整本地调度器
- 进行端到端验收
交互原则
1. 默认使用中文
所有说明、提问、总结和操作建议都使用中文。
2. 先识别用户模式
收到请求后，先判断用户属于哪一类场景：
- 引导模式：用户不知道下一步做什么，需要一步步带着操作
- 代执行模式：用户目标明确，例如“跑一次今天的流程”“帮我补跑昨天的日报”
- 混合模式：用户希望先解释，再由模型代为执行关键步骤
如果用户目标足够明确，应直接执行，不要只停留在解释层。
3. 默认优先走命令面
优先使用下面这组命令，而不是直接依赖旧的 run/rerun：
python main.py setuppython main.py prepare --report-date <日期>python main.py review-status --report-date <日期>python main.py status --report-date <日期>python main.py status-overview --report-date <日期>python main.py approve --report-date <日期> --approved-by <审核人>python main.py publish --report-date <日期>python main.py rerun-stage --report-date <日期> --stage prepare|publish|video|distribute
这些命令会返回稳定 JSON。模型应优先读取 ok、status、artifacts、metadata、next_action，再向用户解释。
4. 先看结构化结果，再解释人话
只要有对应命令，先执行命令拿 JSON，再向用户解释，不要反过来凭感觉判断。
5. 始终围绕仓库现状工作
本 skill 只针对当前仓库，不做抽象泛化。优先参考这些文件：
四阶段观测要点
1. freshness 层级
strict：高时效、高可信，重点栏目优先从这里选loose：仍可进入候选，但更适合进入 watchliststale：在 freshness gate 就被拦下，不进入 candidates
2. 时间可信度
time_confidence=high/medium：发布时间可信time_confidence=low 或 is_fallback_time=true：通常代表时间是回退推断值，应显著降权
3. discovery-only
discovery_only=true 通常来自 HTML fallback- 这类条目允许进入发现池，但不允许进入 highlights
4. source tier
source_tier_summary.primary_count 偏高，说明当天更偏官方主源source_tier_summary.radar_count 偏高，说明当天更偏雷达/热榜源
标准工作流
场景 1：首次配置与命令面体检
- 先运行
python main.py setup。
- 检查 JSON 返回中的
ok、sources_count、配置路径和默认审核人。
- 如果配置不完整，优先指导用户修改
config/sources.json、config/profile.json、config/branding.json。
- 若用户要求继续生成当天稿件，再进入
prepare。
场景 2：准备当天待审核稿
- 如用户没给日期，默认按今天处理，但要在反馈中明确实际日期。
- 运行
python main.py prepare --report-date <日期>。
- 检查 JSON 返回中的
status 是否为 prepared。
- 优先提醒用户查看
review_summary_path。
- 若需要解释质量概况，再补跑
status-overview，读取 freshness_summary 和 html_fallback_count。
场景 3：查看审核状态
- 运行
python main.py review-status --report-date <日期>。
- 用
status、review_status_input、final_report_exists、publish_task_exists 判断当前停在哪个阶段。
- 同时查看
recovery_suggestions，明确告诉用户下一步该重跑哪一段。
- 若用户只想要一句话结论，直接说“当前停在 prepared / in_review / approved / published”。
场景 3.5：看整条产物链与质量概览
- 运行
python main.py status-overview --report-date <日期>。
- 检查
artifact_statuses 中哪一层缺失。
- 查看
source_health：每个来源的 fetch_status、item_count、failure_reason。
- 查看
event_summary：total_events、multi_source_events、top_events。
- 查看
freshness_summary、source_tier_summary、html_fallback_count。
- 结合
recovery_suggestions 给出下一步动作，而不是只说“有文件没生成”。
场景 4：用户已经审核，准备发布
- 确认目标日期。
- 若还未批准，先运行
python main.py approve --report-date <日期> --approved-by <审核人>。
- 再运行
python main.py publish --report-date <日期>。
- 检查
final-report.json、publish-tasks.json 和 review-task.json 是否已更新为 published。
场景 5：查看当前链路是否跑通
- 先确认目标日期。
- 优先执行
python main.py review-status --report-date <日期>，先拿到结构化状态。
- 如结构化状态还不够，再按顺序检查：
data/raw -> data/clean -> data/candidates -> data/reports -> data/review_tasks/review-task.json -> data/final_reports/review.json -> data/final_reports/final-report.json -> output/reports -> output/audio -> output/visuals -> output/video -> output/publish
- 明确指出断在哪一层，不要泛泛说“可能有问题”。
场景 6：启动长期运行
- 先向用户说明调度命令会常驻当前终端。
- 确认调度时间。
- 运行
python main.py schedule --hour <H> --minute <M>。
- 告诉用户调度器默认只执行
prepare，不会自动正式发布。
- 提醒用户重点查看
output/notifications/<日期>/review-summary.md。
场景 7：端到端完整执行
- 确认目标日期（默认今天）。
- 运行
python main.py prepare --report-date <日期>。
- 执行人工审核：打开审核台或修改
review.json。
- 运行
python main.py approve --report-date <日期> --approved-by <审核人>。
- 运行
python main.py publish --report-date <日期>。
- 如需修改口播稿，编辑
final-report.json 后执行 python main.py rerun-stage --report-date <日期> --stage video。
- 如需重刷发布目录，执行
python main.py rerun-stage --report-date <日期> --stage distribute。
代理执行规范
1. 先审批，后发布
如果状态仍是 prepared 或 in_review，不要直接跳过 approve 去做 publish，除非用户明确要求沿用已有审核文件直接发布。
2. 回退兼容模式
只有在这些情况才回退到旧命令：
- 用户明确要求使用旧命令
- 新命令面覆盖不到某个场景
- 需要启动本地审核台
python main.py review --report-date <日期>
兼容语义：
python main.py run 等价于一次 preparepython main.py rerun --report-date <日期> 等价于一次 publish
3. 发现问题时的反馈结构
不要只报错。应按下面结构反馈：
- 问题出在哪一层
- 直接原因是什么
- 下一步应该执行什么
例如：
- RSS 失败：先检查
config/sources.json 的地址是否可访问；若是官方源 RSS 404，改到官方列表页并补 must_match_paths
prepare 失败：先看是否停在采集、清洗还是候选阶段，再决定是否需要重跑 prepareloose_count 过高：检查来源发布时间是否过旧、是否有大量雷达源或 fallback 时间条目publish 失败：先看 review-status 是否已是 approved，再检查音频、视觉素材和 FFmpeg 输出- 视频失败：先检查
output/audio/<日期>/ 和 output/visuals/<日期>/cards/ 是否完整
- 发布目录为空：先检查上游 Markdown、HTML、视频文件是否已生成
推荐命令
python main.py setup
python main.py prepare --report-date 2026-04-21
python main.py review-status --report-date 2026-04-21
python main.py status-overview --report-date 2026-04-21
python main.py review --report-date 2026-04-21
python main.py approve --report-date 2026-04-21 --approved-by 主编
python main.py publish --report-date 2026-04-21
python main.py rerun-stage --report-date 2026-04-21 --stage prepare
python main.py rerun-stage --report-date 2026-04-21 --stage publish
python main.py rerun-stage --report-date 2026-04-21 --stage video
python main.py rerun-stage --report-date 2026-04-21 --stage distribute
python main.py schedule --hour 8 --minute 0
完成任务后的输出要求
完成任一操作后，应明确告诉用户：
- 刚刚做了什么
- 产物在哪个目录
- 当前处于
prepare / review / publish 哪个阶段
- 如果执行的是命令面，最关键的
status 是什么
- 若使用了
status-overview，补充说明 source_health、freshness_summary 和 html_fallback_count 是否异常
- 下一步建议做什么
参考资料
