pr-calendar

PR 日历

PR 日历是 PR 规划的一半。newsjack-detector 会监测当下正在发生的新闻；这项技能会查看已知的即将发生的时机，并判断品牌应该围绕哪些时机进行规划、何时开始推介，以及在联系记者之前品牌需要准备哪些证据。

日历源有依据，但价值仍取决于判断。不要只罗列日期。大多数时机都应该被剔除，因为品牌缺乏立足点、切入点过于笼统，或该时机不适合商业化。

这是一个 MOLECULE。它会读取品牌的监测资料，通过 CLI 查询日历 API，筛选出真正的候选时机，检查去年这些时机对应的节点前后出现了哪些类型的报道，并返回一份易读的计划。它不会自行撰写切入角度或推介内容，也不会保存任何内容。

这项技能不会做什么

• 它不会承诺某个神奇的最佳日期或最佳发送时间。请使用时间窗口，而不是虚假的精确度。
• 它不会列出所有纪念日。薄弱或笼统的切入点不是媒体计划。
• 它不会编造日期。本周行动、六个月计划、观察列表和避免中的每个时机，都必须来自日历源或用户明确提供的日期。如果日历源中缺少明显的重要日期，只能在缺口与聚类下注明“日历源缺失；规划前请另行核实”。
• 它不会运行检测器流水线、粗略相关性筛选、报道来源检查或时效性关卡。这是一个规模较小的上下文问题。对日历结果进行一次审慎的 LLM 分析就足够了。

输入

1. 品牌资料。 复用 newsjack-setup 中现有的监测资料或 fixture profile JSON。读取公司描述、主题、搜索词、竞争对手、立足点、发言人、证明材料和市场。除非不存在资料，否则不要重新提问。
2. 规划窗口。 默认从今天起的未来六个月。长周期机会可能已经开始酝酿，因此不要使用更短的默认窗口。
3. 日历源。 有日期的机会来自 newsjack pr-calendar query，该命令会调用 Medialyst 的 PR 日历 API。

如果没有资料，只询问判断所需的四项内容：品牌做什么、它可以可信地谈论哪些主题、能附上哪些证明或数据，以及它面向哪个市场进行推介。

获取日历

Newsjack 通过两种方式访问 PR 日历。按以下顺序尝试，成功后立即停止：

1. CLI 模式（首选）。 如果已安装并通过身份验证，请使用 newsjack pr-calendar query。
2. MCP 模式（备用）。 如果未安装 newsjack CLI 或它不在 PATH 中，但已连接 medialyst MCP 服务，请使用 MCP PR 日历查询工具。它与 POST /api/v1/pr-calendar/query 功能相同，因此请求字段和响应格式与 CLI 相同，只有传输方式不同。

PR 日历端点可免费使用。只有 Medialyst 登录是为了防止滥用。如果实时查询未通过身份验证，请连接 Medialyst 后重试；不要根据记忆构建备用日历。

CLI 模式

在源代码检出目录中使用仓库 shim，否则使用已安装的二进制文件：

bin/newsjack --version
newsjack --version

如果命令未通过身份验证，且你可以访问 shell，请运行：

newsjack login

告知用户打开打印出的 Medialyst 链接并批准 newsjack CLI，然后重试日历查询。

然后为每个档案查询一个范围较广的六个月时间段：

newsjack pr-calendar query --from <YYYY-MM-DD> --to <YYYY-MM-DD> \
  --industry <tech|fin|health|retail|media|food> \
  --limit 100

仅在有助于查询且不会将范围缩得过窄时使用 --query。保持简短且宽泛，通常使用一两个词。对于开发者工具或 AI 软件档案，使用 --industry tech 通常比把整个主题列表塞进 --query 更好。过于具体的查询可能会遗漏有用的会议和季节性切入点。

默认不要使用 --country-code。只有当用户明确想要本地日历时才添加，因为许多全球性活动没有国家代码。

对于与 API 请求结构完全一致的请求，请使用：

newsjack pr-calendar query --json '{"industries":["tech"],"start_date":"2026-06-30","end_date":"2026-12-30","limit":100}'

响应会返回 calendar 元数据和 opportunities。重要的机会字段包括 title、type、industry、start_date、end_date、pitch_start_at、pitch_deadline_at、lead_time_summary、description、pitch_angles、audiences、coverage、source_urls、tags 和 confidence。

MCP 模式

仅当 newsjack CLI 不可用且 medialyst MCP 服务已连接时，才使用此路径。MCP 工具会直接接收 API 请求正文。在大多数运行环境中，该工具名为 mcp__medialyst__query_pr_calendar 或类似名称；如果运行环境提供了不同名称的 PR 日历工具，请使用其描述对应于 POST /api/v1/pr-calendar/query 的工具。

MCP 请求正文：

{
  "industries": ["tech"],
  "start_date": "2026-06-30",
  "end_date": "2026-12-30",
  "limit": 100
}

可用的请求字段与 CLI/API 一致：q、industries、types、tags、audiences、country_codes、start_date、end_date、pitch_start_before、pitch_deadline_after、limit 和 cursor。

使用 MCP 结果的方式与 CLI 结果完全相同：calendar 元数据和 opportunities。如果 CLI 和 MCP 均不可用，请停止并告知用户连接 Medialyst；不要自行编造日历。

候选机会评估

对返回的机会进行一次评估。将每个机会分到以下四个类别之一：

类别	含义	输出处理方式
可直接提案	品牌有充分的专业公信力，并能提供证据、数据、产品事实、客户案例或可信的发言人。	纳入计划。
观察	有一定可能性，但角度较为宽泛。提案前需要专有证据。	仅在有助于用户规划时纳入，并说明需要哪些证据才能提升其类别。
规避	敏感、庄严、政治、医疗、纪念性质，或其他可能让人觉得该品牌在借机营销的机会。	列入“规避”类别并说明原因。
剔除	对该品牌而言，没有正当的媒体切入角度。	除非用户要求列出淘汰项，否则不要逐项列出。

在这一次评估中使用以下判断标准：

品牌公信力。 思考：记者会自然而然地接受该品牌作为与此时点相关的信息来源吗？在大型开发者或企业软件会议上，开发者工具公司可以具有很强的专业公信力。若没有专有的储蓄数据，金融科技公司在世界储蓄日通常应归为“观察”。B2B 物流 SaaS 公司在全国披萨日应归为“剔除”。

证据。 可直接提案的时机需要具体依据：使用数据、基准测试、客户资源、创始人专长、技术研究、产品新闻，或明确的发言人。如果品牌资料中没有证据，应标为“观察”，而不是“可直接提案”。

品牌安全。 避免借纪念日、灾难、严重疾病日、宗教庄严纪念日和争议性政治时刻进行商业营销，除非品牌确有相关公信力，且能提供有尊重的公共利益角度。遵循 skills/ETHICS.md 和 skills/WHY-NOT-SPAM.md。

时机。 优先使用 API 的 pitch_start_at、pitch_deadline_at 和 lead_time_summary。将这些日期与今天进行比较：

• 现在提案表示今天处于提案开始日期与截止日期之间。
• 窗口于 <date> 开启表示提案开始日期尚未到来。
• 已过截止日期表示应转向筹备周期更短的媒体，或跳过。
• 活动临近表示只剩下即时评论、自有内容或筹备周期极短的编辑部门。

适用时，用时间窗口解释媒体的筹备周期，而非视为固定规则：

媒体类别	常见提案窗口
筹备周期较长的杂志和行业媒体	3-6 个月
全国性线上出版物	1-2 个月
周刊杂志	2 周-2 个月
日报纸媒	1-2 周
线上媒体、博客、播客、地方媒体	1-4 周
新闻编辑部	最晚可在当天

节奏安排。 完成分类后，整体审视一次六个月的安排。指出需要常青内容的冷清时段，以及应错开安排的密集周次。

往年报道情况

找到候选项后，使用 news-search 调研去年每个可用于提案或值得关注的候选时机实际获得了哪些报道。这用于获取灵感和校准判断，不是新鲜度门槛。

研究范围要有限：

• 只研究通过常规审核和安全审核的候选项。
• 对于普通的六个月日历，最多搜索排名前 8-12 的候选项。如果候选项更多，优先考虑可用于提案的时机、提案窗口即将开启或关闭的时机，以及品牌契合度最明确的时机。
• 每个候选项进行 1-2 次有针对性的搜索。不要穷尽所有可能的文章。

对每个候选项，推导往年搜索时间范围：

1. 从候选项的 start_date 开始。
2. 将日期往前推一年，作为去年对应时机的大致日期。如果信息源或往年报道明确给出了上一次活动的确切日期，则使用该日期。
3. 搜索周期性活动时，从活动名称中去掉年份，然后从该往年日期前六个月搜索到后六个月。

使用 news-search / newsjack news search，在查询中加入 after: 和 before: 条件。如果缺少 CLI，但 Medialyst MCP 已连接，则使用相同的查询字符串调用 mcp__medialyst__search_news。

newsjack news search --query "\"<moment name without year>\" after:<prior-year-date-minus-6-months> before:<prior-year-date-plus-6-months>" --limit 10

示例：

newsjack news search --query "\"Dreamforce\" \"AI agents\" after:2025-03-15 before:2026-03-15" --limit 10
newsjack news search --query "\"Pumpkin Spice\" coffee after:2025-03-01 before:2026-03-01" --limit 10
newsjack news search --query "\"Black Friday\" \"coffee subscription\" after:2025-05-27 before:2026-05-27" --limit 10

像公关策略师一样解读结果：

• 哪种形式效果最好：趋势报道、实用新闻、数据报道、创始人分析、礼品指南、活动预告、专家评论、本地视角、产品综述，还是行业回顾。
• 哪些证据让内容值得刊发：独家数据、专家渠道、客户案例、研究、产品新闻、调查、价格数据、本地影响力，还是文化时机。
• 哪些媒体和编辑部进行了报道。
• 报道是否确实围绕该时机，还是仅与之略有关联。

利用这些模式完善计划中的角度构想。如果去年的报道大多是礼品指南，就不要提议泛泛的思想领导力文章；应建议准备礼品指南素材并规划好截止日期。如果去年的报道主要是分析师或专家评论，就应建议由合适的发言人提供精炼的专家观点。如果报道稀少或以 SEO 内容为主，就降低信心，或将该时机列入观察名单。

多个档案

对于单个档案，执行一次日历查询和一轮审核。

对于多个档案，不要将它们混在一次大型审核中。应分别处理每个档案。如果运行环境支持子 Agent，则为每个档案启动一个子 Agent，并提供档案 JSON 和相同的六个月时间窗口。每个子 Agent 都应返回所运行的日历命令、所选时机、往年报道搜索、报道模式、应避免的事项，以及信息缺口或聚集情况。只有在这些独立审核完成后，才合并各档案的输出。

输出

按以下顺序撰写易读的 Markdown：

本周行动。 提案窗口已开启、即将关闭或已经错过的时机。优先写出用户下一步该做什么。

未来六个月计划。 表格保持简洁：

日期	时机	立场	角度种子	提案窗口	状态	证据

角度种子用单行表述。它们是提供给 angle-generator 的提示词，不是写好的角度。证据应包含一个来源 URL 或 API 过往报道锚点；此外，在有调查过往报道时，还应附上一条简短的往年报道模式，例如“2025 年的报道大多是礼品指南”或“行业媒体倾向于采用专家评论”。

关注列表。 可选。仅列出有可能适用、但需要更有力佐证材料的时机。

避免。 对敏感或不安全的时机，用一句话说明原因。

空档与聚集。 指出需要填补的平静时段，以及需要错开安排的密集时段。如果品牌的一个重要时机似乎未出现在动态中，只在此处指出。除非用户提供了日期，或你运行了单独的实时查询／来源核查并确认该时机，否则不要将其列入计划。

报道模式。 简要总结往年报道对所选时机的启示。仅用项目符号，不要写成第二份报告。

命令记录。 列出所用的确切 newsjack pr-calendar query 命令或 Medialyst MCP 工具调用、配置文件、登录是否已配置，还是需要先完成登录才能重试，以及用于查询往年报道的 newsjack news search／mcp__medialyst__search_news 查询。

交接

用户选定一个时机后，按现有流程交接。不要在此处重复相关工作：

1. angle-generator——以日历时机作为新闻切入点。
2. find-journalists——为选定角度整理记者名单。
3. 起草，然后进行 fact-check，再运行 voice-extractor，之后才能发送任何内容。

提供一个精简的机器交接内容，作为次要代码块：

{
  "moment": "<name>",
  "date": "<YYYY-MM-DD>",
  "news_peg": "<one-line peg>",
  "standing": "strong",
  "proof": ["<data/customer/spokesperson the brand can attach>"],
  "pitch_window": {
    "start": "<YYYY-MM-DD>",
    "deadline": "<YYYY-MM-DD>"
  },
  "source_urls": ["<url>"]
}

边界

• CLI/API 负责数据： 有日期的机会、来源 URL、过往报道、标签、事件类型和 API 提案窗口字段。
• 新闻搜索负责报道证据： 带日期和出处的往年文章，用于了解此前有哪些内容引起关注。
• 此技能负责判断： 立场、佐证需求、品牌安全、提前期解读、报道模式解读、宣传节奏规划，以及编写易读的计划。
• 下游技能负责执行： 角度、记者名单、草稿、事实核查和声音匹配。
• 默认无状态： 除非用户明确要求将日历、已查看存储或推断出的偏好纳入配置文件或简报，否则不要保存这些内容。