Enterprise Team— plugin

<p align="center"> <img src="https://img.shields.io/badge/Claude_Code-Plugin-blueviolet?style=for-the-badge" alt="Claude Code Plugin"/> <img src="https://img.shields.io/badge/Agents-75-green?style=for-the-badge" alt="75 Agents"/> <img src="https://img.shields.io/badge/Departments-10-blue?style=for-the-badge" alt="10 Departments"/> <img src="https://img.shields.io/badge/Model-Opus-purple?style=for-the-badge" alt="Opus Powered"/> </p>

<h1 align="center">Enterprise Team</h1>

<p align="center"> <strong>Hire a whole company with one plugin.</strong><br/> 75 specialized AI agents across Engineering, Product, Infrastructure, Data, Security, Marketing, Sales, Finance, Legal, and People. </p>

<p align="center"> <img src="assets/brain-meme.jpg" alt="Evolution: ChatGPT → Claude Code → Claude Code with skills → 75 AI employees auto-routing your requests" width="100%"/> </p>

The Problem with Generalist Agents

When you ask Claude Code to "build me a dashboard," it does its best. But Claude is trying to be everything at once: frontend developer, backend engineer, database architect, and UI designer. The result? Competent but generic work.

The real issue is context switching at scale. A generalist agent:

• Has to hold patterns for dozens of domains simultaneously
• Can't go deep on any single specialty
• Applies the same approach whether the task needs a security mindset or a marketing mindset
• Doesn't know when to ask for help from a different discipline

You end up with code that works but doesn't reflect what a dedicated specialist would produce. The API design a backend-focused engineer would craft. The component architecture a frontend specialist would build. The security hardening an AppSec engineer would insist on.

Skills help, but they're manual. You have to know which skill to invoke, when to switch contexts, and how to coordinate handoffs between different specialties. That cognitive load is on you.

A Different Approach

What if Claude Code could operate like an actual company?

The key insight: departments exist for a reason. Real organizations don't have one person doing everything. They have specialists who go deep, orchestrated by managers who route work to the right people.

Enterprise Team replicates this structure:

1. Department Orchestrators understand what their specialists do and route work accordingly
2. Specialists go deep on their domain with focused system prompts, tools, and patterns
3. Cross-functional routing means a single request can flow through multiple departments seamlessly

When you say "build me a settings page with dark mode," Enterprise Team doesn't just write code. The orchestrator recognizes this needs:

• Frontend Engineer for component architecture
• UI Designer for the visual system
• Backend Engineer if settings need persistence
• Security Engineer if settings include sensitive data

Each specialist contributes their expertise. The result is closer to what a real team would produce.

<p align="center"> <img src="assets/no-more-guessing.png" alt="No More Guessing - Enterprise Team Routes to the Right Specialists" width="100%"/> </p>

How It Works

Phase 1: Request Analysis

When you make a request, the orchestration layer analyzes it:

User: "Set up authentication with OAuth and add a login page"

The orchestrator identifies:

• Primary domain: Engineering (auth system + UI)
• Specialists needed: Backend Engineer (OAuth flow), Frontend Engineer (login page), Security Engineer (token handling)
• Sequence: Security review of approach → Backend implementation → Frontend integration

Phase 2: Specialist Dispatch

Each specialist receives:

• The original request with relevant context
• Their domain-specific system prompt (security mindset, performance focus, etc.)
• Access to tools appropriate for their role
• Awareness of what other specialists are handling

The Backend Engineer focuses on:

• OAuth provider integration
• Token refresh logic
• Session management
• API endpoint design

The Frontend Engineer focuses on:

• Login form UX
• Error state handling
• Loading states
• Redirect flows

The Security Engineer reviews:

• Token storage (not localStorage!)
• CSRF protection
• Rate limiting needs
• Secure cookie configuration

Phase 3: Integration

Work products from specialists are integrated with awareness of each other. The frontend engineer knows what endpoints the backend engineer created. The security engineer's requirements are applied to both.

When Departments Hand Off

Cross-functional work is common:

Example Session

User: Build a user settings page where users can update their profile,
      change their password, and manage notification preferences.

Orchestrator: This request spans multiple specialties. Routing to:
  - UI Designer: Settings page layout and component design
  - Frontend Engineer: Implementation and state management
  - Backend Engineer: API endpoints for settings CRUD
  - Security Engineer: Password change flow review

[UI Designer]
Designing settings page structure:
- Tab-based navigation (Profile | Security | Notifications)
- Form sections with clear hierarchy
- Inline validation feedback
- Responsive layout for mobile

[Frontend Engineer]
Implementing settings components:
- useSettings hook for state management
- Form validation with react-hook-form
- Optimistic updates with rollback
- Tab routing with URL sync

[Backend Engineer]
Creating settings API:
- GET/PATCH /api/settings/profile
- POST /api/settings/password (requires current password)
- GET/PATCH /api/settings/notifications
- Rate limiting on password endpoint

[Security Engineer]
Security review:
✓ Password change requires current password verification
✓ Password strength requirements enforced
✓ Session invalidation option after password change
⚠ Recommend: Add email notification on password change
⚠ Recommend: Add 2FA prompt for security settings

Orchestrator: Implementation complete. Security recommendations
flagged for your review.

Quick Start

1. Add the marketplace

In Claude Code, run:

/plugin marketplace add Chipagosfinest/enterprise-team

2. Install the plugin

/plugin install enterprise-team@enterprise-plugins

That's it. The plugin is now available in any project. Then just ask for what you need:

"Design and build a settings page with dark mode"
"Set up CI/CD with GitHub Actions"
"Create a financial model for our Q2 projections"
"Review this code for security vulnerabilities"
"Plan our product launch campaign"

The orchestrator routes to the right specialists automatically.

By default, the plugin now activates enterprise-orchestrator as the main agent through settings.json, so you are dropped into the routing layer instead of hoping Claude picks the right specialist on its own.

Departments & Specialists

Engineering (10 specialists)

Infrastructure (4 specialists)

Product (5 specialists)

Data (3 specialists)

Security (3 specialists)

Marketing (14 specialists)

Sales (5 specialists)

Finance (4 specialists)

Legal (4 specialists)

People (6 specialists)

Support (4 specialists)

Consulting (2 specialists)

Program Management (1 specialist)

Why This Approach?

Enterprise Team shines when:

• You don't know which specialty a task needs
• Work crosses multiple domains (most real work does)
• You want specialist-quality output without manual orchestration
• The request is ambiguous and benefits from multiple perspectives

The tradeoff: More comprehensive responses, slightly more tokens. If you know exactly what you need and just want a quick answer, a single skill or direct prompt might be faster.

Collaboration Protocol (v2.2.0)

Enterprise Team ships with a formal inter-agent collaboration protocol for multi-agent work. Every orchestrator follows the same rules, so routing, review, and escalation stay auditable.

Capability-Based Routing

Agents no longer escalate up an org chart. They route by capability. Each agent declares capabilities in frontmatter using a controlled vocabulary (25 domains + freeform qualifiers):

capabilities:
  - auth: [oauth2, pkce, jwt]
  - backend: [nodejs, python]
  - database: [postgresql, supabase, rls]

When a task needs auth work, the orchestrator matches on the auth domain first, then refines by qualifier (oauth2 beats jwt for OAuth tasks). Every routing decision produces an auditable Routing Decision artifact: requested capability, matched agents, selected, rejected, tie-break rule.

Qualifiers are normalized (lowercase, trim, alias-mapped) so postgres, Postgres, postgresql, and pg all match. See capability-aliases.yaml.

Honest note on implementation: capabilities: is NOT a Claude Code runtime config field — the runtime ignores it. It is a protocol convention. The orchestrator reads capability-index.yaml, which is auto-generated from agent frontmatter by scripts/build-capability-index.sh. Regenerate after any frontmatter change; CI should diff-check the generated index to catch drift.

Tie-break rules (deterministic from current task context):

1. Qualifier match count — agent covering the most requested qualifiers
2. Same-department affinity — only as final tiebreaker
3. If still tied — orchestrator picks one and documents exactly why

Load-balancing ("fewer current assignments") is intentionally excluded: no durable assignment ledger exists, so any such rule would be non-auditable across sessions.

Task ID Gating

Every task gets an orchestrator-issued ID (DEPT-NNN, e.g., ENG-042) and a declared file scope at dispatch. Agents must file a scope-expansion record before touching undeclared files. Undeclared changes are rejected — you either expand the scope with justification or revert.

Three tiers of enforcement (use what fits your setup):

The Tier 2 hook requires the orchestrator to declare both ## Expected file scope: [...] and ## Baseline SHA: <sha> in the Task prompt. The hook diffs against that baseline, not the full working tree, so it does not produce false violations from unrelated dirty state. If either declaration is missing, the hook gracefully degrades to Tier 1.

Risk-Classified Review (replaces self-reported confidence)

Risk is classified at dispatch by the orchestrator, not self-reported by the agent:

Evidence is conjunctive — all listed items required, not a menu. High-risk work cannot be auto-approved; it blocks to the user if no reviewer is available.

Reclassification: risk is re-evaluated on completion. A task dispatched as LOW that ends up touching auth middleware gets upgraded to HIGH, and the higher evidence requirements apply retroactively.

Failure-Reason Routing (replaces retry count)

When a specialist escalates, they classify the failure type:

• wrong-capability → reroute to the right capability
• task-too-large → decompose into subtasks
• conflicting-requirements → escalate to product-manager for spec clarity
• environment-issue → route to devops-engineer or sre
• insufficient-context → route to the knowledge holder
• unknown → orchestrator investigates

Retry count is a fallback signal. Failure-reason is the primary routing input.

Transport-Neutral Interaction Records

Every consequential exchange produces an Interaction Record (see skills/handoff-protocol/SKILL.md). Same schema regardless of transport:

• Agent Teams mode (CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1): delivered via SendMessage between teammates
• Fallback mode: delivered via the Task tool prompt to subagents

Agent Teams mode allows peers to message each other directly, but authority stays with the orchestrator: peers may propose, not commit. Consequential agreements must be recorded before any code changes.

Troubleshooting

Routing feels inconsistent

Make sure the plugin is reloaded after upgrade:

/reload-plugins

This version ships a default settings.json that activates enterprise-orchestrator automatically. If you are still seeing generalist behavior, confirm the plugin is enabled and that another plugin is not overriding the active default agent.

Codex compatibility

This repo also ships enterprise-team/AGENTS.md so the same department-routing model can be reused in Codex-style environments. Claude Code uses the plugin manifest and settings.json; Codex-style agents can read the AGENTS instructions as the equivalent orchestration entrypoint.

Install returns no output

If /plugin install enterprise-team@enterprise-plugins returns nothing, a folder or symlink with the same name likely already exists:

# Check for existing installation
ls -la ~/.claude/plugins/enterprise-team

# If it's a symlink (for local development), remove it first
rm ~/.claude/plugins/enterprise-team

# Then retry install
/plugin install enterprise-team@enterprise-plugins

Marketplace not found

Make sure you've added the marketplace first:

/plugin marketplace add Chipagosfinest/enterprise-team

Plugin not loading

Restart Claude Code after installation to ensure the plugin is loaded.

Contributing

Want to add plugins to this marketplace? See CONTRIBUTING.md.

License

MIT © Alec Gutman