Downstream exports 是 acaprino/daodan 项目中的一个技能文档，主题是内容如何流向 Codex 之外的宿主。它与 external-repo-intake 技能互为镜像：后者处理从其他仓库流入的内容，本技能处理本项目内容向其他宿主的流出。
一、用途与定位 exports/ 目录下的任何文件都不允许手工编辑，全部是 plugins/ 加 adapters/ 的编译器输出。python scripts/daodan_build.py --check 会在已提交的包无法从源重新生成时使构建失败。如果某个导出看起来有问题，缺陷在于内核、适配器或编译器，直接修改导出会在下一次构建时被静默删除。
二、核心与宿主的职责划分 核心负责角色、工作流依赖、必需的上下文隔离、连接与可观察契约；harness 负责宿主 API、调度、重试与结果收集。变更归属如下：
- 审查者关注什么、工作流含义、报告必须包含什么：归 plugins/<name>/（行为用 Markdown，结构用 TOML）。
- 哪个宿主工具满足某个中立能力：归 adapters/<host>/capabilities.toml。
- 宿主支持哪些协调策略及其顺序：归 adapters/<host>/coordination.toml。
- 组件落在宿主包的什么位置：归 adapters/<host>/layout.toml。
- 告诉宿主 harness 如何调度的包装文本：归 adapters/<host>/templates/。
- 某宿主如何执行中立策略：归 adapters/<host>/policies/<name>/，其中 policy.toml 声明它实现了什么。
- 确实无法从通用模板渲染的含义：归 adapters/<host>/overrides/<plugin>/<workflow>/。 中立内容中永远不得出现宿主工具、团队 API 或调度原语的名称。
三、各宿主期望的包结构 文档以表格形式列出 claude、copilot、codex、pi、opencode 五个宿主在 catalog、plugin manifest、roles、workflows、skills、source reference 上的差异。例如 Claude 的 catalog 是 .claude-plugin/marketplace.json，角色位于 agents/<role>.md；Copilot 的 catalog 是 .github/plugin/marketplace.json，工作流位于 prompts/<workflow>.prompt.md；Codex 的 catalog 是 .agents/plugins/marketplace.json，工作流位于 skills/<workflow>-workflow/SKILL.md；Pi 的 catalog 是根 package.json，无 plugin manifest，角色渲染为带 disable-model-invocation: true 的 skills；OpenCode 的 catalog 是 exports/opencode/package.json，无 plugin manifest，角色位于 agents/<role>.md 并注册为 agent <plugin>:<role>。
四、Pi 与 OpenCode 的特殊机制 Pi 没有 marketplace 和逐插件 manifest，其 catalog 是仓库根部的 npm 形 package.json，通过 glob 注册 ./exports/pi/plugins/*/skills 与 .../prompts。Pi 核心有意省略的两个机制由用户安装的伴随包提供：pi-subagents 提供隔离的 worker 上下文，pi-mcp-adapter 提供 MCP。 OpenCode V2 在代码注册之前什么都不存在，没有 marketplace 和静态包格式，包以插件形式到达，是 ES 模块，其默认导出的 setup 调用 V2 的 transform 钩子来注册 skills、agents、commands 和 MCP servers。其 index.js 是固定加载器，由 layout 的 package_files 键逐字复制，受 drift gate 约束，从不按插件生成。
五、Codex 的命名与目录后缀 Codex 的工作流目录故意加 -workflow 后缀，因为它是唯一把 skills 和 workflows 都渲染为 skills 的宿主。自 marketplace 29.0.0 起，同一插件内 skill、role、workflow 不得重名，validate_component_kinds 会在构建时失败。
六、Harness 渲染 当工作流的 sidecar 声明 [dispatch].roles、允许 [dispatch].inline_workers，或存在带 fanout 或 fanout_from 的阶段时，该工作流会获得 harness。宿主模板用隔离的 worker 上下文、交付屏障、最终报告的单写者规则和调度计划包装中立主体。文档列出了各宿主的模板文件路径。调度计划（${dispatch_plan}）按 sidecar 的每个阶段逐行编号，说明 worker 数量、上下文、并发、屏障以及阶段的需求、消费与产出。
七、Claude 的两个占位符 内核主体写 ${CLAUDE_PLUGIN_ROOT}/skills/x/scripts/y.py，因为 bundled-path linter 要求该形式；写 $ARGUMENTS 因为这是 Claude 命令展开的形式。两者在 Copilot 或 Codex 上未定义，渲染器按宿主从四个 layout 键重写，并在每个使用该引用的 Markdown 文件中于 frontmatter 之后插入一次宿主说明。
八、共享契约与组合 [contracts].exports 声明内核的公共 contracts/ 文件。共享引用如 project-protocol/contracts/work.toml 应放在 [contract].shared_schemas 中，其提供者必须是直接必需依赖，目标必须显式导出。提供者包携带规范文件，消费者的 contracts/<workflow>.workflow.toml sidecar 保留限定引用，编译器不会创建另一份手工编写的 schema 副本。
关于收费、价格、平台支持范围等具体信息，资料中暂未提供。