mcpField
E
event-official-social-program

event-official-social-program

github.com/samber生产力45.6k 次安装2 天前更新
代码仓库

关于 event-official-social-program

event-official-social-program 是规划活动官方社交场次数量及其安排的技能。它关注整体规模与包容性底线;单场活动的形式和执行细节由另一项技能负责。

主要功能

  1. 01决定社交场次数量
  2. 02比较整体安排方式
  3. 03检查活动间的无障碍覆盖
  4. 04设定增加场次的条件
  5. 05明确与其他规划技能的分工

适用场景

  1. 01判断是否增加第二场活动
  2. 02规划同时进行的社交活动
  3. 03确保每个时段都有无障碍选项
  4. 04筹划系列活动的社交项目

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/samber/dev-event-organizer-skills --skill event-official-social-program

安装后在 Claude Code 中输入/event-official-social-program确认已加载。

附带文件evals/evals.json

详细介绍

活动官方社交安排

你只决定一件事:活动安排多少场官方社交活动,以及这些活动如何彼此安排。 一场活动、另选时段安排第二场,或者由多场活动组成主题系列。讨论范围仅此而已。

samber/dev-event-organizer-skills@event-hospitality 已经决定了任何单场活动的_形式_。以下事项不在此处重新讨论:

  • 活动形式
  • 餐食
  • 饮品
  • 酒精政策
  • 面向哪些人
  • 活动地点
  • 参加费用
  • 开始和结束时间

已经决定的事项,以及由谁决定

本技能范围有限,因为相邻领域已有负责方。评估任何选项前,请先阅读本节。如果你需要的答案在下面列出,那就该使用其他技能。

  • 任何单场活动的形式完全由 samber/dev-event-organizer-skills@event-hospitality 决定。
    • 其菜单决定“是否安排晚间或社交活动,以及采用何种形式”,并按效率对形式排序:基于场地的交流活动 > 带有活动环节的正式晚宴 > 不安排组织好的活动 > 场外游览或活动。
    • 切勿重新排列这些选项、重命名选项,或另行制定一份菜单。
    • 将该技能给出的答案作为你计划中每场活动的形式。每场活动都使用其菜单评估一次。
  • 选择不安排任何活动也是该技能菜单中的选项,并非由你决定。“不安排组织好的活动”已列在上面的菜单中,而且该技能已经说明,无论选择哪种方案,都要公布决定,因为不公布就会让人们自行前往无人接待的酒吧。因此,_本_菜单的底线是至少安排一场活动。如果坦诚的答案是完全不安排活动,该技能已经给出了答案,本技能无需补充。
  • 每场活动的具体方案由该技能自己的参考文件规定:
    • 负责人
    • “面向所有参会者,还是其中一部分人。”
    • “活动地点,以及选择该地点是否出于无障碍考虑。”
    • “参会者需要支付的费用。”
    • “餐食和饮品”
    • “开始和结束时间”
    • 其称为“适合家庭参与的晚间活动”的无障碍措施
    • 根据上述内容逐场填写。此处不重新规定清单中的任何事项。
  • 酒精政策由该技能决定,并为整场活动统一设定。活动计划不能为每项活动分别设定酒精政策。
  • 由第三方举办的卫星活动归 samber/dev-event-organizer-skills@event-side-event-coordination 负责。该技能从自己的角度说明两者的界限:晚间餐饮款待是你提供的,卫星活动是你允许的。你的活动计划是由活动主办方自行举办的安排。将完成的活动计划交给该技能,作为其协调审批时使用的日程。
  • 仅限受邀者参加以及面向指定嘉宾的款待活动归 samber/dev-event-organizer-skills@event-vip-social-program 负责。面向所有持证参会者开放的活动安排属于本技能范围。需要受邀才能参加的晚宴不属于本技能范围,即使它安排在同一个晚上也一样。
  • 已发布的日程表归 samber/dev-event-organizer-skills@event-schedule-design 负责,其原话是“到已发布的日程表为止”。向其提出活动之间不得重叠的要求。切勿自行安排或移动时段。
  • 是否提供哪些无障碍措施归 samber/dev-event-organizer-skills@event-accessibility-inclusion 负责:即“身体、感官、饮食、经济和数字无障碍措施”。切勿自行编造这些措施。根据其公布的内容检查活动计划。

以下排序是默认方案,而非铁律。它会随着具体情境和执行方而变化。根据你已掌握的信息重新排序,因为以下情况都可能推翻默认排序中的某一项:

  • 社交活动是某一届活动吸引人们参加的主要原因
  • 场地本身已备有第二间房,无需额外提出要求
  • 团队中有一个人事实上默默承担了所有工作的负责人角色

访谈

每次只问一个问题,尽可能采用多选题。之所以有第 6 至第 8 个问题,是因为各个层级在工作量、持久性和见效时间上差异很大。不能替用户选定默认方案。

  1. samber/dev-event-organizer-skills@event-hospitality 是否已经确定了活动形式和对酒精饮品的安排?如果还没有,请先去处理。在得到答案之前,此技能不会对任何方案排序。
  2. 真正列入考虑范围的官方社交活动有几场?有人提出要办第二场,还是你一开始就这么假设?
  3. 无障碍标准公布了哪些无障碍承诺,具体到什么程度?请询问,绝不要自行编造。
  4. 是否会有两场活动在同一时段举行,还是每场活动都会在已公布的日程中占用各自的时段?
  5. 除第一场活动外,每场活动是否都有明确的负责人?请逐场回答,不要笼统地回答整个活动安排。
  6. 工作量上限是多少:志愿者工时、第一场之外的预算额度,以及第二个房间或场地?上一届还留下了什么?
  7. 是一次性活动,还是定期举办,且社交活动也是大家再次参加的原因之一?
  8. 每场活动的场地必须在什么时候确定,无障碍声明必须在什么时候发布?菜单的排序依据是这些日期,而不是活动日期。

活动安排规模

活动举办多少场官方社交活动,以及它们是否会有时间重叠。以下每个层级都假设每场活动的形式均来自 samber/dev-event-organizer-skills@event-hospitality 的菜单,并且每场各自执行一次。

这里的价值是覆盖面:有多少人能在活动安排中找到自己可以参与、也愿意参与的项目。

此菜单、其四条轴线及附带的所有条件,都是此技能自行构建的内容,并非经测量得出的实践经验。应将排序视为默认方案,而不是铁律;问题 2、问题 5 和问题 7 会重新调整排序。

  • 工作量(需指定的负责人、需预订的场地或房间、需确认的无障碍路线、需发布的声明):主题多活动项目 > 分时段举办两场活动 > 单场社交活动
  • 价值、覆盖面:主题多活动项目 > 分时段举办两场活动 > 单场社交活动
  • 合规成本(触发审查、消耗可逆性):主题多活动项目 > 分时段举办两场活动 == 单场社交活动
  • 效率:单场社交活动 > 分时段举办两场活动 > 主题多活动项目

支配关系检查:3 个层级、3 组配对、严格支配关系为零;这个结果只是构建方式导致的,绝不算通过。 计数规则是对列出的 3 个层级进行所有无序配对,不排除任何层级。同一种机制阻断了全部 3 组配对,并且该机制解释了每一组配对,而非只解释其中一部分。

每个层级都是在下一层级的基础上再增加一场活动。因此,工作量和覆盖面沿同一顺序递增,没有成本更低的层级能在价值轴上胜过更丰富的层级。这就意味着测试没有可捕捉的情况,也没有哪个层级会仅因价值较低而落败。应根据问题 2 中的实际活动数量和问题 5 中的实际负责人来检查排序,而不是照搬排名。

“集中度”是活动安排的一项真实属性,但此菜单不会对其排序。 集中度指所有人共同参与同一时刻。按集中度排序时,各层级的顺序是 单场社交活动 > 分时段举办两场活动 > 主题多活动项目,这与按工作量反向排序完全相同。

对集中度排序不会让菜单区分出已有内容之外的任何东西。它唯一的机械效果,是让支配关系检查看起来不再空洞,同时把效率一栏变成按成本从低到高排序。这里会提及集中度,但不对其排序;这样,想要共同参与时刻的读者可以直接为此提出理由。 合规方面的关联是论证依据,而不是回避决策的借口。第二场活动沿用第一场的场地、时段安排和酒精政策,会触发第一场已经触发过的审核:一项场地准入确认、一项许可问题。这些审核只是重复,而非新增,而且可以像之前一样撤销。多活动主题系列则确实高出两个层级,因为跨越多个房间或建筑的并行活动,会让每个场所都需要单独进行准入确认和许可审核;而且,系列一旦发布,人们据此做好安排后,撤回的代价就很高。

  • 单场社交活动,默认选项:一场活动,形式取自 samber/dev-event-organizer-skills@event-hospitality。它在效率上居首,因为系列活动带来的覆盖面从一开始就注定是前置的,而非按某个测量比例分布。无论观众在社交方面有何需求,都会在第一场活动中体现。第二场活动能够触达的每个人,按定义都是第一场活动不适合的人:这是一个逐渐缩小的剩余群体,每增加一场活动,成本大致不变。
    • **晋级条件,以 Q2 和 Q5 为依据,分别评估:**只有两项都满足时才上调一个层级。任一项不满足,都维持在此层级。
      • Q2 表明确实有人提出要办第二场活动,而不是你自行假设的。
      • Q5 为第二场活动指定了负责人。
  • 分时段举办的两场活动:第二场活动安排在另一个时段,沿用第一场活动的场地和政策,面向第一场活动不适合的人。它扩大覆盖面,又不需要并行举办,因此其合规成本与下一层级挂钩。真正的成本是第二位负责人要投入晚间时间,这会落在 samber/dev-event-organizer-skills@event-volunteers 的计算范围内。
  • 主题式多活动系列,效率排序中被挤到最末的层级:它兼顾最高覆盖面和最高投入,因此效率永远不会选它。团队想把社交项目打造成特色时,会选择这一层级。它真正的特点是并行举办,让截然不同的活动得以共存。若人们只有一个晚上的时间,按顺序举办就做不到这一点。
    • **晋级条件,以 Q3、Q5 和 Q7 为依据,分别评估:**只有三项都满足时才晋级。任一项不满足,都维持在此层级以下。
      • Q3 中公布的准入范围包含无法由单一形式同时满足的需求(面向家庭的活动和安静、无酒精的活动,并不是同一个房间里的安排)。
      • Q5 为每项活动分别指定了负责人,而非为整个系列指定一位负责人。
      • Q7 表明该届活动会再次举办,因此该系列的投入会在不同届活动中不断累积。
    • 如果主题式系列成为活动的标志性环节,请将这一决策交由 samber/dev-event-organizer-skills@event-cultural-identity 处理;该技能负责标志性传统,其公开先例会为“让活动独具特色的趣味项目”预留预算。

**删除条件,以 Q5 为依据:**如果 Q5 没有为第一场活动之外的活动指定负责人,就从此菜单和上方的坐标轴说明中删除“单场社交活动”以上的两个层级。删除,而非降级。保留一个已降至最低的层级,会导致计划先按该层级制定,之后却无人负责。samber/dev-event-organizer-skills@event-hospitality 在相同条件下也会删除自己的上层级;在那里,这条规则适用于活动形式,而在这里,适用于活动场次。

**删除,而非降级:发布一份选项清单,却没有说明其中哪一项满足准入底线的系列。**从此菜单和上方的坐标轴说明中删除它。

它看起来像是最慷慨的层级,能给所有人更多选择。但恰恰对底线旨在保障的人来说,这个层级的选择是虚假的。系列安排不会因为内容很长,就自动成为无障碍保障。

活动日程必须达到的包容底线

这是这里唯一无法通过单次活动决策来回答的问题。 这也是这项技能存在的意义。下文的底线是这项技能自行设定的,并非已发布的标准。

samber/dev-event-organizer-skills@event-hospitality 的参考内容已经为单次活动设定了底线:场地是否因无障碍通行而选定、参会者需要承担多少费用,以及适合家庭参与的安排。逐项活动应用这项检查时,即使日程上仍有人无事可做,也可能通过检查。每项活动都单独考虑过,但那些一项活动都无法参加的人从未成为任何单项检查的对象。

日程层面的规则,以底线而非基准的形式表述:在日程安排了任何活动的每个时段,至少有一个选项符合 Q3 报告的无障碍条件集合。 “至少一个”只是底线所能要求的最低数量,并非观察到的做法或推荐数量;这并不意味着数量应高于此。

以下每项后果都属于日程属性,而非活动属性:

  • 如果某个时段的所有选项都无人能参加,那么该时段就把某些人排除在活动之外了,无论其中每项活动的设计有多完善。用三种方式之一解决:为该时段增加一个符合条件的选项、将其中一项活动移出该时段,或缩减日程。绝不能只记录缺口就照常发布。
  • 在日程旁注明哪个选项符合底线。 读者会根据已发布的日程来决定是否出行、安排照护或参加活动,而不是事后才找到的页面。按照 Q3 已发布集合所用的术语,指出哪项活动无台阶通行、适合家庭参与或不提供酒精饮品。
  • 并行安排会造成这个问题,因此 Q4 是用于发现问题的提问。 如果各场活动从未安排在同一时段,日程就不会因选择不足而违反这条底线。它只可能像普通的单次活动那样不达标,而接待服务参考内容已经涵盖了这一点。

将完成的检查交回 samber/dev-event-organizer-skills@event-accessibility-inclusion,由它负责维护该集合及其已发布的细化内容。你要根据它的标准检查日程,而不是设定标准。

收尾活动属于议程,而非剩余时间

日程决策还多了一项单次活动菜单不具备的属性:最后一场环节结束后的活动是否安排了充足时间,还是只能利用超时后剩下的时间。

  • 在快速发展的领域,收尾饮品会成为同行交流彼此上次之后所见变化的时刻。
  • 这是最先被议程超时挤掉的活动,因为时间表上没有任何安排为它保留时间。
  • 如果有人在收尾活动开始前或刚开始时提前离场,这就是一个信号:议程超时了,或者收尾活动从未让人觉得它是活动的一部分。

这会改变什么,以及不会改变什么:

  • 活动的形式、时长、开始和结束时间仍由 samber/dev-event-organizer-skills@event-hospitality 决定。
  • 在下方的执行要求中添加一项保障要求:主议程必须提前结束,为收尾活动留出预留时间。当天负责落实这一要求的提示由 samber/dev-event-organizer-skills@event-run-of-show 提供。

交接内容

你的输出是一份清单:列出各项活动,并为每项活动附上自己的接待安排简报。交接这份清单生成的内容:

  1. 交给 samber/dev-event-organizer-skills@event-schedule-design:不重叠要求,以及保护闭幕活动的要求(§ 闭幕活动是正式议程的一部分,不是剩余时间的安排)。明确指出哪些活动的时间不得彼此重叠,以及哪些活动的时间不得与主议程重叠。将其作为一项要求提出。该技能会负责安排,你绝不能自行移动任何场次或时段。
  2. 交给 samber/dev-event-organizer-skills@event-side-event-coordination:已确认的清单,作为日历,用于协调第三方卫星活动的时间。它无法保护自己不知道的时段。
  3. 交给 samber/dev-event-organizer-skills@event-accessibility-inclusion:上述逐时段底线检查,以及任何未能通过检查的时段。
  4. 交给 samber/dev-event-organizer-skills@event-code-of-conduct:数量和地点,确保适用范围条款涵盖每项活动,而不只是大家都记得的那一项。

在占用第二个场地之前,先提交清单供审批。清单发布后再缩减,就像是在取消活动。

如果你的运行环境有持久记忆,请按届记录:

  • 举办了多少项活动
  • 活动占用了哪些时段
  • 各群体实际参加了哪一项活动
  • 哪个时段未达到底线(如有)

下一届的排序应以这份记录为依据,而不是采用这套默认排序。

失败模式

  • 重新决定此技能无权决定的活动形式。 活动选项由 samber/dev-event-organizer-skills@event-hospitality 负责。用不同措辞对相同层级进行第二次排序,不属于清单决策,而是重复劳动,会让读者不得不在同一组选项的两种排序中做选择。
  • 将卫星活动计入你的清单。 他人举办的活动是允许的,不是你提供的。它应列入时间协调日历,绝不能列入你负责的清单。
  • 因为晚上有空就增加一项活动。 触发条件是 Q2 中的实际请求加上 Q5 中的实际负责人,而不是有一个空闲时段。
  • 逐项检查无障碍活动,然后声称清单已检查。 这正是上述底线检查要防止的失败,而且各项活动在检查过程中都能单独通过。
  • 先发布清单,再发布无障碍说明。 清单一出现,人们就会据此安排行程。稍后发布的说明只能触达仍在做决定的人,而这并不是说明原本面向的群体。
  • 把闭幕活动当作溢出安排。 演讲超时,饮品交流缩短到十分钟,吸引人们返场的同行交流也就此取消。解决办法:向日程安排方提出保护要求,并在流程表中设置明确提示。
  • 让一个负责人独自负责整条活动线。 只有一名负责人的活动线,就是一连串带着乐观假设的安排。Q5 按每项活动分别表述,正是为了发现这种情况。

衡量指标

此技能不提供任何参与人数、活动数量或自身的比例。§ 调用示例中的活动数量和星期几属于用户自己的问题,不是可重复使用的数据。除门槛项外,以下各项均由自己设定,且只有跨届比较才有意义。

  • 时段最低覆盖率(门槛):活动安排表覆盖的每个小时,至少提供一个符合已公布无障碍需求集合的选项。没有适用的阈值;未覆盖时段数为零。
  • 实际举办次数与已安排次数之比(自行设定):没有由负责人 Q5 指定的人在场却仍然举办的活动,正是此菜单的删除条件旨在避免的情况。
  • 闭幕活动留存率(自行设定):大致统计有多少人留下参加闭幕活动,并与参加最后一场活动的人数对比;在活动开始时和中途目测计数。提前离场是需要解读的信号,不是分数。
  • 按人群划分的各场活动参与者(自行设定):这是唯一能判断第二场活动是否触达了第一场未触达的人群的方法,也能据此判断推广条件是否合适。

选一项。活动开始前,写下它会如何影响下一届,然后记录下来。

调用示例

  • “我们已经决定举办一场晚间交流会。还要不要安排晨跑和桌游活动,还是只办一项就够了?”
  • “周四晚上同时安排了三项社交活动。这有问题吗?”
  • “怎样发布社交活动安排,让大家知道自己实际上可以参加哪些活动?”
  • “有人想在第二天再办一场社交活动。什么条件满足后我才能答应?”

预期输出:

  • 一份活动安排表,每场活动都附有自己的接待说明
  • 每个时段的无障碍需求底线检查,并指出任何未覆盖的时段
  • 为日程安排写明的不得重叠要求
  • 决定活动安排深度的增加或删除条件

将输出中的每个要素标明为取自同系列技能,或在此设定。

参考资料

此技能没有参考文件。它唯一需要做的决策就是上述菜单,而参考资料会载明的逐场活动详情,已存在于 samber/dev-event-organizer-skills@event-hospitality 自己的参考文件中。在此重复会造成第二份相互竞争的副本,而本技能正是为了避免这种情况。

另请参阅同系列技能:

  • samber/dev-event-organizer-skills@event-hospitality:决定是否举办社交活动及其形式,设定酒精饮品安排,并规定逐场活动说明。对活动安排表中的每场活动运行一次其菜单;切勿重新排序。
  • samber/dev-event-organizer-skills@event-side-event-coordination:审批并协调由他人举办的活动;接收你的活动安排表,作为其要保护的日历。
  • samber/dev-event-organizer-skills@event-vip-social-program:仅限受邀者和指定宾客参加的聚会,绝不列入这份开放活动安排表。
  • samber/dev-event-organizer-skills@event-accessibility-inclusion:负责制定活动安排表最低标准所依据的无障碍需求集合及其已公布的覆盖深度。
  • samber/dev-event-organizer-skills@event-schedule-design:将活动安排表中的时段安排到已公布的时间表中;接收不得重叠的要求。
  • samber/dev-event-organizer-skills@event-code-of-conduct:负责制定必须适用于活动安排表中每场活动的范围条款。

评论

支持 Markdown