dailypaper-operator

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 setup
• python 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：仍可进入候选，但更适合进入 watchlist
• stale：在 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：首次配置与命令面体检

1. 先运行 python main.py setup。
2. 检查 JSON 返回中的 ok、sources_count、配置路径和默认审核人。
3. 如果配置不完整，优先指导用户修改 config/sources.json、config/profile.json、config/branding.json。
4. 若用户要求继续生成当天稿件，再进入 prepare。

场景 2：准备当天待审核稿

1. 如用户没给日期，默认按今天处理，但要在反馈中明确实际日期。
2. 运行 python main.py prepare --report-date <日期>。
3. 检查 JSON 返回中的 status 是否为 prepared。
4. 优先提醒用户查看 review_summary_path。
5. 若需要解释质量概况，再补跑 status-overview，读取 freshness_summary 和 html_fallback_count。

场景 3：查看审核状态

1. 运行 python main.py review-status --report-date <日期>。
2. 用 status、review_status_input、final_report_exists、publish_task_exists 判断当前停在哪个阶段。
3. 同时查看 recovery_suggestions，明确告诉用户下一步该重跑哪一段。
4. 若用户只想要一句话结论，直接说“当前停在 prepared / in_review / approved / published”。

场景 3.5：看整条产物链与质量概览

1. 运行 python main.py status-overview --report-date <日期>。
2. 检查 artifact_statuses 中哪一层缺失。
3. 查看 source_health：每个来源的 fetch_status、item_count、failure_reason。
4. 查看 event_summary：total_events、multi_source_events、top_events。
5. 查看 freshness_summary、source_tier_summary、html_fallback_count。
6. 结合 recovery_suggestions 给出下一步动作，而不是只说“有文件没生成”。

场景 4：用户已经审核，准备发布

1. 确认目标日期。
2. 若还未批准，先运行 python main.py approve --report-date <日期> --approved-by <审核人>。
3. 再运行 python main.py publish --report-date <日期>。
4. 检查 final-report.json、publish-tasks.json 和 review-task.json 是否已更新为 published。

场景 5：查看当前链路是否跑通

1. 先确认目标日期。
2. 优先执行 python main.py review-status --report-date <日期>，先拿到结构化状态。
3. 如结构化状态还不够，再按顺序检查： 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
4. 明确指出断在哪一层，不要泛泛说“可能有问题”。

场景 6：启动长期运行

1. 先向用户说明调度命令会常驻当前终端。
2. 确认调度时间。
3. 运行 python main.py schedule --hour <H> --minute <M>。
4. 告诉用户调度器默认只执行 prepare，不会自动正式发布。
5. 提醒用户重点查看 output/notifications/<日期>/review-summary.md。

场景 7：端到端完整执行

1. 确认目标日期（默认今天）。
2. 运行 python main.py prepare --report-date <日期>。
3. 执行人工审核：打开审核台或修改 review.json。
4. 运行 python main.py approve --report-date <日期> --approved-by <审核人>。
5. 运行 python main.py publish --report-date <日期>。
6. 如需修改口播稿，编辑 final-report.json 后执行 python main.py rerun-stage --report-date <日期> --stage video。
7. 如需重刷发布目录，执行 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 等价于一次 prepare
• python main.py rerun --report-date <日期> 等价于一次 publish

3. 发现问题时的反馈结构

不要只报错。应按下面结构反馈：

1. 问题出在哪一层
2. 直接原因是什么
3. 下一步应该执行什么

例如：

• RSS 失败：先检查 config/sources.json 的地址是否可访问；若是官方源 RSS 404，改到官方列表页并补 must_match_paths
• prepare 失败：先看是否停在采集、清洗还是候选阶段，再决定是否需要重跑 prepare
• loose_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

完成任务后的输出要求

完成任一操作后，应明确告诉用户：

1. 刚刚做了什么
2. 产物在哪个目录
3. 当前处于 prepare / review / publish 哪个阶段
4. 如果执行的是命令面，最关键的 status 是什么
5. 若使用了 status-overview，补充说明 source_health、freshness_summary 和 html_fallback_count 是否异常
6. 下一步建议做什么

参考资料

• 操作流程参考
• 命令面参考
• 产物与排障参考