company-creator

Company Creator

Agent Companies 仕様に準拠したエージェント企業パッケージを作成します。

仕様の参照先：

• 規範仕様：https://agentcompanies.io/specification
• ローカルのクイックリファレンス：references/companies-spec.md
• プロトコルサイト：https://agentcompanies.io/

2 つのモード

モード 1：ゼロから企業を作成

ユーザーが希望する内容を説明します。ビジョンを具体化するためにヒアリングしてから、パッケージを生成します。

モード 2：リポジトリから企業を作成

ユーザーから Git リポジトリの URL、ローカルパス、またはツイートが提供されます。リポジトリを分析して、それをラップする企業を作成します。

リポジトリ分析の詳しい手順については、references/from-repo-guide.md を参照してください。

プロセス

ステップ 1：コンテキストを収集する

どちらのモードに該当するかを判断します。

• ゼロから作成：どのような企業またはチームですか？ どのような分野ですか？ エージェントには何をさせますか？
• リポジトリから作成：リポジトリをクローンまたは読み込みます。既存のスキル、エージェント設定、README、ソース構造を調べます。

Step 2: ユーザーにヒアリングする

ファイルを書き始める前に、必ずこのステップを実施してください。ユーザーに焦点を絞った質問をして、認識を合わせます。

ゼロから会社を作る場合は、以下について質問してください。

• 会社の目的と事業領域（1～2文で十分です）
• 必要なエージェント — ユーザーの説明に基づいて採用計画を提案します
• CEOが必要な会社全体なのか、CEOが不要なチーム／部門なのか
• エージェントに必要な特定のスキル
• 組織内で仕事がどのように進むか（下記の「ワークフロー」を参照）
• プロジェクトと初期タスクを作成するかどうか

リポジトリから会社を作る場合は、分析結果を提示して、以下について質問してください。

• 作成予定のエージェントとその役割の確認
• 発見したスキルを参照するか、同梱するか（デフォルト：参照）
• リポジトリが提供するもの以外に、追加のエージェントやスキルが必要かどうか
• 会社名とカスタマイズ内容
• リポジトリから推測したワークフローの確認（下記の「ワークフロー」を参照）

ワークフロー — この会社では仕事がどのように進みますか？

会社は、スキルを持つエージェントの一覧にすぎません。アイデアを成果物に変える組織です。各エージェントが以下を把握できるよう、ワークフローを理解する必要があります。

• 誰から、どのような形で仕事を受け取るか（タスク、ブランチ、質問、レビュー依頼など）
• 受け取った仕事にどう取り組むか
• 完了後、誰に引き継ぐか。また、その引き継ぎはどのような形か
• その役割における「完了」の定義

**すべての会社がパイプライン型とは限りません。**状況から適切なワークフローパターンを推測してください。

• パイプライン — 順序立てた段階があり、各エージェントが次のエージェントに引き継ぎます。リポジトリや事業領域に明確な直線的プロセスがある場合に使います（例：計画 → 構築 → レビュー → リリース → QA、またはコンテンツのアイデア出し → 下書き → 編集 → 公開）。
• ハブ・アンド・スポーク — マネージャーが専門家に仕事を委任し、それぞれが個別に報告します。互いに連携しない異なる種類の仕事をエージェントが担当する場合に使います（例：CEOがリサーチャー、マーケター、アナリストに仕事を割り振る）。
• コラボレーション型 — エージェントが対等な立場で同じ仕事に協力して取り組みます。全員が同じ成果物に貢献する小規模チームに使います（例：デザインスタジオ、ブレインストーミングチーム）。
• オンデマンド型 — 決まった流れはなく、必要に応じてエージェントを呼び出します。ユーザーが直接呼び出す専門家のツールボックスのようなエージェントに使います。

ゼロから会社を作る場合は、ユーザーの説明に基づいてワークフローパターンを提案し、合っているかどうかを尋ねます。

リポジトリから会社を作る場合は、リポジトリの構成からパターンを推測します。スキルに明確な順次依存関係がある場合（plan-ceo-review → plan-eng-review → review → ship → qa など）は、パイプラインです。スキルが独立した機能であれば、ハブ・アンド・スポーク型かオンデマンド型である可能性が高くなります。推測した内容をヒアリングで伝え、ユーザーに確認または調整してもらいます。

ヒアリングの重要な原則：

• 具体的な採用計画を提案します。「どんなエージェントがほしいですか？」という自由回答式の質問は避け、状況に基づいて具体的なエージェントを提案し、ユーザーが調整できるようにします。
• 必要最小限にとどめます。エージェント企業に慣れていないユーザーが大半です。スタートアップでは、エージェントは3～5体が一般的です。範囲上の必要がない限り、10体以上は提案しないでください。
• ゼロから作る会社では、全員を管理するCEOから始めます。チームや部門にはCEOは不要です。
• 1回のやり取りにつき、焦点を絞った質問を2～3個にします。10個は質問しないでください。

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

ルール：

• スラッグは URL で使用できる、小文字とハイフンのみの形式にします
• COMPANY.md には schema: agentcompanies/v1 を設定し、その他のファイルはこれを継承します
• エージェントへの指示は .paperclip.yaml ではなく、AGENTS.md の本文に記述します
• AGENTS.md で短縮名を使って参照するスキルは、skills/<shortname>/SKILL.md に解決されます
• 外部スキルには usage: referenced を指定した sources を使用します（仕様のセクション 12 を参照）
• シークレット、マシン固有のパス、データベース ID はエクスポートしないでください
• 空のフィールドやデフォルト値のフィールドは省略します
• リポジトリから生成した会社の場合は、COMPANY.md の本文末尾に参照フッターを追加します： Generated from [repo-name](repo-url) with the company-creator skill from [Paperclip](https://github.com/paperclipai/paperclip)

報告先の構造：

• CEO 以外のすべてのエージェントの reportsTo には、マネージャーのスラッグを設定します
• CEO の reportsTo は null にします
• CEO がいないチームでは、最上位のエージェントの reportsTo を null にします

ワークフローを考慮したエージェントへの指示を書く：

各 AGENTS.md の本文には、エージェントが何をするかだけでなく、組織のワークフローの中でどのような役割を担うかも記載します。以下を含めてください。

1. どこから仕事が来るか — 「ユーザーから機能のアイデアを受け取ります」または「CTO から割り当てられたタスクに取り組みます」
2. 何を作成するか — 「アーキテクチャ図を含む技術計画を作成します」または「レビューと承認を経た、リリース準備のできたブランチを作成します」
3. 誰に引き継ぐか — 「計画が確定したら、実装のためにスタッフエンジニアに引き継ぎます」または「レビューに合格したら、リリースエンジニアに引き継いでリリースします」
4. 何をきっかけに動くか — 「新しい機能のアイデアにプロダクトレベルの検討が必要になると、作業を開始します」または「ブランチがリリース前レビューに進める状態になると、作業を開始します」

これにより、エージェントの集まりが、実際に連携して機能する組織になります。ワークフローの情報がなければ、エージェントは孤立して動きます。つまり、自分の仕事はこなしても、その前後に何が起きるかはわかりません。

ステップ 5：出力先を確認する

パッケージの書き込み先をユーザーに尋ねます。一般的な選択肢は以下のとおりです。

• 現在のリポジトリ内のサブディレクトリ
• ユーザーが指定する新しいディレクトリ
• 現在のディレクトリ（空の場合、またはユーザーが使用を確認した場合）

ステップ 6：README.md と LICENSE を作成する

README.md — すべての会社パッケージに README を含めます。GitHub を見ている人にとって、読みやすく魅力的な紹介文にしてください。以下を含めます。

• 会社名とその事業内容
• ワークフロー／会社の運営方法
• エージェント、役職、報告先の構造、スキルを示す、Markdown のリストまたは表形式の組織図
• 各エージェントの役割の簡単な説明
• 出典と参照先：ソースリポジトリへのリンク（リポジトリから生成した場合）、Agent Companies 仕様（https://agentcompanies.io/specification）、Paperclip（https://github.com/paperclipai/paperclip）へのリンク
• インポート方法を説明する「Getting Started」セクション：paperclipai company import --from <path>

LICENSE — LICENSE ファイルを含めます。著作権者は、元のリポジトリの作者ではなく、会社を作成するユーザーです（スキルを作成したのは元のリポジトリの作者であり、会社を作成するのはユーザーです）。ソースリポジトリと同じライセンスの種類を使用します（リポジトリから生成した場合）。ゼロから作成した場合は、ユーザーに尋ねます。不明な場合は MIT をデフォルトとして使用します。

ステップ 7：ファイルを書き込み、要約する

すべてのファイルを書き込んだ後、簡単に要約します。

• 会社名とその事業内容
• エージェント一覧、役割、報告先の構造
• スキル（独自のもの＋参照するもの）
• プロジェクトとタスク（あれば）
• 出力パス

.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 ゲートウェイ

次の場合にのみ、アダプターを設定してください。

• リポジトリまたはそのスキルが特定のランタイムを明確に対象としている場合（例：gstack は Claude Code 用に構築されているため、claude_local が適切です）
• ユーザーが特定のアダプターを明示的に希望している場合
• エージェントの役割に特定のランタイム機能が必要な場合

環境変数入力のルール

定型的な環境変数を追加しないでください。 エージェントのスキルまたは役割に基づいて実際に必要な環境変数入力のみを追加してください。

• コードのプッシュ、PR の作成、GitHub との連携を行うエージェントには 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

例 — 実際にオーバーライドがあるエージェントのみが記載されます。

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

この例では、GH_TOKEN が必要なため release-engineer のみが記載されています。他のエージェント（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

ユーザーから明示的に依頼されない限り、外部スキルの内容をパッケージにコピーしないでください。

ヒント

• エージェントの数は、できるだけ 1 対 1 にしてください — 元のリポジトリの README に「48 agents, 37 workflows」のように記載されている場合は、完了時にエージェントを 48 個用意してください。ただし、エージェントが多い場合は、中間管理職を設けてチームに分けるとよいでしょう。

• README で元のリポジトリを明記してください — 上流の GitHub リポジトリから README を生成する場合は、README.md の上部付近でクレジットを記載してください。元のリポジトリへのリンクと、その内容の説明を含めます。例：GStack を基にした Agent Company で を実現

• すべての会社は CEO を含む、正しく構成されたグラフでなければなりません — すべてのエージェントが、1. 上司または 2. CEO のいずれかに報告するようにしてください。誰にも報告しない CEO が必要です。