Submission standard

如果你想分享自己的 OpenClaw 成果，这里告诉你怎样准备内容更容易被看懂。

比起丢一堆文件上来，更重要的是把结果、场景、限制和风险讲清楚，这样别人才能判断它是不是适合自己。

查看字段总览先看安全要求

快速提示

最好先准备真实结果、演示和输入输出样例

适用版本、前置条件和限制条件要写清楚

涉及高权限、外部账号或文件写入时，风险别藏着不说

把信息分清楚写，比一大段宣传文案更容易让人理解

你将获得

内容风格

少废话，先给结果

先告诉你该做什么、会遇到什么，再给出最短可用路径。

阅读体验

能看懂，也能照着做

重点信息会被拆成清单、步骤和提示，减少第一次上手的理解成本。

页面重点

先把关键问题讲清楚

实用优先

Workflow

投稿入口是审核入口，不是上传文件的垃圾桶。

平台要先用结构化字段判断它值不值得收录、是否足够可信、是否可以安全复刻，然后才决定是否进入推荐。

草稿中

方向已建立，但证据和字段还不完整，适合早期讨论。

待补充材料

方向成立，但演示、安全字段或复刻路径还不足以支持收录判断。

审核中

平台正在按用户价值、能力证明、安全与权限、复刻可行性、维护可信度五维检查。

已通过

达到最低证明标准，可进入首页推荐、精选目录或官方收录列表。

已驳回

存在违规内容、隐藏风险、伪造展示或明显不可复现等重大问题。

Draft intake

草稿阶段先验证方向，不要求一次把分享包补到最满。

草稿提交的任务是让审核方先判断它是不是空泛概念、有没有真实用户价值，以及作者是否真的有继续补全的能力。

Minimum judgment

草稿阶段至少要让审核方判断这三件事

如果连最小必要字段都说不清，就不应该直接进入正式审核和精选流程。

方向是否成立

它不是空泛概念，而是有明确结果导向。

价值是否明确

它解决的是一类真实问题，而不是只讲炫技。

作者是否能补完

作者已经有演示或复刻路径的基础素材。

Draft fields

草稿阶段最小必要字段

先让平台快速判断值不值得继续补材料，而不是一开始就让作者填完所有正式字段。

Showcase 名称

一句话价值说明

它最适合谁

它解决的核心问题

1 条最强结果描述

当前 OpenClaw 版本

是否已有演示素材

作者名称 / 昵称

联系邮箱或其他联系渠道

Formal schema

正式提交字段必须按 7 组结构化收集。

这不是为了做复杂表单，而是为了让 Showcase 页面、审核流程和分享包文件完全对齐。字段分组清楚，后续才能做状态流转、复核和推荐。

1. 基本信息

这组字段会进入 Showcase 的第一屏和列表卡片，先回答“它是什么、适合谁”。

Showcase 名称

一句话价值说明

一句话能力钩子

核心问题描述

适合谁 / 不适合谁

所属类别

适用的 OpenClaw 版本

语言支持

2. 能力展示与证明

这组字段决定它能不能进入精选目录或首页推荐，缺失时不应通过。

完整演示素材

真实输入示例

真实输出结果

结果证明

3 个代表性场景

为什么强

3. 适用场景与边界

平台不允许只讲能力不讲限制，这组字段负责收住用户预期。

适用场景

不适用场景

已知失败场景

前置条件

预期效果

不保证项说明

4. 安全与权限说明

这是审核优先级最高的一组，凡是高风险能力都必须结构化申报。

文件读取 / 写入

Shell / 命令执行

联网访问

浏览器接管或自动化

第三方账号或外部服务

高权限操作 / 付费 API

主要风险说明

建议的安全使用方式

5. 分享包与复刻信息

它决定用户能不能在自己的环境里安全复刻，而不是只停留在看演示。

分享包名称与一句话卖点

Agent 灵魂 / 使命描述

Skills 清单与安装顺序

依赖项与前置环境

复刻步骤

预计配置时间

是否需要手动调整

不包含的敏感内容说明

适用版本 / 最后验证日期

6. 作者与维护信息

这组字段不是做营销，而是建立维护可信度和反馈入口。

作者名称 / 昵称

作者简介

主页或社交链接

是否愿意接收反馈

更新频率说明

正式提交前至少补齐这些材料

没有演示、没有真实输入输出、没有安全申报，就不能进入人工审核的下一步。

至少 1 段完整演示素材，能够看清从输入到输出的过程。

至少 1 组真实输入输出，不只给结果截图或宣传文案。

清晰的安全申报，说明是否涉及文件写入、Shell、联网、外部账号等能力。

清晰的复刻路径，说明前置条件、安装顺序、需要手动调整的部分和不包含内容。

Quick reject

出现以下情况，直接驳回

这些问题不是补材料能修的，而是方向或安全性本身就不成立。

与 OpenClaw 基本无关，只是泛 AI 包装内容。

没有任何真实演示、截图或输入输出示例。

包含凭证、私密记忆、隐私数据、未授权素材。

明明涉及高风险能力，却故意不申报或模糊表达。

没有复刻路径，只有炫技展示。

Attachments

表单应支持的附件与素材类型

演示、输入输出和分享包文件必须能被审核方直接拿来判断，不要只上传宣传文案。

演示视频

GIF

连续截图

输入输出示例文本

分享包附件或模板文件

补充说明文档

Required declarations

正式提交必须勾选的审核声明

这些声明不是形式项，而是平台压低版权、隐私和误导风险的硬门槛。

我确认该内容不包含私密记忆、账号凭证或未授权数据。

我确认展示素材真实有效，未伪造结果。

我确认高风险能力已经如实说明。

我确认我有权分享该设定、素材和相关内容。

我理解平台会进行人工审核，并可能要求补充材料。

Agent pack

第一版分享包至少要让作者、审核方和接收者对齐同一套结构。

这不是把所有内容塞进一个大文件里，而是让结构化元数据和解释性文档各司其职。

manifest.yaml

承载结构化元数据，包括版本、风险标签、依赖项和最后验证日期。

soul.md / skills.md

说明 Agent 设定层内容、依赖 Skills 和它们之间的组合关系。

setup.md / safety.md

给出复刻步骤、权限边界、失败停点和风险说明。

examples.md / changelog.md

提供真实输入输出样例和后续维护记录，让用户知道内容还在不在维护。

Template example

Morning Brief Desk Pack · 完整公开分享包示例

这是一套对齐当前 PRD 的可公开分享包样板，不追求自动导入，而是优先让作者、审核方和接收方对同一套结构形成一致理解。

package_name

Morning Brief Desk Pack

package_version

1.0.0

适用版本

OpenClaw 0.9.x

风险标签

network, file_write

Template preview

完整公开分享包示例至少要覆盖这 7 个文件

这组预览不是虚构附件清单，而是平台希望作者、审核方和接收者看到的同一套最小结构。

manifest.yaml → package_name: Morning Brief Desk Pack / summary: 把多来源素材收束成可复核晨报初稿。

soul.md → 角色是晨报编辑，不做事实捏造，不越过待确认标记直接外发。

skills.md → 依赖 Release Watcher 与 Workflow Packager，前者负责筛选变化，后者负责整理分享结构。

setup.md → 先准备来源清单与模板，再跑一次测试目录输出，最后才接正式团队工作流。

safety.md → 明确只读取允许来源、输出写到独立目录、所有待确认段落必须保留标记。

examples.md → 提供 1 组晨报输入素材与 1 份 Markdown 草稿输出。

changelog.md → 记录 2026-03-15 首版样板建立与后续字段变更。

Template checklist

分享包示例应如何对齐 PRD 结构

这样写出来的示例，才足以作为站内公开样板，而不是只停留在字段命名层。

manifest.yaml：写清 package_name、summary、target_users、core_problem、required_skills、risk_flags、compatibility、verified_at。

soul.md：只描述角色定位、目标边界、做事原则和不该做的事，不导出私密上下文。

skills.md：说明每个 Skill 为什么需要、安装顺序是什么、缺了会影响哪部分能力。

setup.md：把前置环境、配置顺序、验证步骤和需要手动调整的部分逐项写清楚。

safety.md：逐项解释 risk_flags，对齐账号、文件写入、联网和审批停点，不留模糊表述。

examples.md：给至少 1 组真实输入输出和 1 条结果证明，允许脱敏但不能改写逻辑。

changelog.md：记录最后验证日期、更新内容和已知兼容变化，方便审核与后续复核。

Official sources

投稿标准页也只优先采信官方文档里能支撑审核与复刻判断的内容。

投稿字段不是凭空设计出来的。涉及 Skill 依赖、权限申报、health check 和浏览器接管等高风险能力时，站内规则应先对齐官方文档能交叉验证的边界，再固化为平台审核标准。

官方文档 · Skills

用于核对分享包和投稿内容中 Skill 依赖、来源说明与安装边界的写法。

https://docs.openclaw.ai/zh-CN/skills/overview

官方文档 · 权限与批准

用于核对投稿字段里文件写入、命令执行、外部服务和高权限能力应如何申报。

https://docs.openclaw.ai/zh-CN/config/permissions

官方文档 · Doctor & Health Check

用于核对分享包复刻前的健康检查、阻断项和失败停点说明。

https://docs.openclaw.ai/zh-CN/config/doctor-and-health-check

官方文档 · Browser Relay / 浏览器接管

用于核对涉及浏览器接管、网页操作和外部账号风险的投稿说明边界。

https://docs.openclaw.ai/zh-CN/tools/browser