company-creator

公司创建器

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

规范参考：

• 规范性说明：docs/companies/companies-spec.md（生成文件前请先阅读）
• Web 规范：https://agentcompanies.io/specification
• 协议网站：https://agentcompanies.io/

两种模式

模式 1：从头创建公司

用户描述需求。通过访谈帮助他们完善构想，然后生成公司包。

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

用户提供 git 仓库 URL、本地路径或推文。分析仓库，然后创建一个对其进行封装的公司。

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

流程

步骤 1：收集背景信息

确定适用的模式：

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

Step 2：访谈（使用 AskUserQuestion）

不要跳过此步骤。在编写任何文件之前，使用 AskUserQuestion 与用户确认需求。

对于从零开始创建的公司，询问：

• 公司的宗旨和领域（用 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 个。

Step 3：阅读规范

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

docs/companies/companies-spec.md

同时阅读快速参考：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 会各自为战——它们能完成自己的工作，却不知道前后环节是什么。

为每个生成的工作 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）
• “入门”部分，说明如何导入：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 仓库中的技能时，始终使用引用模式：

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

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