dev-event-kickoff

开发活动启动

你是 dev-event-organizer-skills 技能集合的入口和路由器，该集合包含 72 项技能。将当前任务准确路由到一个同级技能；如果没有合适的技能，就直接说明，并让下一次会话从温暖状态开始，而不是冷启动。路由是这项技能存在的原因，其他一切都是为此服务的。

这个集合太大，成员无法相互了解。event-sponsor-pricing 中的组织者不知道自己需要的数字来自 event-budget，也无法发现 event-b2b-matchmaking。解决这一发现问题就是全部工作。

每次项目启动时都要运行这项技能，即使这个集合已用于另一场活动的日常工作也是如此：新活动意味着新上下文。在同一项目的后续会话中，重新运行以重新总结和路由，而不是重新采访。

1. 先检测，再提问

你从环境中推断出的每一条事实，都是用户无需回答的问题。先运行检测；只有这样，采访提问次数上限才有意义。

记忆：使用运行环境内置的记忆机制；在不同章节中分别记录任务信息，移除已完成的任务，为任务添加日期，并注明不同任务的采访回复可能有所不同。

1. 只根据一个信号判断是冷启动还是温启动：项目中是否存在上下文文件 event-context.md？存在 → 温启动。不存在 → 冷启动。绝不要询问用户属于哪种情况。
2. 如果可以读取项目的 git 历史记录，请查看近期日志以推断阶段和进度：最近有哪些变更、活动工作是否停滞，以及最近一次提交距离有日期的里程碑还有多远。
3. 清点现有文件——README、Agent 指令文件、预算电子表格、投稿导出文件、价格表、日程网格、场地合同、风险登记表。已提交的价格表可确定赞助状态；已发布的网格则可同时确定活动形式和日期。
4. 如果运行环境提供连接器——git 托管服务、日历、邮件或票务来源、分析来源、文档存储——检测哪些连接器可用，并据此调整路由和常规流程。描述其能力；不要假定具体产品。
5. 如果该集合提供可读取的版本元数据，请注明自上次会话以来有哪些变更；否则静默降级。绝不要因此受阻或询问版本信息。

2. 访谈——限量、可交互

冷启动时，最多提问 5–7 个问题，每条消息只问一个问题，并尽可能提供多选项。只针对检测未能得出结论的内容提问；文件清单或 git 日志已经回答的问题一律跳过。使用交互式提问机制（例如 AskUserQuestion、askuser、Jev，或运行环境提供的其他决策／提问工具），而不是将问题作为纯文本打印出来——纯文本提示会迫使用户用自由文本回复，无法保留结构化选项。不要将此建议与任何模型或运行环境绑定；请泛称这种机制。

1. 本次活动处于哪个阶段？ - (a) 活动尚不存在，或正在决定是否举办；(b) 已决定举办，正在规划；(c) 距离开放入场还有几周，或已在现场；(d) 活动已结束；(e) 正在规划已举办过的某项活动的第 N 届。这是分流点：它决定 § 3 中哪些分流模块适用，后续每个问题都在此基础上进一步缩小范围。
2. 形式是否已确定——活动形态、分会场数量、举办方式——这些信息记在哪里？ - (a) 尚未确定任何内容；(b) 活动形态已确定，其余未定；(c) 已完全确定：说明活动形态、分会场数量，以及线下／线上／混合形式。回答 (a) 或 (b) 表示暂时无法应用形式门槛。
3. 这是单次活动还是第 N 届？团队运营多少个活动品牌？ - (a) 新活动的首届；(b) 单次活动，不打算重复举办；(c) 第 2 届或之后；(d) 运营多个活动品牌，或正在考虑新增一个。此问题决定生命周期门槛；(d) 还会开启品牌组合门槛，无论旗舰活动进行到第几届。
4. 由谁提供资金，谁负责组织？ - (a) 志愿者社区组织者；(b) 由公司出资并拥有自己的活动；(c) 基金会或非营利组织；(d) 混合。此问题决定公司门槛，并影响预算中赞助所占的比重。
5. 本次活动的目标是什么——它与项目目标相同吗？ 冷启动和暖启动时都要询问；项目目标不能代替本次活动的目标。
6. 成果必须在哪个日期前落地？ - (a) 有固定的开放入场日期；(b) CFP、开售或公告截止日期；(c) 赞助预算窗口即将关闭；(d) 没有日期。对于 (a) 至 (c)，请提供具体日期。
7. 这是一次性成果还是长期运行的体系——你的投入上限是多少？ - (a) 一次性，只投入几小时；(b) 一次性，投入一周没问题；(c) 长期运行，每周投入几小时；(d) 长期运行，有带薪员工或专项预算。

提问 6 和 7 是为了排列输出顺序，而非描述项目：落地日期、一次性还是长期运行，以及投入上限会重新排列候选清单（§ 4）和例行工作（§ 7）的顺序。应在此处提问，绝不要在排序时才问——到那时，用户已经选定了方向。将这三项都记录在产物中，以便暖启动时无需再次提问即可重新排序。

暖启动时，只问问题 5。其他所有内容——包括门槛和两个排序依据——均从产物中获取。

3. 路由任务

将说明的会话目标与下方每项技能声明的范围进行匹配。为当前任务准确路由到一项技能。切勿强行匹配：如果没有合适的技能，就明确说明，并指出缺少什么。

这些表格刻意不排序，必须保持原样。范围是匹配测试，而非比例：任务要么属于某项技能声明的范围，要么不属于，因此给各行排序会凭空制造从未存在过的技能偏好。排序应放在下一步的候选列表中（§ 4）。

各行按组织者的决策顺序排列，因为问题就是依次出现的。问题 1 的答案会决定哪些区块生效：（a）启用 A-B；（b）启用 B-I；（c）启用 J-K；（d）启用 L；（e）启用 M，以及下一届重新启用的 A-K 中的区块。

Gate 列。 Gate 用于说明一行在什么条件下才可用：

• hackathon、virtual、hybrid、in-room、conference、workshop——取决于活动形式的决策（Q2）。
• first、recurring、properties——取决于活动生命周期的答案（Q3）；company——取决于资金来源的答案（Q4）。

Gate 为空表示该行始终可用。有一项例外会跨越 Gate：如果 startup-pitch-contest 奖项是无股权要求的现金，则无论活动形式如何，都应将其奖金资格、税务和付款路由到 hackathon-cash-prize。完整矩阵（包括 Q2 尚未确定时的处理方式）见 references/format-and-lifecycle-gates.md。

A. 这场活动是否存在？它是什么？

技能	当任务涉及以下内容时，路由至此	Gate
samber/dev-event-organizer-skills@event-market-fit	概念、受众和价格是否符合真实需求
samber/dev-event-organizer-skills@event-positioning	活动代表什么、面向谁、与哪些替代方案竞争
samber/dev-event-organizer-skills@event-cultural-identity	活动的风格，以及它在每个接触点上的呈现方式
samber/dev-event-organizer-skills@event-first-edition	从零开始确定首届活动的范围并启动	first
samber/dev-event-organizer-skills@corporate-event-strategy	公司投入资金举办这场活动要实现什么目标	company
samber/dev-event-organizer-skills@event-portfolio-strategy	将多个活动品牌塑造成相互促进的整体	properties

B. 活动采用什么形式？

技能	当任务涉及以下内容时，路由至此	Gate
samber/dev-event-organizer-skills@event-format-selection	活动形式、分会场数量、环节组合、举办方式
samber/dev-event-organizer-skills@business-event-formats	公司主办的活动形式：晚宴、峰会、巡回活动、展区	company
samber/dev-event-organizer-skills@workshop-program-design	实操环节或实验室的具体运行方式	workshop
samber/dev-event-organizer-skills@event-learning-expedition-design	带领受众前往主办方自己的场所
samber/dev-event-organizer-skills@hybrid-event-design	同时服务现场和远程受众	hybrid
samber/dev-event-organizer-skills@virtual-event-production	举办完全没有实体场地的活动	virtual

C. 时间和地点

技能	任务涉及以下内容时，请选择此项…	门槛
samber/dev-event-organizer-skills@event-date-selection	选择日期，其他计划都以此为基础
samber/dev-event-organizer-skills@event-planning-timeline	从开场时间倒推的计划，按环节逐项安排
samber/dev-event-organizer-skills@event-venue-sourcing	寻找、考察和协商场地	室内
samber/dev-event-organizer-skills@event-vendor-sourcing	场地未包含的供应商
samber/dev-event-organizer-skills@event-sustainability-plan	估算环境足迹、制定减排措施、编写诚实的可持续发展说明页面

D. 执行人员及规则

技能	任务涉及以下内容时，请选择此项…	门槛
samber/dev-event-organizer-skills@event-code-of-conduct	行为准则及其执行流程
samber/dev-event-organizer-skills@event-risk-management	风险登记表、保险组合、是否继续举办的决策日期
samber/dev-event-organizer-skills@event-volunteers	招募、排班和活动当天的志愿者简报
samber/dev-event-organizer-skills@event-volunteer-experience	志愿者非值班时的关怀、感谢和校友名单
samber/dev-event-organizer-skills@event-team-structure	常设团队及其在各届活动之间的治理	定期

E. 收入——预算和门票

技能	任务涉及以下内容时，请选择此项…	门槛
samber/dev-event-organizer-skills@event-budget	成本明细、收入组合、盈亏平衡、应急储备、现金流
samber/dev-event-organizer-skills@event-ticket-pricing	票价梯度、不同档位的入场权限、退款和转让政策

F. 收入——赞助

技能	任务涉及以下内容时，请选择此项…	门槛
samber/dev-event-organizer-skills@event-sponsor-value-proposition	每个赞助商群体真正能买到什么，以及原因
samber/dev-event-organizer-skills@event-sponsor-pricing	价格表、赞助档位梯度及折扣政策
samber/dev-event-organizer-skills@event-sponsor-prospectus	赞助商阅读的已发布赞助方案文档
samber/dev-event-organizer-skills@event-sponsor-outreach	从全新目标名单到签约确认
samber/dev-event-organizer-skills@event-sponsor-agreement	签署前由法律顾问审核的条款清单
samber/dev-event-organizer-skills@event-sponsor-fulfillment	履行已签署的承诺，并完成活动后的报告
samber/dev-event-organizer-skills@event-sponsor-renewal	续约提议、报价、价格变更和有流失风险的赞助商

G. 议程——演讲环节

技能	任务属于以下情况时，转到此处……	门槛
samber/dev-event-organizer-skills@event-cfp-design	撰写并安排已发布的征稿启事
samber/dev-event-organizer-skills@event-talk-selection	评审并选择征稿收到的投稿
samber/dev-event-organizer-skills@event-speaker-sourcing	寻找并评估征稿之外的演讲者
samber/dev-event-organizer-skills@event-speaker-cold-outreach	邀请已列入候选名单的演讲者
samber/dev-event-organizer-skills@event-speaker-experience	从接受邀请到演讲结束后的致谢
samber/dev-event-organizer-skills@event-speaker-coaching	辅导已接受邀请的演讲者：彩排、演讲与幻灯片反馈、缓解紧张、问答
samber/dev-event-organizer-skills@event-schedule-design	将选定的环节编排成已发布的日程表

H. 议程——竞赛环节

技能	任务属于以下情况时，转到此处……	门槛
samber/dev-event-organizer-skills@hackathon-brief-design	团队据此开展工作的挑战说明文档和规则	黑客松
samber/dev-event-organizer-skills@hackathon-team-formation	参与者如何组队，以及何时确定队伍	黑客松
samber/dev-event-organizer-skills@hackathon-mentoring	导师支持安排，以及遇到困难的团队如何获得帮助	黑客松
samber/dev-event-organizer-skills@hackathon-judging	评分标准、评委分配和评分流程	黑客松
samber/dev-event-organizer-skills@hackathon-cash-prize	奖励内容，以及哪些人依法有资格领取	黑客松
samber/dev-event-organizer-skills@startup-pitch-contest	面向已成立公司的创业路演比赛或演示日

I. 充实会场

技能	适用于以下任务……	门槛
samber/dev-event-organizer-skills@event-marketing-plan	细分受众、渠道、活动日历、预算分配
samber/dev-event-organizer-skills@event-landing-page	面向公众的入口页面及其按日期切换的 CTA 状态
samber/dev-event-organizer-skills@event-social-media	活动自己的渠道，在计划规定的权重范围内
samber/dev-event-organizer-skills@event-attendee-email-sequences	按日期安排的邮件流程、发送频率及文案
samber/dev-event-organizer-skills@event-media-partnerships	与媒体及社群互换曝光的合作
samber/dev-event-organizer-skills@cross-event-promotion	与其他主办方的活动互惠推广
samber/dev-event-organizer-skills@event-press-relations	媒体报道、媒体证件、新闻中心	conference
samber/dev-event-organizer-skills@event-no-show-management	超额预订、候补名单、现场入场、实际人数
samber/dev-event-organizer-skills@event-registration-forecast	预计注册人数、截止日期时的参会人数

J. 按人群照料现场体验

技能	适用于以下任务……	门槛
samber/dev-event-organizer-skills@event-attendee-experience	签到、胸牌、导引、帮助、首次参会者	in-room
samber/dev-event-organizer-skills@event-accessibility-inclusion	活动承诺提供哪些无障碍便利，以及如何接收相关请求
samber/dev-event-organizer-skills@event-hospitality	餐饮、休息、酒精饮品安排，以及是否举办晚间活动	in-room
samber/dev-event-organizer-skills@event-booth-experience	展览区布局、展位等级规格、布展时间表	conference
samber/dev-event-organizer-skills@event-b2b-matchmaking	活动日程中的结构化一对一商务会谈	conference
samber/dev-event-organizer-skills@event-vip-management	需要安排陪同或遵循礼宾规范的特邀嘉宾	conference
samber/dev-event-organizer-skills@event-official-social-program	官方社交活动安排多少场，以及其最低包容性标准	conference
samber/dev-event-organizer-skills@event-vip-social-program	面向公众的活动之外的私人聚会	conference

K. 活动当天

技能	适用于以下任务……	门槛
samber/dev-event-organizer-skills@event-run-of-show	工作人员按分钟执行的活动流程手册
samber/dev-event-organizer-skills@event-production	录制等级、信号路径、视听团队、冗余保障	in-room
samber/dev-event-organizer-skills@event-comms-channels	各类参会者消息应通过哪个渠道传达
samber/dev-event-organizer-skills@event-side-event-coordination	审批在你活动日期前后举办的第三方卫星活动

L. 闭幕之后

技能	适用于以下任务……	门槛
samber/dev-event-organizer-skills@event-feedback	询问参与者哪些内容、通过什么方式以及何时询问
samber/dev-event-organizer-skills@event-debrief	组织团队自己的无责复盘
samber/dev-event-organizer-skills@event-content-repurposing	将采集的素材转化为已发布的作品
samber/dev-event-organizer-skills@event-continuous-improvement	多届活动复盘日志中的趋势	recurring

M. 届次之间

技能	适用于以下任务……	门槛
samber/dev-event-organizer-skills@event-community-building	活动在各届之间维系自己的受众	recurring
samber/dev-event-organizer-skills@event-growth-strategy	逐届扩大规模，或有意不扩大	recurring
samber/dev-event-organizer-skills@tech-podcast-youtube-channel	将常设节目或频道打造为跨届活动的固定项目	recurring

元信息

技能	在以下任务中使用此技能……	门槛
samber/dev-event-organizer-skills@dev-event-career	候选人侧——进入活动策划行业、面试准备、评估录用通知
samber/dev-event-organizer-skills@dev-event-hiring	雇主侧——职位发布和评分卡、面试流程、人才搜寻、薪酬
samber/dev-event-organizer-skills@dev-event-kickoff	此技能：项目启动、签到、“我需要哪个技能”、重新路由

这三行刻意限定得很窄，是叶子路由，绝不是起点。 event-learning-expedition-design 会将餐饮交由 event-hospitality 处理，将多场地物流交由 event-production 处理；event-official-social-program 会将单场活动的餐饮、饮品和形式交由 event-hospitality 处理；event-vip-social-program 会将某位来宾是否符合资格交由 event-vip-management 处理。只有当任务恰好属于它们负责的狭窄范围时才路由过去；将其中任何一个说成不可或缺的核心技能，比不提它更容易造成误导。

阅读格式决策，不要重新做决策。 event-format-selection 负责确定活动形态、分会场数量和交付模式。当 Q2 的答案是 (a) 或 (b) 时，路由至该技能并停止：在它返回结果之前，所有受门槛限制的行都不可用。当答案是 (c) 时，将答案作为门槛列传递，并且不要重新审视。hybrid-event-design 和 virtual-event-production 都位于该决策之后，绝不会替你做出该决策。

严格根据每项技能声明的范围进行区分——绝不要猜测某项技能“可能”涵盖什么。在路由任何可能符合两项技能的任务之前，请阅读 references/skill-routing.md，了解边界对照和有序流程链。

指出缺口之前，先检查任务是否属于 samber 的姊妹集合：

• 开发者内容、文档、开源策略或持续在线的社区 → samber/developer-relations-skills。
• 作为 DevRel 项目开展的系列网络研讨会、办公时间或开发者调查，而非单场活动 → samber/developer-relations-skills@devrel-webinar-program、samber/developer-relations-skills@developer-office-hours-program 或 samber/developer-relations-skills@developer-survey-design。
• 将参会者、注册者或徽章扫描记录导入常设开发者通讯，或通过演讲和展位扩大该通讯的订阅名单 → samber/developer-relations-skills@devrel-newsletter-growth。
• 活动邮件进入垃圾邮件、退信或被拒收 → samber/developer-relations-skills@devrel-newsletter-deliverability。
• 公共 API、SDK、webhook 或应用市场相关问题 → samber/developer-platform-skills。

将上述任何一项表述为建议，而非依赖项——此集合应能继续独立使用。

4. 输出格式

每次都按以下格式交付路由结果：

1. 状态摘要（仅暖启动时）——严格从产物中摘取 5 行：活动身份和形式、日期及活动所在阶段、进行中的工作、最重要的待决策事项、当前限制。
2. 路由——针对当前任务的一个技能（或“没有适用的技能”，并说明具体缺口）。
3. 候选清单——列出当前相关的 5 到 8 个技能，按单位投入所能带来的价值从高到低排序。每个条目占一行，同时说明它要解决的瓶颈和本次会话的成本。不要按成本高低或路由表中的行顺序排序。
4. 链路——当任务确实可以拆解时，按执行顺序列出各步骤，每行说明交给下一步的内容。链路顺序取决于依赖关系，而非效率顺序。没有链路时省略；绝不虚构执行序列。
5. 暂不处理——列出之后会用到的技能，并明确说明其启用条件（例如，event-schedule-design——等 event-talk-selection 返回已接受的列表后）。
6. 缺口——列出当前任务需要但没有任何技能覆盖的事项。如果缺口涉及 DevRel 实践或平台界面，请推荐相应的同级仓库，而不要只笼统指出缺口。

候选清单排序

用户问的从来不是“有哪些技能”，而是“我应该先运行哪个，是否值得投入本次会话”，只有对比价值与投入的比率才能回答。以下九类及其四种维度排序均为本技能自行制定，并非已发布的分类体系。默认类别顺序按单位投入所能带来的价值从高到低排列：

1. 存在性检查 - event-market-fit、event-positioning、corporate-event-strategy、event-cultural-identity、event-first-edition。换来对这场活动是否该举办、以及它是什么的判断；这个判断可能让下面每一类工作都不必进行。代价是花时间阅读已有信号；不预订、不发布、不签署任何内容。
2. 主干 - event-format-selection、event-date-selection、event-planning-timeline，以及依赖它们的形式设计技能（business-event-formats、workshop-program-design、event-learning-expedition-design、hybrid-event-design、virtual-event-production）。换来三项决定，其他所有类别都将在其框架内开展。代价是每项决定各需一场会话，另加一次日历检查；日期一经公布，若要更改就必须付出公众代价。
3. 填满会场 - event-marketing-plan、event-landing-page、event-social-media、event-attendee-email-sequences、event-no-show-management、event-registration-forecast、event-press-relations、event-media-partnerships、cross-event-promotion。换来报名人数，这是其他所有类别默认依赖的输入。代价是从公布活动到开场门这段时间内的一场营销活动，以及之后必须履行的名单授权责任。
4. 资金模型 - event-budget、event-ticket-pricing。换来带日期的盈亏平衡数字，而非一个愿望。代价是一场建模会话；门票售出后，已公布的退款政策就具有约束力。
5. 议程征集 - 演讲环节（event-cfp-design、event-talk-selection、event-speaker-sourcing、event-speaker-cold-outreach、event-speaker-experience、event-speaker-coaching、event-schedule-design）和竞赛环节（hackathon-brief-design、hackathon-team-formation、hackathon-mentoring、hackathon-judging、hackathon-cash-prize、startup-pitch-contest）。换来参与者前来活动的内容。代价是一个不可压缩的征集窗口、一个评审委员会、每位演讲者的后勤安排，以及每位参与者的授权同意。
6. 场地与照护责任 - event-venue-sourcing、event-vendor-sourcing、event-sustainability-plan、event-code-of-conduct、event-risk-management、event-accessibility-inclusion、event-volunteers、event-volunteer-experience、event-team-structure。换来一个适合活动形式的场地，以及在事故发生后仍能履行的承诺。代价是场地考察、协商和经过演练的响应团队；这些事项能否撤销，都取决于他人。
7. 活动当天运营 - event-run-of-show、event-production、event-comms-channels、event-attendee-experience、event-hospitality、event-side-event-coordination、event-booth-experience、event-b2b-matchmaking、event-vip-management、event-vip-social-program、event-official-social-program。换来兑现已经售出的承诺。代价是工作人员、排班表和实体搭建，必须压缩在无法延期的几天内完成。
8. 赞助销售 - event-sponsor-value-proposition、event-sponsor-pricing、event-sponsor-prospectus、event-sponsor-outreach、event-sponsor-agreement、event-sponsor-fulfillment、event-sponsor-renewal。换来门票收入鲜少能覆盖的收入来源。这是所有类别中代价最高的：要按照合作方的日程持续数月推进，要请法律顾问审阅条款清单，还要履行持续到活动结束的义务。
9. 活动之后与届次之间 - event-feedback、event-debrief、event-content-repurposing、event-continuous-improvement、event-community-building、event-growth-strategy、event-portfolio-strategy、tech-podcast-youtube-channel。换来下一届活动的起点。每场会话的成本不高，但收益要等到本届活动结束之后才会显现。

这些维度彼此矛盾，而这恰恰是最难抉择的地方：

• 效率：存在性检查 > 主线 > 坐满场地 > 财务模型 > 活动征集 > 场地与照护责任 > 活动当天 > 赞助销售 > 活动之后与间隔期
• 价值：活动征集 > 坐满场地 > 赞助销售 > 主线 > 场地与照护责任 > 活动当天 > 活动之后与间隔期 > 财务模型 > 存在性检查
• 工作量：赞助销售 > 活动征集 > 坐满场地 > 活动当天 > 场地与照护责任 > 活动之后与间隔期 > 主线 > 财务模型 > 存在性检查
• 合规成本：赞助销售 > 场地与照护责任 > 活动征集 > 活动当天 > 坐满场地 > 活动之后与间隔期 > 财务模型 > 主线 > 存在性检查（无）——签署赞助协议会带来排他性和交付义务，须由法律顾问审核；场地合同和无障碍承诺会让你受制于另一方的条款；同意、奖项资格和评审团利益冲突都需要提前决定；徽章扫描和获批的卫星活动会公开一种立场，之后你就有义务履行；名单授权和以物易物的交付都是对第三方的承诺；门票售出后，退款政策便具有约束力；公布的日期是一项公开承诺。存在性检查不会发布、签署或预订任何内容。

**高效和低成本是两种不同的排序方式，这份清单将这一点展示了两次。**坐满场地在效率排序中高于财务模型，尽管成本更高，因为宣传活动能把时间转化为每个类别都假设存在的投入，而盈亏平衡数字却无法让座位坐满。活动之后与间隔期接近成本最低的类别，却排在最后，因为效率是在当前周期内评估的，而该类别为下一个周期付出成本。

**支配关系审查，在实际适用之处进行。**九个类别共有 36 组无序配对。其中六组不存在权衡——一个类别既更有价值又更便宜——每组都有各自的机制，不会共用同一种机制：

• 活动征集优于赞助销售，以及_坐满场地优于赞助销售_——前置条件倒置：赞助商购买的是接触受众和活动内容的机会，因此两者都必须先存在；这种支配关系来自先后顺序，而非偏好。
• 主线优于场地与照护责任、主线优于活动当天，以及_主线优于活动之后与间隔期_——上游决策杠杆：活动形式、日期和时间线是这三者的输入，因此日期一变就要重新寻找场地，形式一变就会让流程表和回顾描述另一场活动。
• 场地与照护责任优于活动当天——场地先于活动当天：场地合同、行为准则、人员名单和风险登记册决定了活动当天的执行内容，因此在场地尚未确定时写好的流程表必然需要重写。

评估标准只权衡价值和工作量。最后这组配对在合规成本上则反转了——合同和已公布的承诺属于场地这一侧，而非活动当天这一侧——因此，受审批约束而非受工作时数约束的读者会反过来选择。

其余 30 组配对中，每组至少有一个维度与效率排序相悖，因此排序在这些配对上确实发挥了作用。效率排序也不等同于工作量的反向排序；后者会是 存在性检查 > 财务模型 > 主线 > 活动之后与间隔期 > 场地与照护责任 > 活动当天 > 坐满场地 > 活动征集 > 赞助销售，仅首位相同。两种排序一致，就会让排名退化为单纯的从低成本到高成本。

**这种排序最容易忽略的：赞助销售。**它在价值排序中位居第三，在效率排序中位居第八，是所有类别中差距最大的，因为其成本取决于合作方的日程安排。如果不提升它的优先级，优先考虑比率的排序会先坐满场地，却办成一场预算始终无法敲定的活动。

提升条件：Q7 (c) 或 (d)，即有固定的每周工时或有经费支持的员工，可将其提升至第 2 位，因为只有固定团队才能承担持续数月的推进工作；Q6 (c)，即赞助预算窗口即将关闭，无论如何都会将其提升至第 1 位，因为本周期内该窗口不会重新开放。 删除已排除的类别；绝不要把它降到最后一位，因为放在底部的类别会悄无声息地重新成为考量范围。带有解除阻碍条件的类别应连同该条件一起移到“暂不处理”；没有条件的类别则不再提及。

排序是默认顺序，不是铁律。根据访谈和检测刚刚揭示的信息重新排序，并明确说出哪个回答让哪个类别发生了变化：

• Q1a（活动尚不存在）将存在性检查提至第 1 位，并删除赞助销售和活动当天——没有活动可供赞助，也没有活动日可安排。
• Q1c（活动将在数周内举行，或正在现场举办）将活动当天提至第 1 位，并删除存在性检查和活动后及间隔期；Q1d（活动已结束）则反过来，将短名单缩减为仅保留活动后及间隔期。两种情况都是删除，而不是降级。
• Q2a 或 Q2b（形式尚未确定）会将流程缩减为一条路径——event-format-selection——并暂停所有设有前提的行。
• Q3a（首届活动）将 event-first-edition 提至第 1 位，并删除活动后及间隔期中涉及不同届次的条目——没有往届活动可供参考。
• Q3d（拥有多个活动属性）将 event-portfolio-strategy 从活动后及间隔期提至第 2 位——不同活动属性之间的冲突，必须在各自制定计划之前解决。
• Q4a（志愿者组织者）会删除 corporate-event-strategy 和 business-event-formats，并提升赞助销售的优先级，因为门票收入很少能单独填补预算缺口。
• Q4b（由公司出资并拥有活动）将 corporate-event-strategy 提至第 1 位，并降低赞助销售的优先级。
• Q6a（本周期有固定的开门日期）会提升满场、活动节目征集和活动当天的优先级，并将活动后及间隔期移到“暂不处理”。
• Q6b（有征集方案（CFP）或开售截止日期）会将负责该截止日期的活动节目征集或资金模式提至满场之前。
• Q7a（一次性活动，仅持续数小时）会将短名单缩减为存在性检查和主干流程，并删除赞助销售和活动当天。
• Q7d（长期持续运营，配有员工或预算）会将赞助销售和场地与照护责任提升至高于默认的位置。
• 检测结果也会改变类别排序：预算已确定时，资金模式几乎无需处理；活动日程已发布时，删除 event-schedule-design；场地合同已签署时，删除 event-venue-sourcing 并提升 event-risk-management。

5. 上下文文件

在项目根目录创建或更新 event-context.md——一个经过版本控制的文件；如果项目使用 git，就与项目一同提交。这是让下次启动能够快速进入状态的唯一事实来源，也是快速启动时读取各项前提条件的地方。

• 快速启动时：读取该文件，不要重建。生成 5 行状态摘要，追加一行会话日志，并且只修补发生变化的字段。
• 可选：在项目的 Agent 指令文件中加入项目不变量——形式、日期、资金模式——这样后续会话无需加载此技能也能继承这些信息。
• 不要为项目搭建它尚未需要的工作树；过早搭建结构会将尚未作出的决定硬编码下来。
• 只有当项目积累了存在争议的决定时，才保留决策日志；否则，“已决定与待定”字段就足够了。
• 开始第 N 届活动前，归档上一届的文件；绝不要覆盖它。复盘和趋势分析都需要了解上一届作出的决定。

字段、完整示例和反面示例见 references/context-artifact.md。每次会话结束前都要更新该文件——未写入的会话会让下次启动变成冷启动。

6. 记忆

如果你的运行环境支持持久化记忆，请从上下文文档中提取记忆条目——绝不要反过来。上下文文档始终是事实来源，因为队友看不到也无法审查记忆；优先从记忆出发会让项目状态按用户分叉。

• 面谈结束后、§ 4 输出前，保存面谈答复：先将答案写入上下文文档，再从中提取记忆条目。无论答案看起来多么显而易见，都绝不要直接根据答案写入记忆。

记忆只能存放在以下三个位置之一，而且这三个位置都需要同一个索引文件，列出每个条目并附上一行说明。按以下顺序选择，优先考虑单位设置工作量的价值最高者：

1. 项目 git 仓库中的 memories/ 目录。 设置工作只是创建目录和索引文件；共同组织者可以在他们本来就会查看计划的地方阅读记忆，而且每次变更都会以可审查的差异形式提交。
2. 团队知识库。 能触达从不打开仓库的志愿者、赞助方联系人和场地工作人员。需要在组织团队之外设置访问权限，而且由于页面与提交之间没有关联，内容容易逐渐偏离。
3. 用户本地环境。 设置成本几乎为零，但其他人都无法阅读。仅在一人独自组织时使用——第二位组织者加入后，按用户存储就会让项目状态分叉；而组织者更替正是这套资料最常应对的问题。

• 效率：git repository > team knowledge base > local environment
• 覆盖范围：team knowledge base > git repository > local environment
• 设置工作量：team knowledge base > git repository > local environment

如果项目已经位于 git 仓库中，默认选择 git 仓库；如果需要记忆的人不在仓库中工作，则选择知识库。

• 在重新启动时，将记忆与上下文文档进行差异比较。如果两者不一致，提出协调方案——默认以上下文文档为准；覆盖任一方前都要先询问。
• 绝不要将以下内容写入记忆：任何类型的参会者或演讲者个人数据、无障碍便利请求及其背后的情况、行为准则报告及其中涉及的身份、协商中的赞助方和场地费率，以及任何仍在协商中的合同条款。首次写入记忆时，说明这一排除项。
• 当记忆存放在 git 仓库中时，绝不要悄悄提交。每次都先展示差异并获得批准。

7. 例行流程

如果你的运行环境支持定时例行流程，请提出 2 到 4 项；每一项都先以试运行形式展示给用户，并明确指定输出渠道——没有输出渠道的例行流程只会制造噪声，用户一周内就会将其静音。例行流程的成本不在设置，而在每次触发时占用的注意力乘以触发频率；它的价值则在于，能在人们仍有机会作出决定时，将该决定摆到他们面前。按这一比率从高到低排序，并从最优先的开始提出。

以下六个候选项是此技能自行构建的内容，并非标准例行流程集合：

1. 票务进度检查 → samber/dev-event-organizer-skills@event-market-fit。读取票务系统本就会生成的数字，并与项目已发布的检查点进行对照。只有这项例行流程能在款项仍可退款时触发暂缓、转向或停止。
2. 倒排计划检查点 → samber/dev-event-organizer-skills@event-planning-timeline。在计划日历中的每个重新规划检查点触发。其输出会在缩减范围仍比更改日期成本低时缩减范围。
3. 重新调用启动流程 → 此技能。每次触发的成本近乎为零。它会保持产出物和路由信息的最新状态，避免其他例行流程对已不存在的工作反复触发。
4. 是否继续审查 → samber/dev-event-organizer-skills@event-risk-management。在场地取消费用曲线的每个阶梯之前一步设定，而非设在阶梯上。它在这组流程中的合规风险最高：该决定具有合同效力，无法撤回。
5. 届次后趋势分析 → samber/dev-event-organizer-skills@event-continuous-improvement。复盘完成后触发一次，并综合分析多个届次。至少有两个届次后才能触发。
6. 赞助商管道与续约检查 → 对上一届的赞助商使用 samber/dev-event-organizer-skills@event-sponsor-renewal，对全新赞助商使用 samber/dev-event-organizer-skills@event-sponsor-outreach。根据管道中已有记录的预算窗口触发。它的持续成本最高：它列出的每个账户都需要有人跟进。

• 效率：票务进度检查 > 倒排计划检查点 > 重新调用启动流程 > 是否继续审查 > 趋势分析 > 赞助商检查
• 价值：是否继续审查 > 票务进度检查 > 赞助商检查 > 倒排计划检查点 > 趋势分析 > 重新调用启动流程
• 工作量：赞助商检查 > 是否继续审查 > 倒排计划检查点 > 趋势分析 > 票务进度检查 > 重新调用启动流程
• 合规成本：是否继续审查 > 赞助商检查 > 票务进度检查 == 倒排计划检查点 == 趋势分析 == 重新调用启动流程（无） - 取消或延期会触发场地的取消费用曲线和保险理赔，而法律顾问和经纪人都参与了这一决定；检查结果会列出账户和协商条款，因此其渠道必须符合项目的数据规范。最后四项并列为零，因为每项都读取内部产物——销售数据、时间线、复盘日志、上下文文件——不会向团队外发布任何内容，也不需要审批。

在实际使用场景中进行支配关系审计。 六项例行流程共有 15 个无序配对。其中四项没有权衡，各自都有明确的机制：

• 是否继续审查优于赞助商检查 - 已承诺的资金优于尚未承诺的资金：审查保护的是已为合同固定日期投入的支出；检查则追逐尚未承诺的收入，成本与名单长度成正比。
• 票务进度检查优于赞助商检查 - 读取数据不等于执行任务：进度检查查询的是无论如何都会记录的数据；检查会实际开展外联，并需要有人发送外联消息。
• 票务进度检查优于倒排计划检查点 - 现成的工具更胜一筹：进度检查只需查询，检查点则要求团队重新汇总并缩减范围；而且进度检查触发得更早，处于仍可退款的窗口内。
• 票务进度检查优于趋势分析 - 当届改进胜过跨届改进：进度检查会影响本届；趋势分析影响下一届，且必须等一届结束后才能触发。

与 § 4 中相同的注意事项：评判标准是价值与工作量的对比，而前四项中第一项在合规成本上恰好相反——是否继续审查是唯一一项输出具有合同效力的例行流程。其余 11 对至少在一个维度上有所取舍。效率排序也并非与工作量的倒序完全一致：若按工作量倒序，重新调用启动流程会排在首位，而它在此处排第三。

这种排序会牺牲什么：赞助商检查。 它的价值排名第三，效率排名末位，因为其成本随管道规模而增长，而非随触发次数增长。 推广条件，以 Q6 为准：答案为 (c)，赞助商预算窗口即将关闭时，优先安装该项；以 Q7 为准：答案为 (d)，有经费支持的员工时，在默认位置上即可负担得起。

默认：第 1 至 3 项，共三个例行任务。切勿超过 4 项——上限能保护真正重要的例行任务，避免它们被那些无人响应的任务淹没。

根据访谈重新排序，并说明哪个答案调整了哪个例行任务：

• Q6a（日期固定的开场日）会优先安装倒排检查点；Q3a 或 Q3b（首届或一次性活动）会删除趋势分析，而不是将其降级，因为没有下一届可供调整；Q3c 或 Q3d 则会恢复该项。
• Q1a（活动尚不存在）只会安装一项例行任务，即重新执行启动流程；Q7a（一次性活动，仅有数小时）也会如此。
• 磁盘上有已签署的场地合同，会将是否继续审核提升至第 1 项，因为取消成本曲线此时已成为现实；未检测到票务数据源则会直接删除票务进度检查，因为没有可查询的数据。

将每个触发条件锚定到活动已有的日期——征稿截止日、开售日、场地的取消节点、开门时间、复盘日——绝不要锚定到任意日程；并为每项例行任务设定停止条件：

• 添加新例行任务前，先停用上一届的例行任务。
• 如果运行环境没有已安排的例行任务，则退而使用一条循环日历提醒（“活动检查——重新运行活动组织者启动流程”），并就此为止。有关试运行格式、日历锚点和清理规则，请参阅 references/routines.md。

8. 覆盖缺口

集合中没有技能涵盖以下内容。指出缺口；绝不要承诺或捏造技能：

• 报名和票务系统运营——平台选择、结账、现场售票处、退款处理、收入税务处理。event-ticket-pricing 负责定价并编写退款政策；event-landing-page 会将 CTA 接入现有系统。
• 会议论文集和论文分会场——以发表论文而非获得演讲时段为目标的同行评审。event-talk-selection 只评审演讲提案。
• 社区奖项计划——提名、评审团、作为活动环节的颁奖典礼。startup-pitch-contest 和 hackathon-judging 分别依据各自的参赛规则评审一项竞赛；两者都不是奖项计划。
• 以两种语言开展活动——翻译后的分会场、双语主持人、按语言标注。event-accessibility-inclusion 涵盖按需提供的无障碍口译和字幕，而不是将第二语言作为设计选择。
• 将参会者的旅行和住宿作为一项计划来安排——协商酒店房间配额、预订旅行、为大量参会者办理签证邀请函。event-venue-sourcing 会审阅场地合同中的房间配额条款；event-registration-forecast 会根据参会人数区间估算配额所需的房晚数；event-speaker-sourcing 只会为一位受邀演讲者标记签证办理所需的提前时间。

按设计不在范围内，而非覆盖缺口：参加活动而非举办活动、赞助他人的活动、在自己不拥有的展区参展，以及在活动上演讲。

9. 调用示例

• “开始一个新的活动项目——我们想在明年春天举办首届黑客马拉松。”
• “我需要哪项活动技能？赞助商总在问他们具体能得到什么。”
• “运行我的活动检查。”
• “我们该从哪里开始？我们已经有日期和场地，其他什么都没有。”
• “会议上周结束了。现在该做什么？”

10. 失败模式

• 强行匹配。 把最近的技能硬套到它并不涵盖的任务上，会浪费一次会话，也会掩盖能力缺口。请说明“没有合适的”，并指出缺口；或者，如果任务属于 samber/developer-relations-skills 或 samber/developer-platform-skills，就指向相应技能。
• 重新决定格式。 各个关卡读取 event-format-selection 的答案，不会自行给出答案。将“我们是否应该采用混合形式”路由到 hybrid-event-design，等于把用户交给一个假定决策已做出的会话，而用户原本正是要在该会话中做出这个决策。
• 对尚未确定的格式应用关卡。 如果 Q2 的答案是 (a) 或 (b)，所有受关卡限制的行都不可用。应路由到 event-format-selection 并停止，不要为了启用这些行而猜测形式。
• 把叶子路由提升为主路由。 § 3 中刻意划分的三个窄范围行，会将大部分相关主题交给同级技能。把其中任何一个作为核心呈现，会让用户只看到一小部分内容，而真正的决策由同级技能负责。
• 暖启动时重复提问，或冷启动时超过上限。 设计这个产物就是为了避免重复提问；超过七个问题后，启动流程就会变成用户会放弃填写的表单。通过检测来填补缺口——已确定的预算或已发布的日程表，能回答的问题比任何提问都多。
• 根据猜测的范围进行路由。 只根据明确声明的范围进行路由；看似合理的猜测也可能自信地把用户引向错误方向。
• 按分组路由，而非按主题路由。 有一组应根据评判的对象进行区分：活动期间完成的作品（hackathon-judging），还是活动前就已存在的公司（startup-pitch-contest）。另有两组应根据用户处于边界的哪一侧进行区分：你方的卫星活动，还是另一位组织者的活动（event-side-event-coordination 与 cross-event-promotion）；你方的渠道，还是另一家媒体的渠道（event-social-media 与 event-media-partnerships）。
• 没有输出渠道的例行事项，或永不退役的例行事项。 它们会无声无息地触发并被屏蔽，掩盖唯一真正重要的例行事项；活动总有结束时间，因此几乎所有例行事项都需要停止条件。
• 扁平的候选名单，或由最便宜选项领头的名单。 看起来不分高下的选项会凭个人喜好或排列顺序被选中，而便宜与高效是不同的排序标准。
• 给路由表或链条排序。 范围是匹配测试，链条是依赖顺序；对其中任何一者强加比例，都会凭空创造不存在的偏好。
• 把已排除的类别降级，而不是删除。 将它放在候选名单底部，过两次会话后它又会以范围的形式出现。
• 悄悄提交记忆，或让记忆包含个人信息。 共同组织者无法审核他们从未看到被记录的内容；出席者数据、便利安排请求和行为举报绝不能进入记忆。
• 路由表过时。 每当技能集发生变化——新增、重命名、移除或重新划定范围——都要更新此技能，包括表格、关卡、参考文件和缺口列表。过时的路由器会把用户引向已不存在的技能，这比完全没有路由器更糟。

11. 通过标准

结束会话前，逐项检查。任何一项未通过，都要修正并重新检查；切勿在未通过的情况下结束会话。

1. 每项推荐技能的声明范围都与所述任务相符——重新阅读其描述并确认。
2. 没有任何路由指向 § 3 中表格以外的名称。
3. 每项应用的门槛都来自某个答案或某项产物，绝非根据事件名称或用户语气推断。
4. 访谈未超出上限：冷启动时最多七个问题；暖启动时仅询问会话目标。
5. 会话结束前，已编写或更新 event-context.md，并添加一行会话日志。
6. 每项提议的例行操作都以试运行形式展示，并设有输出渠道和停止条件。
7. 候选清单和例行操作集都按单位投入所产生的价值排序；每个条目都说明所针对的瓶颈和所需成本；如果某个答案使内容偏离默认位置，就要明确说明重新排序。
8. 每个排除的类别都已彻底移出候选清单；路由表和任何链均未排序。