[FEATURE] Multi-Repo Agent Teammates Auto-Detect and Load Relevant Skills

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Problem

When using TeamCreate to orchestrate work across multiple repositories, spawned teammates operate in the context of the leader's repository. They inherit the leader's skills and CLAUDE.md instructions, but have no awareness of the target repo's own .claude/ configuration.

This means:

Missing skills — If repo-b defines custom skills (e.g., a /adding-new-component or /adding-new-endpoint skill specific to that project), the teammate can't discover or use them. The leader has no way to forward them either.

We are using skills for defining our by-demand repo conventions either (we keep CLAUDE.md with "always-relevant" instructions only), so that leads to these not be available for the agents, resulting in bad output.

Who This Affects

Anyone using multi-agent teams for:

• Monorepo-adjacent workflows (multiple repos that need coordinated changes)
• Platform/infra teams making cross-cutting changes across service repos
• Basically, any TeamCreate usage where teammates operate on a different repo than the leader

Proposed Solution

Proposed Solution

Repo-aware teammate initialization

When a teammate is created via Task with a team_name, and its working directory resolves to a git repository different from the leader's, Claude Code should:

1. Detect the repo boundary — Resolve the teammate's working directory to its git root (or nearest .claude/ directory).

1. Load that repo's .CLAUDE.md — Inject it into the teammate's system context the same way it's loaded for a top-level claude session.

1. Register that repo's skills — Discover .claude/skills/ in the target repo and make those skills available to the teammate.

1. Respect that repo's settings.json — Apply the target repo's .claude/settings.json for teammate-scoped settings (e.g., allowed tools, permission overrides).

Leader visibility

The leader should be able to see which CLAUDE.md and skills a teammate loaded, either via:

• A field in the team config (~/.claude/teams/{name}/config.json)
• Or a log line in the teammate's output (e.g., Loaded .CLAUDE.md from /path/to/repo-b)

Opt-out mechanism

Add a flag to suppress auto-loading for cases where the leader intentionally wants to override the target repo's config:

{
  "inherit_target_config": false
}

Alternative Solutions

### 1. Inlining target repo's configurations into the teammate's prompt

Manually injecting the target repo's configurations references into the prompt field of the Task call so the teammate has the right conventions.

Why it falls short:

• Skills are not available as tools to the teammate — even if you describe them, the teammate can't invoke them via the Skill tool since they're not registered in its session
• Doesn't scale across multiple repos or teammates

### 2. Symlinking or copying .claude/ directories into the leader's directory

Merging target repos' .claude/ directories (skills, etc) into the leader's workspace so everything is loaded in one place.

Why it falls short:

• Skill name collisions — Different repos define skills with the same name but different behavior. For example, a Python/FastAPI repo and a Node/Fastify repo may both define

/adding-endpoint, but they generate completely different boilerplate. When both are loaded into the root, one silently shadows the other.

• Extra manual overhead to set up and maintain the symlinks/copies
• Breaks on repo updates, branch switches, or when new skills are added upstream
• Pollutes the leader's directory with unrelated config from other projects

### 3. Running separate claude sessions per repo instead of using teams

Opening independent Claude Code sessions in each repo so each one natively loads its own .claude/ config, and coordinating the work manually.

Why it falls short:

• Loses all team coordination benefits — shared task list, inter-agent messaging, dependency tracking, and blocking relationships
• The user becomes the manual orchestrator, defeating the purpose of multi-agent automation
• No shared context between sessions

Priority

High - Significant impact on productivity

Feature Category

CLI commands and flags

Use Case Example

One example out of many:

### Coordinated frontend + backend feature development

A team is building a new feature:

• frontend-app (React/Next.js) — has a /add-component skill that scaffolds a component with the project's design system imports, Storybook file, and test file using vitest
• backend-api (Go) — has CLAUDE.md, and a /add-handler skill that scaffolds a handler with the project's middleware chain and OpenAPI spec update

The leader spawns two teammates. The frontend teammate doesn't have /add-component, so it creates a component from scratch — missing the design system tokens, skipping the Storybook
file, and writing tests with Jest instead of vitest.
Same goes for the backend teammate missing /add-handler skill.

With this feature: Each teammate operates as if you opened a fresh claude session in that repo. The frontend teammate uses /add-component and gets the right scaffolding. The backend teammate uses /add-handler and gets the right scaffolding.

Additional Context

_No response_