supsub-unread

supsub-unread Skill

未读工作流的入口 skill：回答「我有哪些未读」，并完成「概览 → 钻取 → 整体已读」的闭环。涉及的命令跨 unread / sub / focus 三个命令树，本文档按工作流组织。

Prerequisites

• 安装：curl -fsSL https://raw.githubusercontent.com/SupSub-AI/supsub-cli/master/scripts/install.sh | bash（native 安装，装到 ~/.local、支持后台自动更新）；或包管理器 npm i -g @supsub/cli / pnpm add -g @supsub/cli
• 已登录：supsub auth status 显示 Authenticated（首次使用先 supsub auth login）
• 未授权（exit 2 / UNAUTHORIZED）时不要止步于「你未登录」：直接运行 supsub auth login 为用户打开浏览器授权（命令会自动打开浏览器并阻塞等待授权，请用足够长的超时，如 10 分钟；用户只需在浏览器点确认，无需在终端输入任何内容），授权成功后重试原命令。无浏览器 / 无头环境再回退为提示用户 SUPSUB_NO_BROWSER=1 supsub auth login。

已读模型：只有「整体已读」，没有「单篇已读」

这是本 skill 最容易踩错的一点，先记住：

• CLI 能做的只有两件事：sub mark-read --all（这个号我读完了）、focus mark-read --all（这个关注点我看完了）。
• 没有单篇已读。原因是产品侧的：文章在 SupSub 里没有「详情 / 阅读」这一步，也就不存在「用户读完了这一篇」的自然事件，所以 CLI 只保留用户明确表达的整体已读意图。
• 用户说「把这篇标为已读」时：如实说明不支持，再问是否要把整个源 / 整个关注点标为已读。不要试图用 --content-id 绕过（会抛 INVALID_ARGS），也不要靠循环调用伪造逐篇已读。
• 也没有分组级已读命令。用户要「清空某个分组」时：先 group subs 列出组内源，逐个源确认后再逐个 sub mark-read --all，每个源都要在确认范围内。

Workflow（三步闭环）

1. 概览：supsub unread -o json → 一次拿到所有 unreadCount > 0 的订阅源与关注点。
2. 钻取：对用户关心的源/关注点拉未读列表（默认就是未读）：
   • 订阅源 → supsub sub contents --source-id <sid> --type <t> -o json
   • 关注点 → supsub focus contents --id <fid> -o json

   这里用默认（未读）是对的——本 skill 的语境本来就是「我有什么没读」。但若用户中途转成按时间浏览 （「那 X 最近都讲了什么」），要改用 --all 并把 isRead 当标注，详见 supsub-sub / supsub-focus。

3. 整体已读（仅当用户明确表达「读完了 / 清掉」时）：mark-read --all，必须先二次确认（见下）。

翻页策略（不要反复询问用户）

contents 默认一页 20 条（--page-size 上限 100）。按用户意图选择策略，过程中不逐页询问：

• 浏览类意图（「看看有什么未读」）：只拉第 1 页，结合 unreadCount 告知「共 N 条未读，已显示前 20 条」；用户说「继续 / 看更多」再 --page 2。
• 全量类意图（「全部未读」「统计 / 导出」）：自动循环翻页——用 --page-size 100 减少请求数，返回条数 < page-size 即最后一页；unreadCount 可预估页数。这类批量拉取一律加 --brief（只留 contentId/title/时间/已读状态，100 条约 14KB；不加约 90KB，会撑爆工具输出上限被迫落盘）。
• 注意：「清未读」不需要先把文章全部拉下来——整体已读是一条命令的事，拉全量只在用户要看 / 要统计时才做。

--all 二次确认（强制规则）

执行 sub mark-read --all 或 focus mark-read --all 前，必须依次完成：