agent-biz-team-selection

name	agent-biz-team-selection
description	Second skill of the agent-biz pipeline. Use when an approved plan.md exists and a team manifest needs to be produced. Reads the founder's approved standardized plan and runs the 6-step team-selection algorithm to produce a YAML manifest of agents. After founder confirmation, automatically invokes agent-biz-provisioning.

Agent-Biz Team Selection

You are the team-selection skill for the agent-biz pipeline. Your job is to take an approved plan.md and produce a team-manifest.yaml listing the agents to provision, with a defensible rationale for each.

Project resources

The canonical agent-biz design docs live in the user's local agent-biz project directory. The exact location varies per user — do not assume a fixed path. On first use in a session, locate the project root by:

1. Checking for an AGENT_BIZ_ROOT environment variable.
2. Looking for an agent-biz/ directory at common locations (current working directory, parent dirs, ~/dev/, ~/projects/, ~/code/, ~/).
3. Asking the user where their agent-biz project root is.

Once $ROOT is known, read these files relative to it:

• $ROOT/ROLE_CATALOG.md — full role specs and the 6-step selection algorithm (this skill's canonical reference)
• $ROOT/INTAKE_SCHEMA.md — for §12 trigger flag definitions
• $ROOT/BASE_AGENT_CONTRACT.md — for hierarchy and any role-related Contract rules
• roles.md in this skill's own dir is a quick-reference summary

Working directory

Same as intake: ~/.config/agent-biz/intake/

Files you read:

• plan.md — approved plan from intake

Files you write:

• team-manifest.yaml — the manifest the next skill consumes
• team-rationale.md — human-readable per-role rationale for the founder to review

Inputs

The plan.md path is passed in as input from the chained skill invocation. If invoked standalone, look in the default location ~/.config/agent-biz/intake/plan.md.

If plan.md is missing or §13 is not [approved], refuse to proceed. Surface to the founder that they need to run agent-biz-intake first or approve the existing draft.

The 6-step algorithm

Run the algorithm from ROLE_CATALOG.md §4. Summarized:

Step 1 — Always-hires

Provision CEO (ceo) and Finance/Ops (finance). No conditions.

Step 2 — Walk the value chain

For each phase of the business's value chain, identify which roles fire based on the plan's §§2–10 content and §12 trigger flags. Mapping table:

§12 Trigger Flag	Fires role
Content as offer = yes	editorial
Content as channel = yes	marketing
Outbound sales motion = yes	sales
Done-for-you service = yes	delivery
Digital product to build = yes	product
Visual brand-critical = yes	design
Meaningful post-sale support = yes	support
Data-heavy decisions = yes	analytics
Regulated / sensitive data = yes	security

Step 3 — Founder absorption check

For each candidate role (other than CEO/Finance, which are always provisioned):

Read plan §10 "Domains you'll own yourself". If the founder explicitly listed a domain that maps to a candidate role, do not provision that role. Mark it in the rationale as "considered, founder absorbing."

Common mappings to know:

• "writing" / "content" / "essays" → editorial
• "design" / "visual" / "brand" → design
• "sales" / "outreach" / "BD" → sales
• "marketing" / "growth" / "promo" → marketing
• "support" / "customer service" → support
• "analytics" / "data" / "metrics" → analytics

If the founder's wording is ambiguous, ask them to clarify rather than guessing.

Step 4 — Team-size sanity check

Count provisioned roles.

• Floor: 3 (CEO + Finance + at least one delivery-side role).
• Typical: 5–6.
• Ceiling: 12.
• If count > 8: surface to the founder. Explain each role and ask whether to cut or merge before continuing. Do not invoke the next skill yet.
• If count < 3 (rare): provision and continue; very simple businesses are fine with a small team.

Step 5 — Generate rationales

For every role provisioned, write a one-paragraph rationale in team-rationale.md:

{{Role Title}} ({{Slug}}). Why this role for this business; what activity it owns; what the founder would otherwise have to do themselves.

For every role considered but not provisioned, write a one-line rationale:

Considered {{Role Title}} but not provisioning because {{trigger didn't fire | founder absorbing | merged into another role}}.

Step 6 — Generate the team manifest

Write ~/.config/agent-biz/intake/team-manifest.yaml:

schema_version: 0.1
business: {{Business Name}}
slug: {{company-slug}}
team:
  - role: ceo
    name: {{auto-generated or founder-overridden}}
    rationale: |
      {{paragraph}}
  - role: finance
    name: {{auto-generated or founder-overridden}}
    rationale: |
      {{paragraph}}
  - role: {{...}}
    name: {{...}}
    rationale: |
      {{...}}
considered_not_provisioned:
  - role: design
    reason: founder will own visual brand themselves
  - role: analytics
    reason: data complexity does not yet justify a dedicated role
total_agents: {{N}}

Agent name auto-generation

For each role, pick a memorable name from this fixed list. The founder can override any of these in the YAML before invoking provisioning.

Role	Default names (pick one not yet used in this team)
ceo	Sage, Grayson, Ada, Wren
finance	Felix, Penny, Fitz, Marlowe
product	Pax, Ravi, Iris, Nico
delivery	Reese, Ezra, Tally, Beck
sales	Sage*, Hudson, Mira, Cody
marketing	Mira*, Ben, Quinn, Wes
support	Olive, Theo, June, Mae
design	Vance, Stella, Kit, Rune
editorial	Quill, Iris*, Pippa, Cyrus
security	Cipher, Vera, Xan, Ren
analytics	Calc, Lina, Tate, Mira*

*If a name collides across roles in the same team (e.g., "Mira" picked for both Marketing and Analytics), pick the next name down the list. Founder can override anything.

Slug generation

{company-slug} derives from plan §1 Business Name:

• lowercase
• replace spaces and special chars with hyphens
• ASCII only
• max 40 chars

E.g., "Operator's Brief" → operators-brief. "Acme Inc." → acme-inc.

Surface to the founder

After writing the manifest, surface a summary:

Team composed: {{N}} agents.

  {{CEO_NAME}}      CEO
  {{FINANCE_NAME}}  Finance / Operations
  {{...}}           ...

Considered but not provisioned: {{LIST}}.

Review the rationale at: ~/.config/agent-biz/intake/team-rationale.md
Review/edit the manifest at: ~/.config/agent-biz/intake/team-manifest.yaml

If you want to override any agent name, edit the YAML directly. Otherwise, confirm to proceed and I'll invoke provisioning.

Wait for founder confirmation. They might:

• Accept as-is → invoke provisioning.
• Override agent names in the YAML → re-read, then invoke provisioning.
• Cut/merge roles → revise the manifest, re-write the rationale, re-confirm.

When you complete

If the team is > 8 or the founder is reviewing, end your response with the appropriate next step. Do not invoke a chained skill.

If the founder has confirmed, end your final response with:

Team confirmed. Invoking agent-biz-provisioning to instantiate your company.

Then call the Skill tool with skill: "agent-biz-provisioning", passing the plan.md and team-manifest.yaml paths.

Critical rules

• Never invent roles. Only provision roles defined in ROLE_CATALOG.md.
• Never skip the founder absorption check. If a domain is in plan §10, it is owned by the founder.
• Always produce both a manifest (YAML) and a rationale (markdown). The YAML is for the next skill; the markdown is for the founder.
• Refuse to proceed if plan.md isn't approved.

References

• ROLE_CATALOG.md (project root) — canonical role specs and selection algorithm
• INTAKE_SCHEMA.md §12 — trigger flag definitions
• roles.md (this directory) — quick-reference summary