[FEATURE] Native support for dynamic, composable context injection into subagents and teammates

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

There is no built-in mechanism for composing context from modular pieces and injecting it into subagents or teammates based on role. Currently, the only ways to provide context to subagents are:

• .claude/agents/ definitions: Static. The system prompt is fixed per agent type. No composition — each agent gets one monolithic blob. Cannot vary context at runtime.
• SubagentStart hook with additionalContext: Works as a workaround but requires external shell scripts, manual YAML parsing, and a hand-rolled module composition system.
• The prompt itself: Non-deterministic. Depends on the LLM correctly formatting and including the right context.

For teams working on large codebases, different agents need different slices of project knowledge. A security reviewer needs security guidelines + API conventions. A tester needs test standards + architecture overview. Currently there's no way to express this composition without building it yourself on top of hooks.

Proposed Solution

A first-class context composition system where:

1. Context modules are defined as individual files (static .md or dynamic scripts):

``
.claude/context/modules/
security-guidelines.md
api-conventions.md
test-standards.md
codebase-map.sh # dynamic — runs at inject time
``

1. Roles map to module lists:

```yaml
# .claude/context/roles.yaml
security-reviewer:

• project-architecture
• security-guidelines
• api-conventions

tester:

• project-architecture
• test-standards

```

1. Agent definitions and teammates reference a role, and the context is automatically composed and injected at spawn time — no hooks required.

1. The main session can also have a role for SessionStart context injection.

Alternative Solutions

Current workaround (validated and working):

• SubagentStart hook runs a bash script that reads agent_type, looks it up in a roles.yaml file, composes context from module files, and injects via hookSpecificOutput.additionalContext
• For teammates, the name parameter falls back to become agent_type when no matching agent definition exists, so the name doubles as the role key
• For regular subagents, a thin .claude/agents/<role>.md shim is needed to register the type

This works but is fragile: requires bash scripting, manual YAML parsing without jq, and understanding of undocumented hook behavior.

Priority

Medium - Would be very helpful

Feature Category

Configuration and settings

Use Case Example

1. A team project has 15 context modules covering architecture, API conventions, security, testing, deployment, etc.
2. The team lead defines 5 roles, each composed of 3-5 relevant modules
3. When the team lead spawns a "security-reviewer" teammate, it automatically receives security + API + architecture context
4. When it spawns a "tester", it gets testing + architecture context
5. A "researcher" gets architecture + API context
6. No hook scripts, no shell escaping, no YAML parsing — just declarative configuration
7. Adding a new module or role is a one-line change to the config

Additional Context

Related issue: #24175 (hook inconsistency across spawn modes). Dynamic context injection currently only works for in-process teammates because it depends on SubagentStart firing in the parent process. A native implementation could work across all spawn modes.

The SubagentStart hook's additionalContext field injects content as a <system-reminder> tag in the message stream, not in the system prompt. A native implementation could place composed context more strategically.