| 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"
如果因浏览器访问被阻挡或没有可用书签而没有文件改动,不要编造提交;直接报告阻碍或无改动状态。
报告
以以下内容收尾:
- 输出路径
- 候选/来源数量
- 使用的时间窗
- 浏览器/访问状态
- 验证结果
- 提交哈希(当已提交时)