company-creator

Company Creator

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

仕様の参照先：

• 規範仕様：docs/companies/companies-spec.md（ファイルを生成する前にお読みください）
• Web 仕様：https://agentcompanies.io/specification
• プロトコルサイト：https://agentcompanies.io/

2 つのモード

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

ユーザーが希望する内容を説明します。ビジョンを具体化するために質問し、その後パッケージを生成します。

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

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

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

プロセス

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

該当するモードを判断します。

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

ステップ 2：ヒアリング（AskUserQuestion を使用）

ファイルを書き込む前に、必ずこのステップを実施してユーザーとの認識を合わせてください。省略しないでください。

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

• 会社の目的と分野（1～2 文でかまいません）
• どのようなエージェントが必要か。ユーザーの説明に基づいて採用計画を提案してください。
• CEO が必要な会社全体なのか、CEO が不要なチーム／部門なのか
• エージェントに必要な特定のスキル
• 組織内での業務の流れ（下記の「ワークフロー」を参照）
• プロジェクトとスタータータスクが必要かどうか

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

• 作成予定のエージェントとその役割の確認
• 見つかったスキルを参照するか、取り込むか（デフォルトは参照）
• リポジトリに含まれていない追加のエージェントやスキルがあるか
• 会社名とカスタマイズの内容
• リポジトリから推測したワークフローの確認（下記の「ワークフロー」を参照）

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

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

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

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

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

ゼロから会社を作成する場合は、説明に基づいてワークフローパターンを提案し、適切かどうか確認してください。

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

ヒアリングの基本原則：

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

ステップ 3：仕様を読む

ファイルを生成する前に、規範仕様を読んでください。

docs/companies/companies-spec.md

クイックリファレンスも読んでください：references/companies-spec.md

サンプルも読んでください：references/example-company.md

Step 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. 引き継ぎ先 — 「計画が確定したら、実装のために Staff Engineer に引き継ぎます」や「レビューに合格したら、リリースのために Release Engineer に引き継ぎます」
4. 起動のきっかけ — 「新しい機能のアイデアにプロダクトレベルの検討が必要になったときに起動します」や「ブランチがリリース前レビューの準備を整えたときに起動します」

これにより、エージェントの集まりが、実際に連携して機能する組織になります。ワークフローの文脈がないと、エージェントは孤立して動作し、業務をこなしても、その前後に何が起きるか把握できません。

生成するすべての実働エージェントに、簡潔な実行契約を追加します。

• 実行可能な作業は同じハートビート内に開始し、計画の作成を求められた場合を除き、計画だけで終わらせないでください。
• コメント、ドキュメント、成果物に、次のアクションとともに、後から確認できる進捗を残してください。
• 長期にわたる委任作業や並行作業には、エージェント、セッション、プロセスをポーリングするのではなく、子イシューを使用してください。
• 作業がブロックされた場合は、ブロック解除の担当者とアクションを明記してください。
• 予算、一時停止／キャンセル、承認ゲート、会社の境界を遵守してください。

Step 5: 出力先を確認する

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

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

Step 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 をデフォルトにします。

Step 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

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