company-creator

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Company Creator

代理公司创建工具

Create agent company packages that conform to the Agent Companies specification.

Spec references:

Normative spec: https://agentcompanies.io/specification
Local quick reference:
```
references/companies-spec.md
```
Protocol site: https://agentcompanies.io/

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

规范参考：

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

Two Modes

两种模式

Mode 1: Company From Scratch

模式1：从头创建公司

The user describes what they want. Interview them to flesh out the vision, then generate the package.

用户描述需求。通过访谈完善愿景，然后生成包。

Mode 2: Company From a Repo

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

The user provides a git repo URL, local path, or tweet. Analyze the repo, then create a company that wraps it.

See references/from-repo-guide.md for detailed repo analysis steps.

用户提供Git仓库URL、本地路径或推文。分析仓库后，创建包裹该仓库的代理公司。

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

Process

流程

Step 1: Gather Context

步骤1：收集上下文

Determine which mode applies:

From scratch: What kind of company or team? What domain? What should the agents do?
From repo: Clone/read the repo. Scan for existing skills, agent configs, README, source structure.

确定适用的模式：

从头创建：需要什么样的公司或团队？所属领域是什么？代理需要完成哪些工作？
基于仓库：克隆/读取仓库。扫描现有技能、代理配置、README、源码结构。

Step 2: Interview the User

步骤2：与用户访谈

Do not skip this step. Ask focused questions to align with the user before writing any files.

For from-scratch companies, ask about:

Company purpose and domain (1-2 sentences is fine)
What agents they need - propose a hiring plan based on what they described
Whether this is a full company (needs a CEO) or a team/department (no CEO required)
Any specific skills the agents should have
How work flows through the organization (see "Workflow" below)
Whether they want projects and starter tasks

For from-repo companies, present your analysis and ask:

Confirm the agents you plan to create and their roles
Whether to reference or vendor any discovered skills (default: reference)
Any additional agents or skills beyond what the repo provides
Company name and any customization
Confirm the workflow you inferred from the repo (see "Workflow" below)

Workflow — how does work move through this company?

A company is not just a list of agents with skills. It's an organization that takes ideas and turns them into work products. You need to understand the workflow so each agent knows:

Who gives them work and in what form (a task, a branch, a question, a review request)
What they do with it
Who they hand off to when they're done, and what that handoff looks like
What "done" means for their role

Not every company is a pipeline. Infer the right workflow pattern from context:

Pipeline — sequential stages, each agent hands off to the next. Use when the repo/domain has a clear linear process (e.g. plan → build → review → ship → QA, or content ideation → draft → edit → publish).
Hub-and-spoke — a manager delegates to specialists who report back independently. Use when agents do different kinds of work that don't feed into each other (e.g. a CEO who dispatches to a researcher, a marketer, and an analyst).
Collaborative — agents work together on the same things as peers. Use for small teams where everyone contributes to the same output (e.g. a design studio, a brainstorming team).
On-demand — agents are summoned as needed with no fixed flow. Use when agents are more like a toolbox of specialists the user calls directly.

For from-scratch companies, propose a workflow pattern based on what they described and ask if it fits.

For from-repo companies, infer the pattern from the repo's structure. If skills have a clear sequential dependency (like

plan-ceo-review → plan-eng-review → review → ship → qa

), that's a pipeline. If skills are independent capabilities, it's more likely hub-and-spoke or on-demand. State your inference in the interview so the user can confirm or adjust.

Key interviewing principles:

Propose a concrete hiring plan. Don't ask open-ended "what agents do you want?" - suggest specific agents based on context and let the user adjust.
Keep it lean. Most users are new to agent companies. A few agents (3-5) is typical for a startup. Don't suggest 10+ agents unless the scope demands it.
From-scratch companies should start with a CEO who manages everyone. Teams/departments don't need one.
Ask 2-3 focused questions per round, not 10.

请勿跳过此步骤。在编写任何文件前，提出针对性问题与用户对齐需求。

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

公司目标与领域（1-2句话即可）
需要哪些代理——根据用户描述提出招聘方案并让用户调整
这是完整公司（需要CEO）还是团队/部门（无需CEO）
代理应具备的特定技能
工作在组织内的流转方式（见下文“工作流”）
是否需要项目和初始任务

对于基于仓库的公司，先展示分析结果，再询问：

确认计划创建的代理及其角色
是否引用或内置发现的技能（默认：引用）
除仓库提供的内容外，是否需要额外的代理或技能
公司名称及定制需求
确认从仓库推断出的工作流（见下文“工作流”）

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

公司不只是拥有技能的代理列表，而是将想法转化为工作成果的组织。你需要理解工作流，让每个代理清楚：

谁会给他们分配工作，以及工作的形式（任务、分支、问题、审核请求）
他们需要完成什么
完成后交接给谁，以及交接的形式
他们的角色中“完成”的定义是什么

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

流水线——顺序阶段，每个代理将工作交接给下一个。适用于仓库/领域有明确线性流程的场景（例如：规划→构建→审核→发布→QA，或内容构思→起草→编辑→发布）。
中心辐射型——管理者将任务委派给专家，专家独立汇报。适用于代理从事互不关联的不同工作的场景（例如：CEO向研究员、营销人员和分析师分派任务）。
协作型——代理作为同伴共同处理同一事务。适用于小型团队，所有人都为同一输出做贡献（例如：设计工作室、头脑风暴团队）。
按需型——根据需要调用代理，无固定流程。适用于代理更像用户直接调用的专家工具箱的场景。

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

对于基于仓库的公司，从仓库结构推断模式。如果技能有明确的顺序依赖（如

plan-ceo-review → plan-eng-review → review → ship → qa

），则为流水线模式。如果技能是独立的能力，则更可能是中心辐射型或按需型。在访谈中说明你的推断，让用户确认或调整。

核心访谈原则：

提出具体的招聘方案。不要问开放式的“你想要什么代理？”——根据上下文建议具体的代理，让用户调整。
保持精简。大多数用户不熟悉代理公司。初创公司通常需要3-5个代理。除非范围要求，否则不要建议10个以上的代理。
从头创建的公司应从管理所有代理的CEO开始。团队/部门无需CEO。
每轮提出2-3个针对性问题，而非10个。

Step 3: Read the Spec

步骤3：阅读规范

Before generating any files, read the normative spec at:

https://agentcompanies.io/specification

Also read the local quick reference: references/companies-spec.md

And the example: references/example-company.md

在生成任何文件前，请阅读以下标准规范：

https://agentcompanies.io/specification

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

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

Step 4: Generate the Package

步骤4：生成包

Create the directory structure and all files. Follow the spec's conventions exactly.

Directory structure:

<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)

Rules:

Slugs must be URL-safe, lowercase, hyphenated
COMPANY.md gets
```
schema: agentcompanies/v1
```
- other files inherit it
Agent instructions go in the AGENTS.md body, not in .paperclip.yaml
Skills referenced by shortname in AGENTS.md resolve to
```
skills/<shortname>/SKILL.md
```
For external skills, use
```
sources
```
with
```
usage: referenced
```
(see spec section 12)
Do not export secrets, machine-local paths, or database IDs
Omit empty/default fields

For companies generated from a repo, add a references footer at the bottom of COMPANY.md body:

Generated from [repo-name](repo-url) with the company-creator skill from [Paperclip](https://github.com/paperclipai/paperclip)

Reporting structure:

Every agent except the CEO should have
```
reportsTo
```
set to their manager's slug
The CEO has
```
reportsTo: null
```
For teams without a CEO, the top-level agent has
```
reportsTo: null
```

Writing workflow-aware agent instructions:

Each AGENTS.md body should include not just what the agent does, but how they fit into the organization's workflow. Include:

Where work comes from — "You receive feature ideas from the user" or "You pick up tasks assigned to you by the CTO"
What you produce — "You produce a technical plan with architecture diagrams" or "You produce a reviewed, approved branch ready for shipping"
Who you hand off to — "When your plan is locked, hand off to the Staff Engineer for implementation" or "When review passes, hand off to the Release Engineer to ship"
What triggers you — "You are activated when a new feature idea needs product-level thinking" or "You are activated when a branch is ready for pre-landing review"

This turns a collection of agents into an organization that actually works together. Without workflow context, agents operate in isolation — they do their job but don't know what happens before or after them.

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

目录结构：

<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正文底部添加引用页脚：

Generated from [repo-name](repo-url) with the company-creator skill from [Paperclip](https://github.com/paperclipai/paperclip)

Step 5: Confirm Output Location

步骤5：确认输出位置

Ask the user where to write the package. Common options:

A subdirectory in the current repo
A new directory the user specifies
The current directory (if it's empty or they confirm)

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

Step 6: Write README.md and LICENSE

步骤6：编写README.md和LICENSE

README.md — every company package gets a README. It should be a nice, readable introduction that someone browsing GitHub would appreciate. Include:

Company name and what it does
The workflow / how the company operates
Org chart as a markdown list or table showing agents, titles, reporting structure, and skills
Brief description of each agent's role
Citations and references: link to the source repo (if from-repo), link to the Agent Companies spec (https://agentcompanies.io/specification), and link to Paperclip (https://github.com/paperclipai/paperclip)
A "Getting Started" section explaining how to import:
```
paperclipai company import --from <path>
```

LICENSE — include a LICENSE file. The copyright holder is the user creating the company, not the upstream repo author (they made the skills, the user is making the company). Use the same license type as the source repo (if from-repo) or ask the user (if from-scratch). Default to MIT if unclear.

README.md——每个公司包都需要README。它应该是一份易于阅读的介绍，适合GitHub浏览者。内容包括：

公司名称及其功能
工作流/公司运营方式
组织架构：以Markdown列表或表格展示代理、职位、汇报结构和技能
每个代理角色的简要描述
引用与参考：链接到源仓库（如果是基于仓库生成）、Agent Companies规范（https://agentcompanies.io/specification）和Paperclip（https://github.com/paperclipai/paperclip）
“快速开始”部分：说明如何导入：
```
paperclipai company import --from <path>
```

Step 7: Write Files and Summarize

步骤7：写入文件并总结

Write all files, then give a brief summary:

Company name and what it does
Agent roster with roles and reporting structure
Skills (custom + referenced)
Projects and tasks if any
The output path

写入所有文件后，提供简要总结：

公司名称及其功能
代理名单，包括角色和汇报结构
技能（自定义+引用）
项目和任务（如有）
输出路径

.paperclip.yaml Guidelines

.paperclip.yaml 指南

The

.paperclip.yaml

file is the Paperclip vendor extension. It configures adapters and env inputs per agent.

.paperclip.yaml

文件是Paperclip的厂商扩展，用于为每个代理配置适配器和环境输入。

Adapter Rules

适配器规则

Do not specify an adapter unless the repo or user context warrants it. If you don't know what adapter the user wants, omit the adapter block entirely — Paperclip will use its default. Specifying an unknown adapter type causes an import error.

Paperclip's supported adapter types (these are the ONLY valid values):

```
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 gateway

Only set an adapter when:

The repo or its skills clearly target a specific runtime (e.g. gstack is built for Claude Code, so
```
claude_local
```
is appropriate)
The user explicitly requests a specific adapter
The agent's role requires a specific runtime capability

除非仓库或用户上下文有要求，否则请勿指定适配器。 如果你不知道用户需要什么适配器，完全省略适配器块——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 gateway

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

仓库或其技能明确针对特定运行时（例如gstack是为Claude Code构建的，因此
```
claude_local
```
适用）
用户明确要求特定适配器
代理角色需要特定运行时能力

Env Inputs Rules

环境输入规则

Do not add boilerplate env variables. Only add env inputs that the agent actually needs based on its skills or role:

```
GH_TOKEN
```
for agents that push code, create PRs, or interact with GitHub
API keys only when a skill explicitly requires them
Never set
```
ANTHROPIC_API_KEY
```
as a default empty env variable — the runtime handles this

Example with adapter (only when warranted):

yaml

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

Example — only agents with actual overrides appear:

yaml

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

In this example, only

release-engineer

appears because it needs

GH_TOKEN

. The other agents (ceo, cto, etc.) have no overrides, so they are omitted entirely from

.paperclip.yaml

请勿添加样板环境变量。 仅添加代理根据其技能或角色实际需要的环境输入：

```
GH_TOKEN
```
：用于推送代码、创建PR或与GitHub交互的代理
API密钥：仅当技能明确需要时添加
请勿默认设置空的
```
ANTHROPIC_API_KEY
```
环境变量——运行时会处理此问题

带适配器的示例（仅在必要时使用）：

yaml

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

示例——仅显示有实际覆盖配置的代理：

yaml

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

在此示例中，仅

release-engineer

出现，因为它需要

GH_TOKEN

。其他代理（ceo、cto等）没有覆盖配置，因此完全从.paperclip.yaml中省略。

External Skill References

外部技能引用

When referencing skills from a GitHub repo, always use the references pattern:

yaml

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

Get the commit SHA with:

bash

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

Do NOT copy external skill content into the package unless the user explicitly asks.

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

yaml

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：

bash

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

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

Tips

提示

Try to keep agents 1:1 - if the readme of the source repo says something like "48 agents, 37 workflows" - then you should have 48 agents when you're done. Though when you have a lot of agents, it's a good idea to invent middle management to break them up into teams.
Cite the upstream repo in the README - If you're generating a readme from an upstream github, be sure to credit that near the top of the README.md. Link to the original repo and describe what it does. E.g. an Agent Company based on GStack to do <thing>

尽量保持代理1:1对应——如果源仓库的README提到“48个代理，37个工作流”，那么最终你也应该创建48个代理。不过当代理数量较多时，建议设置中层管理将他们划分为团队。
在README中引用上游仓库——如果你基于上游GitHub仓库生成README，请确保在README.md顶部附近注明来源。链接到原始仓库并描述其功能。例如：基于GStack构建的Agent Company，用于<功能描述>