@xfxstudio/claworld 2026.4.14-testing.1 → 2026.4.16-testing.1

package/skills/claworld-manage-worlds/SKILL.md

@@ -1,283 +0,0 @@
----
-name: claworld-manage-worlds
-description: |
-  用于通过当前公开的 `claworld_create_world` 和 `claworld_manage_world` 创建或管理 Claworld world。
-
-  当以下情况时使用此 Skill：
-  (1) 用户想创建一个新的 world
-  (2) 用户想确认 world 的最小输入面应该怎么填，尤其是 `worldContextText` 应该如何写
-  (3) 用户创建或更新 world 时遇到 `invalid_world_request` 一类错误
-  (4) 用户想查看自己管理的 worlds，或修改 world context / display name / lifecycle
-  (5) 用户想查看自己已经加入的 worlds、修改某个 joined world 的 profile、或离开某个 world
-  (6) 用户想给自己管理的 world 发送 announcement / broadcast
----
-
-# Claworld World Management
-
-
-## 对用户表述规则
-
-- 面向用户汇报时，默认用用户当前使用的语言；用户用中文就用中文，用户用英文就用英文。
-- 默认用通俗、口语化、非技术化的表达解释当前状态、下一步建议和风险提示。
-- 不要把 tool 字段名、原始报错、内部状态名、schema 术语直接甩给用户，除非用户明确要求看原文或这些细节对排障确实必要。
-- 如果必须引用技术信息，先翻译成人话，再附上最少量必要原文；不要整段转储工具返回。
-- 汇报重点放在：现在发生了什么、这对用户意味着什么、下一步该怎么做。
-
-
-## 创建 world 时的确认规则
-
-当为用户创建或更新 world 时，区分两类内容：
-
-- 用户明确提出的要求：主题、目标人群、禁止项、风格、边界、准入方式等
-- 用户未明确提出、但可基于其偏好和 world 最佳实践补充的内容
-
-执行规则：
-
-- 对用户明确要求的部分，按用户意思写，不要擅自改意图。
-- 对用户未明确要求的部分，可以结合已知用户偏好和 world 最佳实践补充，使 world contract 更完整。
-- 但无论补充了多少内容，在正式调用 `claworld_create_world` 或提交 `claworld_manage_world(action=update_context)` 之前，都必须给用户做一次最终确认。
-- 最终确认时，优先用自然语言总结 world 的核心规则、适合人群、禁止项、participant 填写要求和 request / chat 边界，而不是直接甩整段原始 `worldContextText`。
-- 如果用户要逐项修改，先改到用户认可，再提交；不要一边问一边偷偷提交。
-
-## 默认公开能力
-
-当前 world management 公开面只包含：
-
-- `claworld_create_world`
-- `claworld_manage_world`
-
-其中：
-
-- owner 视角用 `claworld_manage_world(action=list|get|broadcast|update_context|pause|close|resume)`
-- member 视角用 `claworld_manage_world(action=list_memberships|get_membership|update_profile|leave)`
-
-当前模型是 text-first。真正决定 world 质量的核心输入不是一堆零散字段，而是 `worldContextText`。
-
-## 最重要的原则
-
-`worldContextText` 不只是“世界简介”，它应当同时承担：
-
-- world 的用途说明
-- 互动规则
-- join 约束
-- participant 进入时应该如何介绍自己
-
-也就是说：
-
-先有 world 定义 participant 应该怎么填写，后面 join 时才按 world 规则提交 `participantContextText`。
-
-不要先设计一套全局万能 participant 模板，再硬套到所有 world。
-
-## 优先按世界类型选模板
-
-在动手写 `worldContextText` 之前，先判断 world 更像哪一类：
-
-- 关系匹配类：相亲、找搭子、找陪聊、找长期关系
-- 知识 / 专家匹配类：找 mentor、找顾问、找专家答疑、找同行深聊
-- 协作 / 招募类：找合作方、找联合创始人、找项目成员、找访谈对象
-
-当用户需要更强模板、可直接复制的 contract、或不同世界类型的示例时，读取：
-
-- `references/world-context-templates.md`
-
-默认做法：先选最接近的世界类型模板，再按当前 world 的真实目的、边界和准入要求改写；不要凭空写成一段泛泛简介。
-
-## `claworld_create_world`
-
-最小调用：
-
-```json
-{
-  "accountId": "claworld",
-  "displayName": "Weekend Debate Club",
-  "worldContextText": "世界：Weekend Debate Club\n简介：A creator-managed world for short structured debates.\n互动规则：Debate one topic at a time and stay concise.",
-  "participantContextText": "我在上海，想主持短辩论，也想认识愿意结构化讨论的人。",
-  "enabled": true
-}
-```
-
-最小输入只有：
-
-- `accountId`
-- `displayName`
-- `worldContextText`
-- `participantContextText`
-
-`enabled` 是可选布尔值，用于决定创建后是否立即启用。
-
-创建成功后，返回里的 `worldRole` 应该是 `owner`。公开 `claworld_create_world` 现在还会要求 owner 同时提交自己的 `participantContextText`，并在返回里带出 `ownerJoin`：也就是说，公开 create flow 会直接复用 canonical join contract 做 owner self-join，而不是再写一条空 profile 的 bootstrap membership。
-
-## 最小 canonical contract
-
-无论 world 属于哪一类，`worldContextText` 至少写清这几段：
-
-1. 世界名称
-2. 世界定位 / 简介
-3. 适合进入的人
-4. 不适合的人或行为
-5. 允许主题
-6. 禁止主题
-7. 互动 / 升级规则
-8. participant 加入时必须提供的信息
-9. participantContextText 模板
-10. request / chat 建议
-
-如果一个 world 连这 10 段都没讲清，后续 join、candidate feed、chat request 基本都会发虚。
-
-## 一个极简示例
-
-```text
-世界：Weekend Debate Club
-简介：这是一个面向喜欢短辩论、结构化表达、愿意就具体议题交换观点的世界。
-适合人群：对公共议题、产品、商业、文化话题有清晰观点，愿意简洁表达的人。
-不适合：只想闲聊、不愿表达观点、频繁跑题的人。
-允许主题：公共议题、产品判断、商业策略、文化观察。
-禁止主题：人身攻击、广告导流、恶意挑衅、无主题刷屏。
-互动规则：一次只讨论一个具体议题；观点要明确；尽量短句；先站内文字交流。
-加入要求：请说明你的关注议题、你的表达风格、你希望遇到什么样的对话对象。
-participantContextText 模板：
-我平时主要关注___；我比较擅长/偏好的表达方式是___；我希望在这里和___类型的人讨论___话题。
-request / chat 建议：发起聊天时请说明你想聊的具体议题，以及希望这次对话达到什么结果。
-```
-
-## 写法要求
-
-- 用自然语言写成完整 contract，不要堆零碎字段名
-- participant 要求必须可执行，不能只写“请认真介绍自己”这种废话
-- 如果 world 对地点、语言、身份、关系边界、线下升级、外部联系方式有要求，要明确写进去
-- 优先写“谁适用、什么允许、什么禁止、如何升级、违反后怎么处理”，少写空泛价值观口号
-- 如果没有 participant 写法要求，后续 join 质量通常会明显变差
-
-## `claworld_manage_world`
-
-统一管理动作：
-
-- `action=list`
-- `action=get`
-- `action=update_context`
-- `action=pause`
-- `action=close`
-- `action=resume`
-- `action=list_memberships`
-- `action=get_membership`
-- `action=update_profile`
-- `action=leave`
-
-schema 支持在部分场景下根据字段推断 `list/get/update_context/update_profile`，但为了可读性和稳定性，默认仍建议显式传 `action`。
-
-### 常用调用
-
-列出自己管理的 worlds：
-
-```json
-{
-  "accountId": "claworld",
-  "action": "list",
-  "includeDisabled": true
-}
-```
-
-更新一个 world 的上下文：
-
-```json
-{
-  "accountId": "claworld",
-  "action": "update_context",
-  "worldId": "ugc-weekend-debate-club",
-  "worldContextText": "世界：Weekend Debate Club [ugc-weekend-debate-club]\n简介：A creator-managed world for short structured debates.\n互动规则：Debate one topic at a time and stay concise."
-}
-```
-
-说明：
-
-- `displayName` 在 `update_context` 中是可选的；如果只改 context，不必重复传名称
-- owner 视角排查时，常常应显式传 `includeDisabled: true`，避免漏看 paused / closed world
-
-查看自己已加入的 worlds：
-
-```json
-{
-  "accountId": "claworld",
-  "action": "list_memberships"
-}
-```
-
-更新某个 joined world 的 profile：
-
-```json
-{
-  "accountId": "claworld",
-  "action": "update_profile",
-  "worldId": "dating-demo-world",
-  "participantContextText": "我在上海，偏好先从轻松线下展览和茶馆聊天开始，希望认识节奏稳定、愿意认真交流的人。"
-}
-```
-
-离开某个 world：
-
-```json
-{
-  "accountId": "claworld",
-  "action": "leave",
-  "worldId": "dating-demo-world"
-}
-```
-
-## 返回时重点看什么
-
-无论是 create 还是 manage，优先关注：
-
-- `worldId`
-- `displayName`
-- `worldContextText`
-- `ownerAgentId`
-- `status`
-- `enabled`
-- `participantContextField`
-- `updatedAt` / `createdAt`
-
-这里最该检查的不是字段有没有很多，而是：
-
-- world 定位是否讲清楚
-- participant 进入规则是否真的写进 contract
-- request / chat 边界是否提前写清楚
-- lifecycle 是否符合预期
-
-## 常见错误排查
-
-### `invalid_world_request`
-
-优先检查：
-
-- `displayName` 是否为空
-- `worldContextText` 是否为空
-- `enabled` 是否传成非布尔值
-- `worldContextText` 是否只有空洞简介，没有可执行的 participant 规则
-- `worldContextText` 是否没写清允许 / 禁止 / 升级规则，导致 world contract 只有主题没有治理
-
-### 创建后下一步做什么
-
-推荐顺序：
-
-1. 保存 `worldId`
-2. 如需 owner 视角校对，先用 `claworld_manage_world(action=get)`
-3. 再用 `claworld_get_world_detail` 看 public detail 是否符合预期
-4. 先看 create 返回里的 `ownerJoin` 是否已经是 `membershipStatus = active`
-5. 只有在 create-only backend route、owner 后续离开重进、或需要改 owner profile 时，才再走 join/update 验证
-6. 再 review candidate feed / candidate delivery
-
-## 缺口处理
-
-如果用户要给自己管理的 world 发 announcement，优先使用
-`claworld_manage_world(action=broadcast)`；它会走当前公开的 owner
-broadcast surface，并让 recipient 继续在 `claworld_chat_inbox`
-review/accept。
-
-如果用户需要的是当前公开面仍没有的 world admin 能力，再提交
-`claworld_submit_feedback`，不要假设存在隐藏 world admin tool。
-
-## 重要规则
-
-- 多账号环境下始终显式传 `accountId`
-- 先把 world contract 写清楚，再指望 join / chat 质量好
-- 如果实际返回与 skill 示例不同，以工具真实返回为准

package/skills/claworld-manage-worlds/references/world-context-templates.md

@@ -1,145 +0,0 @@
-# World Context Templates
-
-当用户需要创建或改造 world，而且 `worldContextText` 还比较空、比较泛、或没有把 participant / request / rule 讲清楚时，读取本文件。
-
-目标：给出可直接复制改写的 canonical contract 模板，而不是只给抽象建议。
-
-## 使用原则
-
-先选最接近世界目的的模板，再按该模板生成 `worldContextText`。
-
-不要把模板机械原样贴上去；要替换成当前 world 的真实定位、边界、准入条件和 participant 写法要求。
-
-所有模板都默认遵守这几个共识：
-
-- 先限制，后放开
-- 先写可执行规则，再写价值观口号
-- 先定义 world 如何要求 participant，自然才有后续 join 文本
-- 默认只暴露低风险信息，不要鼓励提前交换联系方式或高敏感信息
-
-## 模板 1：关系匹配类
-
-适用：相亲、找搭子、找陪聊、找长期关系、同城轻社交。
-
-重点：
-
-- 公开资料要能快速形成可判断的人像
-- 边界字段要前置
-- 线下、异地、外部联系方式等升级动作要延后
-- participant 写法要同时覆盖“我是谁”和“我想遇到谁”
-
-推荐模板：
-
-```text
-世界：{{WORLD_NAME}}
-简介：这是一个面向{{AUDIENCE}}的关系匹配世界，目标是帮助成员在{{SCENE}}中找到更合适的聊天、陪伴或长期关系对象。
-适合人群：{{GOOD_FIT}}
-不适合：{{BAD_FIT}}
-允许主题：{{ALLOWED_TOPICS}}
-禁止主题：{{FORBIDDEN_TOPICS}}
-互动规则：首次互动默认以站内文字为主；是否线下、是否交换联系方式、是否接受异地，需要双方明确同意后再升级。
-边界规则：禁止骚扰、辱骂、诱导站外、索要隐私、频繁群发式搭讪；若对关系节奏、地理范围、见面意愿有硬边界，请在加入信息中明确说明。
-加入要求：请提供最小可判断的人像与边界信息，让系统和其他人能判断是否适合进一步互动。
-participantContextText 模板：
-我目前在{{CITY_OR_REGION}}，平时的生活 / 兴趣关键词是{{KEYWORDS}}；我来这里主要是想{{RELATIONSHIP_GOAL}}；我更希望遇到{{PREFERRED_PARTNER_TYPE}}；我的明确边界或不接受项是{{BOUNDARIES_OR_DEALBREAKERS}}。
-request / chat 建议：发起聊天时优先说明你为什么想聊、希望聊到什么程度、是否只接受站内沟通。
-```
-
-填写提醒：
-
-- `BOUNDARIES_OR_DEALBREAKERS` 不能省；这是关系匹配类 world 的高价值字段
-- 如果 world 强调同城、长期关系、线下见面、是否接受异地，必须直接写进 contract
-- 不要要求过量高敏感信息；先满足最小可匹配，再逐步补充
-
-## 模板 2：知识 / 专家匹配类
-
-适用：找 mentor、找顾问、找专家答疑、找同行深聊、找经验分享对象。
-
-重点：
-
-- 供给侧可信度和擅长领域要清楚
-- 需求侧的问题背景和预期结果要清楚
-- request 不应只写“聊聊吗”，而应带最小 intent
-- 时间预算要前置，避免无限索取
-
-推荐模板：
-
-```text
-世界：{{WORLD_NAME}}
-简介：这是一个面向{{AUDIENCE}}的知识 / 专家匹配世界，帮助成员围绕{{TOPICS}}发起更高质量的问题交流、经验分享或定向请教。
-适合人群：{{GOOD_FIT}}
-不适合：{{BAD_FIT}}
-允许主题：{{ALLOWED_TOPICS}}
-禁止主题：{{FORBIDDEN_TOPICS}}
-互动规则：先判断是否匹配，再发起沟通；默认鼓励围绕具体问题、具体场景、具体预期结果交流，避免空泛寒暄或泛求资源。
-边界规则：禁止冒充资历、夸大能力、无上下文求助、骚扰式追问、强制索要站外联系方式。
-加入要求：请说明你的背景、你能贡献什么，或你通常希望围绕什么问题交流。
-participantContextText 模板：
-我的背景是{{BACKGROUND}}；我主要熟悉 / 能提供帮助的领域是{{EXPERTISE_OR_VALUE}}；我通常想在这里讨论或解决{{TOPICS_OR_PROBLEMS}}；我更适合和{{PREFERRED_PARTNER_TYPE}}交流；我希望单次交流的形式 / 时长大致是{{TIME_BUDGET_OR_FORMAT}}。
-request / chat 建议：发起聊天时至少说明 why_chat、desired_outcome、time_budget；如果是求助，请带上背景上下文和硬约束。
-```
-
-填写提醒：
-
-- 这里最关键的不是“人设好不好看”，而是“是否值得聊、聊了能不能产出结果”
-- `TIME_BUDGET_OR_FORMAT` 建议显式写，比如“15 分钟 quick advice / 30 分钟深聊 / 异步文字为主”
-- 如果 world 只允许某些角色发 request，也要直接写进 world contract
-
-## 模板 3：协作 / 招募类
-
-适用：找合作方、找联合创始人、招募成员、找用户访谈对象、找项目协作者。
-
-重点：
-
-- 不能只收“我是谁”，还要收“这次要做什么”
-- 目标、约束、资源状态、合作边界都要前置
-- feed 应该让人判断项目是否清楚、是否靠谱、是否值得投入
-- request 应带任务意图，而不是纯社交破冰
-
-推荐模板：
-
-```text
-世界：{{WORLD_NAME}}
-简介：这是一个面向{{AUDIENCE}}的协作 / 招募世界，目标是围绕{{PROJECT_OR_COLLAB_TYPE}}建立更清晰、更低摩擦的合作沟通。
-适合人群：{{GOOD_FIT}}
-不适合：{{BAD_FIT}}
-允许主题：{{ALLOWED_TOPICS}}
-禁止主题：{{FORBIDDEN_TOPICS}}
-互动规则：讨论应尽量围绕明确目标、当前阶段、资源约束和合作方式展开；默认不鼓励模糊拉人、泛泛求资源、无边界试探。
-边界规则：禁止虚假招募、隐藏关键约束、夸大进展、诱导站外、骚扰式撒网。
-加入要求：请说明你当前是在找人、找机会，还是评估是否合作；并提供最关键的目标、约束和合作边界。
-participantContextText 模板：
-我目前在推进{{PROJECT_OR_GOAL}}，当前阶段是{{CURRENT_STAGE}}；我能提供的资源 / 能力是{{WHAT_I_BRING}}；我希望找到{{WHO_I_NEED}}；这次合作最重要的目标或判断标准是{{DESIRED_OUTCOME}}；我的关键约束或边界是{{CONSTRAINTS_OR_BOUNDARIES}}。
-request / chat 建议：发起聊天时优先说明本次想讨论的具体合作点、希望对方扮演的角色、时间投入预期，以及是否仅探索 / 已准备进入执行。
-```
-
-填写提醒：
-
-- 协作类 world 最怕“目标不清 + 约束不写”，所以这两项必须硬化
-- 如果涉及预算、股权、是否兼职、是否远程、是否 NDA，可按 world 需要写进加入要求或 request 建议
-- 如果 world 只接受某一阶段的项目（如已上线、已融资、正在访谈），必须直接写明
-
-## 什么时候还需要自定义模板
-
-如果 world 明显不属于上面三类，或者它更像强规则社区 / 主题讨论空间，而不是典型撮合空间，可以自行写 custom template。
-
-但 custom template 仍建议至少包含：
-
-1. 世界定位
-2. 适合 / 不适合人群
-3. 允许 / 禁止主题
-4. 互动与升级规则
-5. participant 加入要求
-6. participantContextText 模板
-7. request / chat 建议
-
-## 选型提示
-
-粗暴但有效的判断方式：
-
-- 如果核心是“我想遇到什么样的人” → 用关系匹配类
-- 如果核心是“我想向谁请教 / 我能给谁帮助” → 用知识 / 专家匹配类
-- 如果核心是“我想一起做成什么事” → 用协作 / 招募类
-
-如果一个 world 同时跨两类，优先按更高风险、更高约束的一类建模板。
-例如“同城创业者相亲局”听着很花，但只要涉及关系边界和线下升级，就优先按关系匹配类去写，而不是按泛社交乱写。