x-bookmark-quote-posts

X 书签引用帖

何时使用此技能

此技能专用于特定语气：它会将草稿调整为某个 X 账号既有的第一人称语气，而不是生成泛泛而谈的评论。适用于以下场景：

• 查看用户最新的 X 书签，并将其整理为有来源依据、注明日期的引用帖草稿。
• 在起草前，先根据该账号最新发布的 100 条原创帖、回复和引用帖校准草稿语气。
• 刷新或维护带日期的书签引用帖队列文件，例如 data/x-growth/bookmark-quote-posts/YYYY-MM-DD.md。
• 生成一组按优先级排序的 7-10 条引用帖草稿（最佳选择 / 其他选择），以及供用户反馈的建议推文摘要表。
• 在严格遵守不发帖、不回复、不进行任何更改的规则下，使用 Codex 应用内浏览器操作 X。
• 不适用于一般 X/Twitter 数据收集，例如搜索推文、查找用户、提取关注者、下载媒体、监控，或在不进行语气匹配起草的情况下发帖、点赞或发送私信。如需原始 X 数据访问，请改用本仓库的 x-twitter-scraper 技能。

概述

将用户最新的 X 书签整理为带日期的引用帖队列。生成的内容应像某个具体的人或品牌在公开分享基于亲身经历的想法，而不是泛泛而谈的 AI 评论。

开始

除非用户指定其他仓库，否则使用当前内容仓库。如果当前没有活动的仓库，在写入文件前询问目标工作区。

收集内容前：

• 阅读 AGENTS.md（如果该文件存在或在提示中提供）。
• 尽早检查 git status --short。内容工作区经常存在未提交更改；请将改动范围控制在所需范围内。
• 如有最新的书签引用帖文件，阅读该文件以保持内容连贯性。常见位置包括 data/x-growth/bookmark-quote-posts/*.md、data/x/bookmark-quote-posts/*.md，或用户指定的内容队列。不要将生成的草稿作为主要语气来源。
• 仅使用 Codex 应用内浏览器访问 X。不要使用 Chrome。
• 不得在 X 上发帖、回复、引用、点赞、转推、发送私信、关注，也不得进行任何其他更改。

如果 X 已退出登录、受到 CAPTCHA 验证码阻拦，或应用内浏览器无法连接，请停止并报告具体阻碍。只有在浏览器会话要求用户登录时，才请用户登录。

从 100 条帖子中校准语气

在收集书签前先进行校准。根据请求或当前 X 个人资料确定目标账号，然后打开该账号和 X 的「Latest」搜索：

https://x.com/<handle>
https://x.com/search?q=from%3A<handle>&src=typed_query&f=live

如果 X 提供的历史记录足够，收集该账号最新的 100 条原创帖子。包括原创帖子、回复和引用帖子；排除他人发布的纯转发。每条帖子都保留：

• 原创帖子 URL 和时间戳
• 完整的原创文本
• 是否为回复，以及是否包含引用来源
• 引用帖的引用来源 URL
• 时间线文本是否被截断

直接展开每条被截断的原创帖子。如果 X 不允许完整展开，请报告未完整展开的数量，不要默默将片段当作完整帖子。不要把引用来源的文本误认为是用户自己的文本。如果可用的原创帖子少于 100 条，则使用所有可用帖子，并报告实际样本量和日期范围。

根据完整语料建立内部语气记录：

• 通过回复了解自然用词、大小写、缩写、句子节奏、表达异议的方式和不拘小节之处。
• 通过独立帖子了解吸引读者的开场、段落长度、节奏、列表、论据和结尾。
• 将引用帖视为格式特定的权威样本，了解用户如何回应来源并补充背景。
• 区分可复用的模式与一次性内容，例如粘贴的提示词、文字稿、链接列表或异常冗长的公告。保留其中的事实信息，但不要让它们决定通常的表达节奏。
• 通过统计来衡量，而非主观假设：样本量和日期范围、格式占比、中位长度、常见段落数、第一人称使用频率、列表使用情况，以及反复出现的开场和结尾方式。
• 模仿表达方式，不要照搬具体措辞。绝不要拼接多条帖子的片段来撰写草稿。

将最新的 100 条原创帖子作为主要语气来源。仅使用之前生成的草稿来保持队列连贯。当实时语气证据与下方通用写作默认规则冲突时，以实时语料为准。

收集书签

打开：

https://x.com/i/bookmarks

从最新可见的书签信息流中收集一批有限的内容：

• 提取作者、账号名、来源 URL、来源时间戳、可见帖子文本、文章卡片标题／摘要，以及媒体／上下文线索。
• 默认收集过去 30 天内书签信息流来源帖子的内容，除非用户指定其他时间范围。按字面使用当前日期／时间和时区。
• 适度滚动，在这 30 天范围内收集约 12–20 条可用候选内容。
• 收录实用资源列表类书签，不要只收录关于 AI Agent 的观点。例如，类似 Solt Wagner 风格的创意资源、网站和应用列表，可包含图像生成器、抖动工具、样机工具、Framer 模板、Dock 小组件、动效工具和渐变工具。
• 注意，X 通常提供的是来源帖子的时间戳，而非书签保存时间戳。除非能看到保存／加入书签的时间戳，否则请明确标注该时间范围指的是书签信息流中来源帖子的日期。
• 如需获取足够的上下文，可打开状态 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: ...

Voice sample: latest <count> authored posts from <date> to <date>; <standalone> standalone posts, <replies> replies, <quotes> posts with quoted sources. Reply and quote counts may overlap.

Tone pass: first-person voice matched to repeated patterns in the live 100-post corpus.

## Best Picks

### 1. Source Name - Topic

Source: https://x.com/...

<draft>

撰写 7-10 条草稿，除非来源内容不足。将最出色的帖子放在 Best Picks 下；将备选稿或来源可信度较低的内容放在 Secondary Picks 下。尽量涵盖用户相关主题的多样性，例如工具、产品创意、设计资源、技术经验、行业观点、工作流创意和实用资源。

将每条完成的草稿都视为建议的引用推文，用户可以继续打磨。保存的文件是完整队列，但助手回复应直接展示最出色草稿的正文，方便用户在不先打开文件的情况下进行反馈、改写或要求调整角度。

语气

采用用户或品牌一贯的语气，让句子体现更多亲身经验，少一些修饰。

使用：

• 自然合适时采用第一人称
• 遵循用户独立帖子和引用帖中观察到的段落数量与长度分布
• 直白的表达、不刻意修饰的语句和具体的人情味
• 来自用户真实领域的过往经验，例如构建、设计、教学、发布、销售、调试、研究、运营或从错误中学习
• 来源有限时坦诚表达不确定性

避免：

• 短句、空行、短句、空行的节奏
• “真正的技能是……”之类的泛化框架
• “说得好”之类空洞的赞同
• “改变游戏规则”“解锁”“热门观点”“大幅提升”等炒作式表达
• 用户近期内容中没有出现的工整对称、抽象结论或重复套用的开头
• 除非用户提出要求，否则不要添加行动号召
• 不要声称用户的生活、工作、产品、团队、客户或成果情况，除非当前提示、现有草稿或可信的项目上下文中有依据

优秀的草稿应听起来像目标作者在来源内容中加入个人背景，而不是在概述来源。

验证

提交前：

• 确保每条草稿都有来源 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"

如果浏览器访问受阻，或没有可用书签，导致文件没有变更，不要捏造提交；如实说明阻碍或无变更状态。

报告

最后列出：

• 输出路径
• 候选项／来源数量
• 使用的时间范围
• 浏览器／访问状态
• 语气语料数量、日期范围和格式构成
• 验证结果
• 提交时的提交哈希
• 一张展示最出色的建议引用帖的 Markdown 表格，通常包含 3-5 行，列如下：
  • Pick
  • Source
  • Suggested tweet
  • Why this angle
  • Hone next
• 第一行放当前最出色的建议。Suggested tweet 单元格应包含实际推文草稿，而非摘要。需要保留两到三个段落时，在单元格中使用 <br><br>。
• 让表格便于修改：Why this angle 用一句话说明编辑上的取舍，Hone next 则指出最可能需要改进之处、可能的异议或缺失的具体细节。
• 如果浏览器访问受阻或没有找到可用书签，不要捏造建议推文表格。说明阻碍，并注明本次运行没有基于来源的建议。

参考

• 上游来源：MengTo/Skills — x-bookmark-quote-posts
• [agents/openai.yaml]（agents/openai.yaml）— 此技能在 OpenAI 界面上的显示名称、简短描述和默认提示词。