Company Creator 用于创建符合 Agent Companies 规范（agentcompanies/v1）的智能体公司包。
用途
当用户希望从零开始创建新的智能体公司，或基于某个 Git 仓库创建公司时使用。规范参考包括：规范性规范 https://agentcompanies.io/specification、本地快速参考 references/companies-spec.md、协议站点 https://agentcompanies.io/。
两种模式
模式一：从零创建公司。用户描述想要的内容，通过访谈完善愿景，然后生成包。
模式二：基于仓库创建公司。用户提供 Git 仓库 URL、本地路径或推文，分析仓库后创建包装它的公司。详细仓库分析步骤见 references/from-repo-guide.md。
流程
第一步：收集上下文。确定适用模式。从零创建时了解公司或团队类型、领域、智能体职责；基于仓库时克隆或读取仓库，扫描现有技能、智能体配置、README 和源码结构。
第二步：访谈用户。不可跳过。针对从零创建的公司，询问公司目的与领域、所需智能体（基于描述提出招聘计划）、是全公司（需要 CEO）还是团队/部门（无需 CEO）、智能体应具备的特定技能、工作如何流转、是否需要项目和起始任务。针对基于仓库的公司，展示分析结果并确认计划创建的智能体及角色、是否引用或内置发现的技能（默认引用）、仓库之外的额外智能体或技能、公司名称与定制项、推断的工作流。
工作流——工作如何流经公司
公司不只是带技能的智能体列表，而是把想法转化为工作产物的组织。需要理解工作流，使每个智能体知道：谁以何种形式（任务、分支、问题、评审请求）交给他们工作；他们如何处理；完成后交给谁以及交接形式；其角色的“完成”意味着什么。并非每家公司都是流水线，需从上下文推断合适的工作流模式：流水线（顺序阶段，逐个交接，适用于有清晰线性流程的领域）；中心辐射（管理者委派给专家，专家独立汇报，适用于不同类型工作不互相喂入的情况）；协作（智能体作为同伴共同工作，适用于小团队共同产出）；按需（按需召唤，无固定流程，适用于专家工具箱）。从零创建时基于描述提出工作流模式并询问是否合适；基于仓库时从仓库结构推断模式，若技能有清晰顺序依赖则为流水线，若技能是独立能力则更可能是中心辐射或按需，在访谈中说明推断供用户确认或调整。
访谈原则：提出具体招聘计划，不要开放式提问；保持精简，初创公司通常 3-5 个智能体，除非范围需要否则不建议 10 个以上；从零创建的公司应以管理所有人的 CEO 开始，团队/部门不需要；每轮问 2-3 个聚焦问题，而非 10 个。
第三步：阅读规范。生成任何文件前，阅读 https://agentcompanies.io/specification、本地快速参考 references/companies-spec.md 和示例 references/example-company.md。
第四步：生成包。创建目录结构和所有文件，严格遵循规范约定。目录结构：<company-slug>/ 下含 COMPANY.md、agents/<slug>/AGENTS.md、teams/<slug>/TEAM.md（如需要）、projects/<slug>/PROJECT.md（如需要）、tasks/<slug>/TASK.md（如需要）、skills/<slug>/SKILL.md（如需要自定义技能）、.paperclip.yaml（Paperclip 供应商扩展）。规则：slug 必须 URL 安全、小写、连字符；COMPANY.md 设置 schema: agentcompanies/v1，其他文件继承；智能体指令放在 AGENTS.md 正文，不放 .paperclip.yaml；AGENTS.md 中按短名引用的技能解析到 skills/<shortname>/SKILL.md；外部技能使用 sources 并设 usage: referenced（见规范第 12 节）；不导出机密、机器本地路径或数据库 ID；省略空/默认字段；基于仓库生成的公司，在 COMPANY.md 正文底部添加引用页脚。汇报结构：除 CEO 外每个智能体应设置 reportsTo 为其管理者 slug；CEO 的 reportsTo: null；无 CEO 的团队，顶层智能体 reportsTo: null。编写工作流感知的智能体指令：每个 AGENTS.md 正文不仅包含智能体做什么，还包含其在组织工作流中的位置，包括工作来源、产出、交接对象、触发条件。
第五步：确认输出位置。询问用户将包写入何处，常见选项：当前仓库的子目录、用户指定的新目录、当前目录（若为空或用户确认）。
第六步：写入 README.md 和 LICENSE。README.md 每个公司包都要有，应包含公司名称与用途、工作流/公司运作方式、以 Markdown 列表或表格展示的组织架构图（智能体、头衔、汇报结构、技能）、每个智能体角色的简要描述、引用与参考（源仓库链接、Agent Companies 规范链接、Paperclip 链接）、说明如何导入的“Getting Started”部分：paperclipai company import --from <path>。LICENSE 版权持有者为创建公司的用户，而非上游仓库作者；使用与源仓库相同的许可证类型（基于仓库时）或询问用户（从零创建时），不明确时默认 MIT。
第七步：写入文件并总结。写入所有文件后给出简要总结：公司名称与用途、智能体名册及角色与汇报结构、技能（自定义+引用）、项目与任务（如有）、输出路径。
.paperclip.yaml 指南
.paperclip.yaml 是 Paperclip 供应商扩展，按智能体配置适配器和环境输入。适配器规则：除非仓库或用户上下文需要，否则不指定适配器；不知道用户想要什么适配器时完全省略适配器块，Paperclip 将使用默认值；指定未知适配器类型会导致导入错误。Paperclip 支持的适配器类型（仅这些有效值）：claude_local（Claude Code CLI）、codex_local（Codex CLI）、opencode_local（OpenCode CLI）、pi_local（Pi CLI）、cursor（Cursor）、gemini_local（Gemini CLI）、openclaw_gateway（OpenClaw 网关）。仅在以下情况设置适配器：仓库或其技能明确针对特定运行时；用户明确要求特定适配器；智能体角色需要特定运行时能力。环境输入规则：不添加样板环境变量，仅添加智能体基于技能或角色实际需要的环境输入，如推送代码、创建 PR 或与 GitHub 交互的智能体需要 GH_TOKEN，技能明确要求时才加 API 密钥，绝不将 ANTHROPIC_API_KEY 设为默认空环境变量（运行时处理）。示例中仅出现有实际覆盖的智能体。
外部技能引用
从 GitHub 仓库引用技能时，始终使用 references 模式，包含 kind: github-file、repo、path、commit（来自 git ls-remote 或仓库的完整 SHA）、attribution、license、usage: referenced。用 git ls-remote https://github.com/owner/repo HEAD 获取提交 SHA。除非用户明确要求，否则不要将外部技能内容复制到包中。
提示
尽量保持智能体 1:1——若源仓库 README 说“48 个智能体，37 个工作流”，完成后应有 48 个智能体；智能体很多时，可发明中层管理将其分成团队。在 README 中引用上游仓库——若从上游 GitHub 生成 README，务必在 README.md 顶部附近注明，链接原仓库并描述其用途。每个公司必须是结构良好的图且有一个 CEO——确保每个智能体要么向其老板汇报，要么向 CEO 汇报；必须有一个不向任何人汇报的 CEO。