| name | x-bookmark-quote-posts |
| description | 查看用户最新的 X/Twitter 书签，并把近期保存的帖子转成有来源支撑的引用帖（quote-post）草稿。当被要求查看 X 书签、从书签创建引用帖、刷新书签引用队列、运行书签引用自动化，或从 X 来源写第一人称引用帖时使用。 |
X 书签引用帖
概述
把用户最新的 X 书签变成一个带日期的引用帖队列。输出应像某个具体的人或品牌基于亲身经验在公开场合思考，而不是像通用的 AI 评论。
开始
除非用户指定了另一个仓库，否则从当前内容仓库工作。如果没有活跃仓库，在写文件前先索要目标工作区。
收集之前：
- 阅读
AGENTS.md（如果存在或在提示词中提供）。
- 尽早检查
git status --short。内容工作区经常是脏的；把改动保持在窄范围。
- 在存在时，阅读最新的现有书签引用帖文件作为声音样本。常见位置包括
data/x-growth/bookmark-quote-posts/*.md、data/x/bookmark-quote-posts/*.md，或用户指定的内容队列。
- 只对 X 使用 Codex 内置浏览器。不要用 Chrome。
- 不要以任何方式发帖、回复、引用、点赞、转推、私信、关注或改动 X。
如果 X 已登出、被 CAPTCHA 拦截，或内置浏览器无法附着，停止并报告确切的阻碍。仅当浏览器会话要求时才请用户登录。
收集书签
打开：
https://x.com/i/bookmarks
从最新可见的书签信息流收集一个有界批次：
- 提取作者、handle、来源 URL、来源时间戳、可见帖文、文章卡片标题/摘要，以及媒体/上下文线索。
- 默认取书签信息流中最近 30 天的来源帖，除非用户指定了不同的时间窗。按字面理解当前日期/时间和时区。
- 滚动足够多，在 30 天窗口内收集约 12-20 个可用候选，同时保持有界。
- 包含实用的资源清单类书签，而不只是 AI agent 观点。示例模式：一份 Solt Wagner 风格的创意资源、网站和应用清单，如图像生成器、抖动工具、mockup 工具、Framer 模板、dock 组件、运动工具和渐变工具。
- 注意 X 通常暴露的是来源帖时间戳，而非书签保存时间戳。除非保存/收藏的时间戳可见，否则把时间窗清楚地标注为来自书签信息流的来源帖日期。
- 在需要时打开被截断帖子或文章卡片的 status URL 以获取足够上下文。保持收集有来源支撑。
当任务明确是关于书签时，不要依赖公开搜索，除非浏览器访问被阻挡且用户批准了后备方案。
起草
创建或更新：
data/x-growth/bookmark-quote-posts/YYYY-MM-DD.md
在存在时使用现有的项目路径。如果仓库还没有书签队列，创建最小合理的带日期路径，如 data/x/bookmark-quote-posts/YYYY-MM-DD.md。
使用这个结构：
# Bookmark Quote Posts - YYYY-MM-DD
Checked in Codex Browser: https://x.com/i/bookmarks
Window: ...
Tone pass: first-person voice matched to the user or brand. Two or three slightly longer paragraphs, closer to a lived-in note than a stack of punchlines.
## Best Picks
### 1. Source Name - Topic
Source: https://x.com/...
<draft>
写 7-10 篇草稿，除非来源供给较弱。把最强的帖子放在 Best Picks 下；用 Secondary Picks 放备选或置信度较低的来源。在用户相关的主题间偏向多样性，如工具、产品创意、设计资源、技术教训、行业观点、工作流创意和有用资源。
声音
用用户或品牌已确立的声音来写，句子里带更多亲身经验、少些打磨。
使用：
- 在自然贴合时用第一人称
- 每篇草稿两到三段略长的段落
- 直接的语言、粗糙的棱角和人性化的具体
- 来自用户真实领域的过往经验，如构建、设计、教学、发布、销售、调试、研究、运营或从错误中学习
- 当来源单薄时诚实地表达不确定
避免：
- 短句、空行、短句、空行的节奏
- 像"真正的技能是……"这样的通用框架
- 像"说得好"这样空洞的附和
- 像"game changer""unlock""hot take""supercharge"这样的炒作措辞
- 除非用户要求，否则不放 CTA
- 关于用户生活、工作、产品、团队、客户或成果的、在当前提示词、现有草稿或可信项目上下文中没有依据的断言
好的草稿应听起来像是意图中的作者在为来源添加个人语境，而不是在概括它。
验证
提交之前：
- 确保每篇草稿都有来源 URL。
- 确保每篇最终草稿是两到三段，除非有刻意的例外。
- 在心里把文件通读一遍，删掉听起来像 AI 的概括句。
- 运行
git diff --check -- data/x-growth/bookmark-quote-posts/YYYY-MM-DD.md。
- 只暂存目标书签引用帖文件。
当本次运行改动了文件时，从目标仓库提交。使用类似这样的信息：
git commit -m "Refresh X bookmark quote posts for YYYY-MM-DD"
如果因浏览器访问被阻挡或没有可用书签而没有文件改动，不要编造提交；直接报告阻碍或无改动状态。
报告
以以下内容收尾：
- 输出路径
- 候选/来源数量
- 使用的时间窗
- 浏览器/访问状态
- 验证结果
- 提交哈希（当已提交时）
