company-creator

公司创建器

创建符合 Agent Companies 规范的 Agent 公司软件包。

规范参考：

• 规范： https://agentcompanies.io/specification
• 本地快速参考：references/companies-spec.md
• 协议网站： https://agentcompanies.io/

两种模式

模式 1：从零创建公司

用户描述他们想要的内容。与他们访谈，完善愿景，然后生成软件包。

模式 2：基于代码仓库创建公司

用户提供 Git 仓库 URL、本地路径或推文。分析代码仓库，然后创建一个封装该仓库的公司。

详细的代码仓库分析步骤请参阅 references/from-repo-guide.md。

流程

步骤 1：收集背景信息

确定适用的模式：

• 从零创建：要创建什么类型的公司或团队？属于什么领域？Agent 应该做什么？
• 基于代码仓库创建：克隆/读取代码仓库。检查现有技能、Agent 配置、README 和源代码结构。

第 2 步：访谈用户

不要跳过此步骤。编写任何文件之前，先提出有针对性的问题，与用户达成一致。

对于从零开始创建的公司，询问以下内容：

• 公司宗旨和领域（用 1–2 句话说明即可）
• 需要哪些 Agent——根据用户描述提出招聘计划
• 这是完整公司（需要 CEO），还是团队／部门（无需 CEO）
• Agent 是否需要具备任何特定技能
• 工作如何在组织内流转（参见下文“工作流”）
• 是否需要项目和入门任务

对于基于代码仓库创建的公司，展示分析结果并询问以下内容：

• 确认计划创建的 Agent 及其职责
• 是否引用或内置发现的技能（默认：引用）
• 除代码仓库已有内容外，是否还需要其他 Agent 或技能
• 公司名称和任何定制内容
• 确认你从代码仓库推断的工作流（参见下文“工作流”）

工作流——工作如何在公司内流转？

公司不只是拥有各种技能的 Agent 列表。它是一个将想法转化为工作成果的组织。你需要了解工作流，以便每个 Agent 都清楚：

• 谁以何种形式分配工作给他们（任务、分支、问题、审查请求）
• 他们需要如何处理
• 完成后移交给谁，以及移交的形式
• 对他们的职责而言，“完成”意味着什么

并非每家公司都是流水线。 根据上下文推断合适的工作流模式：

• 流水线——按顺序推进的阶段，每个 Agent 都将工作移交给下一个 Agent。适用于代码仓库／领域中存在明确线性流程的情况（例如：规划 → 构建 → 审查 → 发布 → QA，或内容构思 → 起草 → 编辑 → 发布）。
• 中心辐射式——经理将工作委派给各位专家，由他们分别汇报。适用于 Agent 承担不同类型、彼此不衔接的工作（例如：CEO 分派任务给研究员、营销人员和分析师）。
• 协作式——Agent 作为同级成员共同完成相同的工作。适用于所有人都为同一产出做出贡献的小团队（例如设计工作室、头脑风暴团队）。
• 按需调用式——按需召集 Agent，没有固定流程。适用于 Agent 更像是由用户直接调用的专家工具箱。

对于从零开始创建的公司，根据用户的描述提出一种工作流模式，并询问是否合适。

对于基于代码仓库创建的公司，根据代码仓库的结构推断工作流模式。如果技能之间存在明确的顺序依赖（例如 plan-ceo-review → plan-eng-review → review → ship → qa），则属于流水线。如果技能是彼此独立的能力，则更可能采用中心辐射式或按需调用式。在访谈中说明你的推断，以便用户确认或调整。

关键访谈原则：

• 提出具体的招聘计划。不要开放式地询问“你想要哪些 Agent？”——应根据上下文建议具体的 Agent，并让用户调整。
• 保持精简。大多数用户都是 Agent 公司的新手。初创公司通常配备少量 Agent（3–5 个）。除非范围确实需要，否则不要建议 10 个以上的 Agent。
• 从零开始创建的公司应从一位负责管理所有人的 CEO 开始。团队／部门则不需要 CEO。
• 每轮提出 2–3 个有针对性的问题，而不是 10 个。

第 3 步：阅读规范

生成任何文件之前，请阅读以下规范性说明：

https://agentcompanies.io/specification

还要阅读本地快速参考：references/companies-spec.md

以及示例：references/example-company.md

步骤 4：生成软件包

创建目录结构和所有文件。严格遵循规范的约定。

目录结构：

<company-slug>/
├── COMPANY.md
├── agents/
│   └── <slug>/AGENTS.md
├── teams/
│   └── <slug>/TEAM.md        (if teams are needed)
├── projects/
│   └── <slug>/PROJECT.md     (if projects are needed)
├── tasks/
│   └── <slug>/TASK.md        (if tasks are needed)
├── skills/
│   └── <slug>/SKILL.md       (if custom skills are needed)
└── .paperclip.yaml            (Paperclip vendor extension)

规则：

• Slug 必须适用于 URL，使用小写字母并以连字符连接
• COMPANY.md 设置 schema: agentcompanies/v1，其他文件继承此设置
• Agent 指令放在 AGENTS.md 正文中，而不是 .paperclip.yaml 中
• 在 AGENTS.md 中通过短名称引用的技能，应对应到 skills/<shortname>/SKILL.md
• 对于外部技能，使用 sources 并设置 usage: referenced（参见规范第 12 节）
• 不要导出密钥、机器本地路径或数据库 ID
• 省略空字段或默认字段
• 对于从代码仓库生成的公司，在 COMPANY.md 正文末尾添加参考信息： Generated from [repo-name](repo-url) with the company-creator skill from [Paperclip](https://github.com/paperclipai/paperclip)

汇报结构：

• 除 CEO 外，每个 Agent 的 reportsTo 都应设置为其经理的 slug
• CEO 的 reportsTo: null
• 对于没有 CEO 的团队，顶层 Agent 的 reportsTo: null

编写具有工作流意识的 Agent 指令：

每份 AGENTS.md 正文不仅应说明 Agent 的工作内容，还应说明其如何融入组织工作流。包括：

1. 工作来源——“你会收到用户提出的功能想法”或“你会接手 CTO 分配给你的任务”
2. 产出内容——“你会产出包含架构图的技术计划”或“你会产出经过审查和批准、可供发布的分支”
3. 交接对象——“计划确定后，将其交给 Staff Engineer 实施”或“审查通过后，将其交给 Release Engineer 发布”
4. 触发条件——“当新的功能想法需要产品层面的分析时，你会被激活”或“当分支已准备好进行合并前审查时，你会被激活”

这样，多个 Agent 才能组成一个真正协同工作的组织。如果缺少工作流上下文，Agent 就会各自为战——它们能完成自己的工作，却不知道前后环节会发生什么。

步骤 5：确认输出位置

询问用户将软件包写入何处。常见选项包括：

• 当前代码仓库中的子目录
• 用户指定的新目录
• 当前目录（如果目录为空，或用户确认使用）

步骤 6：编写 README.md 和 LICENSE

README.md——每个公司软件包都需要 README。它应是一份清晰易读的介绍，让浏览 GitHub 的用户也乐于阅读。包括：

• 公司名称及其业务
• 工作流／公司的运作方式
• 以 Markdown 列表或表格展示组织结构，包括 Agent、职称、汇报关系和技能
• 简要说明每个 Agent 的职责
• 引用和参考资料：链接到源代码仓库（如果来自代码仓库）、Agent Companies 规范（https://agentcompanies.io/specification）和 Paperclip（https://github.com/paperclipai/paperclip）
• “Getting Started”章节，说明如何导入：paperclipai company import --from <path>

LICENSE——添加 LICENSE 文件。版权所有者应为创建公司的用户，而不是上游代码仓库的作者（他们编写了技能，用户创建了公司）。使用与源代码仓库相同的许可证类型（如果来自代码仓库），或询问用户（如果从零开始）。如果不明确，默认使用 MIT。

步骤 7：编写文件并总结

编写所有文件，然后简要总结：

• 公司名称及其业务
• Agent 名单、职责和汇报关系
• 技能（自定义技能和引用的技能）
• 项目和任务（如有）
• 输出路径

.paperclip.yaml 指南

.paperclip.yaml 文件是 Paperclip 的供应商扩展文件，用于为每个 Agent 配置适配器和环境输入。

适配器规则

除非仓库或用户上下文有明确依据，否则不要指定适配器。 如果你不知道用户想要哪种适配器，请完全省略适配器配置块——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 网关

仅在以下情况下设置适配器：

• 仓库或其技能明确针对特定运行时（例如，gstack 专为 Claude Code 构建，因此适合使用 claude_local）
• 用户明确指定了某种适配器
• Agent 的角色需要特定运行时能力

环境变量输入规则

不要添加模板化环境变量。 只根据 Agent 的技能或角色添加实际需要的环境变量输入：

• 对于会推送代码、创建 PR 或与 GitHub 交互的 Agent，添加 GH_TOKEN
• 仅在技能明确要求时添加 API 密钥
• 切勿将 ANTHROPIC_API_KEY 设为空的默认环境变量——运行时会处理此项

带适配器的示例（仅在有明确依据时使用）：

schema: paperclip/v1
agents:
  release-engineer:
    adapter:
      type: claude_local
      config:
        model: claude-sonnet-4-6
    inputs:
      env:
        GH_TOKEN:
          kind: secret
          requirement: optional

示例——仅显示确实有覆盖配置的 Agent：

schema: paperclip/v1
agents:
  release-engineer:
    inputs:
      env:
        GH_TOKEN:
          kind: secret
          requirement: optional

在此示例中，只显示了 release-engineer，因为它需要 GH_TOKEN。其他 Agent（ceo、cto 等）没有覆盖配置，因此会从 .paperclip.yaml 中完全省略。

外部技能引用

引用 GitHub 仓库中的技能时，始终使用 references 模式：

metadata:
  sources:
    - kind: github-file
      repo: owner/repo
      path: path/to/SKILL.md
      commit: <full SHA from git ls-remote or the repo>
      attribution: Owner or Org Name
      license: <from the repo's LICENSE>
      usage: referenced

使用以下命令获取提交 SHA：

git ls-remote https://github.com/owner/repo HEAD

除非用户明确要求，否则不要将外部技能内容复制到软件包中。

提示

• 尽量保持 Agent 数量一一对应——如果源仓库的 readme 写着类似“48 个 Agent、37 个工作流”，那么完成后也应有 48 个 Agent。不过，如果 Agent 数量很多，最好设置中层管理，将他们分成不同团队。

• 在 README 中注明上游仓库——如果你根据上游 GitHub 仓库生成 readme，请务必在 README.md 顶部附近注明来源。链接到原始仓库并描述其用途。例如，一个基于 GStack 的 Agent 公司，用于完成

• 每家公司都必须是结构良好的图，并且设有 CEO——确保每个 Agent 都向以下其中一方汇报：1. 自己的上司；或 2. CEO。必须设有一位不向任何人汇报的 CEO。