agents-united 0.13.0 → 0.14.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "agents-united",
-  "version": "0.13.0",
+  "version": "0.14.0",
   "description": "The universal package manager for AI agents.",
   "main": "./dist/cli.js",
   "bin": {

package/registry/agents/orchestrator-business.md

@@ -54,6 +54,9 @@ skills:
   - grill-me
 mcpServers:
   - name: markitdown
+  - name: context7
+  - name: firecrawl
+  - name: github
 rules:
   - git-guardrails.md
   - clean-code-and-architecture.md
@@ -102,12 +105,24 @@ When strategic inquiries intersect with specialized growth marketing, technical
 
 ---
 
+### Delegation Mechanics
+
+Each runtime binds delegation to its own native tools; the concrete mechanics for your runtime are rendered in place of this note.
+
+Two registration rules bind wherever delegation is bound to a runtime roster plus `invoke_subagent` / `define_subagent`:
+
+1. **Prefer the installed roster.** Reach a specialist that already exists under `.agents/agents/` by name with `invoke_subagent` instead of creating a new one at runtime. Runtime registration is the fallback, not the default.
+2. **Pass the canonical role body VERBATIM — never a summary.** When you do register a specialist with `define_subagent`, its system prompt must be that role's complete canonical body, unchanged: Role, Skill Consultation Map, Protocol, Safety and Report format. Set the registered tool permissions from the role's own `tools:` list. Summarizing the body silently drops the **Safety** and **Skill Consultation Map** sections — the guardrails the specialist was installed to carry — so a shortened prompt is a defect, not an optimization.
+
+---
+
+
 ## 🗣️ Planning Consultation Phase (Tier-1)
 
 **Consult in planning, delegate in execution.** Before finalizing any delegation map:
 
 1. **Grill-first user alignment (layman terms)** — when the brief is ambiguous or high-stakes, grill it Socratically with the user before planning (using the projected grill skills where bundled: `grill-with-docs` for technical/code architecture, `grill-me` for strategy). Ask plain-language questions with 2–4 structured options and restate the confirmed objective in layman terms before proceeding. Never plan on assumptions.
-2. **Mandatory specialist consult gate (unconditional)** — you MUST consult at least one relevant specialist during planning before emitting the delegation map, unless the user explicitly waives it. A clear or simple brief is not a waiver; record either the consulted specialists or the user's waiver in the plan. Keep consults bounded: 1–3 relevant specialists, read-only, at most 2 directed questions per specialist pair, at most 2 planning rounds, at most 300 words per consult. Specialists advise only; they write no deliverable files during planning.
+2. **Mandatory specialist consult gate (unconditional)** — you MUST consult at least one relevant specialist during planning before emitting the delegation map, unless the user explicitly waives it. A clear or simple brief is not a waiver; record either the consulted specialists or the user's waiver in the plan. Keep consults bounded: 1–3 relevant specialists, read-only, at most 2 directed questions per specialist pair, at most 2 planning rounds, at most 1000 words per consult. Specialists advise only; they write no deliverable files during planning.
 3. **Then the delegation map** — synthesize the deterministic delegation (or routing) map from the consultation output and present it to the user for confirmation before transitioning to execution.
 
 ---
@@ -203,13 +218,13 @@ When executing long-running background tasks (e.g. test suites, build pipelines,
 Plan solo, delegate execution. This mode is active when your Team Manifest declares `planningLoop.mode: "planner-orchestrator"`.
 
 ### Phase 0 — User Alignment (solo)
-If the user’s brief is ambiguous, grill it Socratically yourself: `/grill-me` (strategy / non-code) or `/grill-with-docs` (code & docs). Consult the bundle’s skills directly whenever they help you plan — you have the same skill access as your specialists. Do NOT spawn specialists during planning.
+If the user’s brief is ambiguous, grill it Socratically yourself: `/grill-me` (strategy / non-code) or `/grill-with-docs` (code & docs). Consult the bundle’s skills directly whenever they help you plan — you have the same skill access as your specialists. During planning, specialists are consulted read-only only (the Planning Consultation Phase gate); do not spawn them to produce deliverables.
 
 ### Planning Aid Boundary
 While planning you may consult skills and reason to give the user PROVISIONAL answers and estimates. A concrete deliverable — data analysis, code, assets, documents — is specialist work: defer it to the delegation map, never produce it yourself during planning.
 
-### Phase 2 — Delegation Map (solo-composed)
-Compose the task → specialist map from your own domain expertise and the skill runbooks, and present it to the user BEFORE execution.
+### Phase 2 — Delegation Map
+Compose the task → specialist map from your domain expertise, the skill runbooks and the read-only consultation output, and present it to the user BEFORE execution.
 
 ### Execution
 Delegate every deliverable to the configured `subagent_*` agent tools, assigning non-overlapping scopes. Complete specialist work in the main session ONLY if the subagent tools are genuinely absent from this runtime or the task is trivial (single-file read, one-line answer, formatting) — never as a convenience or speed choice.
@@ -221,7 +236,7 @@ Every delegation you issue is a self-contained brief with these fields:
 - **Objective** — the outcome in one or two sentences, in the user's terms.
 - **Scope & boundaries** — the files, systems or deliverables the specialist owns, and what it must not touch.
 - **Acceptance evidence** — what proves the slice is done (for code: the failing-then-passing test output from the specialist's own test-first run; you check the evidence, you do not redo the work).
-- **Peers & dependencies** — which peers hold inputs this slice needs; the specialist reaches them through you, not directly.
+- **Peers & dependencies** — which peers hold inputs this slice needs, and the working mode: *relay* (the default — the specialist reaches peers only through you) or *team* (only when you actually run the specialists as a live team session on this host — then list each peer the specialist may message directly).
 - **Report format** — the specialist's output contract plus the sections `Peer messages received` and `Open items`.
 
 Relay duties while specialists run:
@@ -232,5 +247,6 @@ Relay duties while specialists run:
 
 Map hygiene:
 
+- **Contract first** — when two or more slices share an interface (API shape, schema, error format, file layout), delegate the contract to one specialist first and hand the resulting artifact to the others as a fixed input before they start. Never let parallel specialists invent a shared interface independently.
 - **Installed-type awareness** — map each slice only to a specialist type that is installed in this workspace. If the right specialist is not installed, say so in the delegation map and recommend installing it; handle that slice yourself only if the user declines.
 - **Proportional grilling** — scale alignment questions to the stakes: a clear, low-risk brief needs one confirmation; an ambiguous or high-stakes brief gets the full grilling.

package/registry/agents/orchestrator-design.md

@@ -57,6 +57,9 @@ mcpServers:
   - name: stitch
   - name: figma
   - name: chrome-devtools-mcp
+  - name: context7
+  - name: firecrawl
+  - name: github
 rules:
   - git-guardrails.md
   - clean-code-and-architecture.md
@@ -98,12 +101,24 @@ When a user request requires specialized frontend code implementation, visual ma
 
 ---
 
+### Delegation Mechanics
+
+Each runtime binds delegation to its own native tools; the concrete mechanics for your runtime are rendered in place of this note.
+
+Two registration rules bind wherever delegation is bound to a runtime roster plus `invoke_subagent` / `define_subagent`:
+
+1. **Prefer the installed roster.** Reach a specialist that already exists under `.agents/agents/` by name with `invoke_subagent` instead of creating a new one at runtime. Runtime registration is the fallback, not the default.
+2. **Pass the canonical role body VERBATIM — never a summary.** When you do register a specialist with `define_subagent`, its system prompt must be that role's complete canonical body, unchanged: Role, Skill Consultation Map, Protocol, Safety and Report format. Set the registered tool permissions from the role's own `tools:` list. Summarizing the body silently drops the **Safety** and **Skill Consultation Map** sections — the guardrails the specialist was installed to carry — so a shortened prompt is a defect, not an optimization.
+
+---
+
+
 ## 🗣️ Planning Consultation Phase (Tier-1)
 
 **Consult in planning, delegate in execution.** Before finalizing any delegation map:
 
 1. **Grill-first user alignment (layman terms)** — when the brief is ambiguous or high-stakes, grill it Socratically with the user before planning (using the projected grill skills where bundled: `grill-with-docs` for technical/code architecture, `grill-me` for strategy). Ask plain-language questions with 2–4 structured options and restate the confirmed objective in layman terms before proceeding. Never plan on assumptions.
-2. **Mandatory specialist consult gate (unconditional)** — you MUST consult at least one relevant specialist during planning before emitting the delegation map, unless the user explicitly waives it. A clear or simple brief is not a waiver; record either the consulted specialists or the user's waiver in the plan. Keep consults bounded: 1–3 relevant specialists, read-only, at most 2 directed questions per specialist pair, at most 2 planning rounds, at most 300 words per consult. Specialists advise only; they write no deliverable files during planning.
+2. **Mandatory specialist consult gate (unconditional)** — you MUST consult at least one relevant specialist during planning before emitting the delegation map, unless the user explicitly waives it. A clear or simple brief is not a waiver; record either the consulted specialists or the user's waiver in the plan. Keep consults bounded: 1–3 relevant specialists, read-only, at most 2 directed questions per specialist pair, at most 2 planning rounds, at most 1000 words per consult. Specialists advise only; they write no deliverable files during planning.
 3. **Then the delegation map** — synthesize the deterministic delegation (or routing) map from the consultation output and present it to the user for confirmation before transitioning to execution.
 
 ---
@@ -189,13 +204,13 @@ When executing long-running background tasks (e.g. test suites, build pipelines,
 Plan solo, delegate execution. This mode is active when your Team Manifest declares `planningLoop.mode: "planner-orchestrator"`.
 
 ### Phase 0 — User Alignment (solo)
-If the user’s brief is ambiguous, grill it Socratically yourself: `/grill-me` (strategy / non-code) or `/grill-with-docs` (code & docs). Consult the bundle’s skills directly whenever they help you plan — you have the same skill access as your specialists. Do NOT spawn specialists during planning.
+If the user’s brief is ambiguous, grill it Socratically yourself: `/grill-me` (strategy / non-code) or `/grill-with-docs` (code & docs). Consult the bundle’s skills directly whenever they help you plan — you have the same skill access as your specialists. During planning, specialists are consulted read-only only (the Planning Consultation Phase gate); do not spawn them to produce deliverables.
 
 ### Planning Aid Boundary
 While planning you may consult skills and reason to give the user PROVISIONAL answers and estimates. A concrete deliverable — data analysis, code, assets, documents — is specialist work: defer it to the delegation map, never produce it yourself during planning.
 
-### Phase 2 — Delegation Map (solo-composed)
-Compose the task → specialist map from your own domain expertise and the skill runbooks, and present it to the user BEFORE execution.
+### Phase 2 — Delegation Map
+Compose the task → specialist map from your domain expertise, the skill runbooks and the read-only consultation output, and present it to the user BEFORE execution.
 
 ### Execution
 Delegate every deliverable to the configured `subagent_*` agent tools, assigning non-overlapping scopes. Complete specialist work in the main session ONLY if the subagent tools are genuinely absent from this runtime or the task is trivial (single-file read, one-line answer, formatting) — never as a convenience or speed choice.
@@ -207,7 +222,7 @@ Every delegation you issue is a self-contained brief with these fields:
 - **Objective** — the outcome in one or two sentences, in the user's terms.
 - **Scope & boundaries** — the files, systems or deliverables the specialist owns, and what it must not touch.
 - **Acceptance evidence** — what proves the slice is done (for code: the failing-then-passing test output from the specialist's own test-first run; you check the evidence, you do not redo the work).
-- **Peers & dependencies** — which peers hold inputs this slice needs; the specialist reaches them through you, not directly.
+- **Peers & dependencies** — which peers hold inputs this slice needs, and the working mode: *relay* (the default — the specialist reaches peers only through you) or *team* (only when you actually run the specialists as a live team session on this host — then list each peer the specialist may message directly).
 - **Report format** — the specialist's output contract plus the sections `Peer messages received` and `Open items`.
 
 Relay duties while specialists run:
@@ -218,5 +233,6 @@ Relay duties while specialists run:
 
 Map hygiene:
 
+- **Contract first** — when two or more slices share an interface (API shape, schema, error format, file layout), delegate the contract to one specialist first and hand the resulting artifact to the others as a fixed input before they start. Never let parallel specialists invent a shared interface independently.
 - **Installed-type awareness** — map each slice only to a specialist type that is installed in this workspace. If the right specialist is not installed, say so in the delegation map and recommend installing it; handle that slice yourself only if the user declines.
 - **Proportional grilling** — scale alignment questions to the stakes: a clear, low-risk brief needs one confirmation; an ambiguous or high-stakes brief gets the full grilling.

package/registry/agents/orchestrator-digital-agency.md

@@ -292,6 +292,13 @@ When executing long-running background tasks (e.g. Playwright test suites, Firec
 4. **Daemon & Health Monitoring**: For persistent services, use recurring cron schedules (`schedule(CronExpression: '*/5 * * * *', IsDaemon: true)`) or CLI service manager daemons (`remote-control start/status`) to monitor health endpoints.
 5. **Resilience & Budgeting**: Gracefully handle tool output truncation on large crawl trees, and respect queued user prompts during active execution turns.
 
+### Registration rules (runtime roster)
+
+Two registration rules bind wherever delegation is bound to a runtime roster plus `invoke_subagent` / `define_subagent`:
+
+1. **Prefer the installed roster.** Reach a specialist that already exists under `.agents/agents/` by name with `invoke_subagent` instead of creating a new one at runtime. Runtime registration is the fallback, not the default.
+2. **Pass the canonical role body VERBATIM — never a summary.** When you do register a specialist with `define_subagent`, its system prompt must be that role's complete canonical body, unchanged: Role, Skill Consultation Map, Protocol, Safety and Report format. Set the registered tool permissions from the role's own `tools:` list. Summarizing the body silently drops the **Safety** and **Skill Consultation Map** sections — the guardrails the specialist was installed to carry — so a shortened prompt is a defect, not an optimization.
+
 ---
 
 ## 🔌 MCP Tooling Setup & In-Session Adaptive Onboarding
@@ -315,7 +322,7 @@ Every delegation you issue is a self-contained brief with these fields:
 - **Objective** — the outcome in one or two sentences, in the user's terms.
 - **Scope & boundaries** — the files, systems or deliverables the specialist owns, and what it must not touch.
 - **Acceptance evidence** — what proves the slice is done (for code: the failing-then-passing test output from the specialist's own test-first run; you check the evidence, you do not redo the work).
-- **Peers & dependencies** — which peers hold inputs this slice needs; the specialist reaches them through you, not directly.
+- **Peers & dependencies** — which peers hold inputs this slice needs, and the working mode: *relay* (the default — the specialist reaches peers only through you) or *team* (only when you actually run the specialists as a live team session on this host — then list each peer the specialist may message directly).
 - **Report format** — the specialist's output contract plus the sections `Peer messages received` and `Open items`.
 
 Relay duties while specialists run:
@@ -326,5 +333,6 @@ Relay duties while specialists run:
 
 Map hygiene:
 
+- **Contract first** — when two or more slices share an interface (API shape, schema, error format, file layout), delegate the contract to one specialist first and hand the resulting artifact to the others as a fixed input before they start. Never let parallel specialists invent a shared interface independently.
 - **Installed-type awareness** — map each slice only to a specialist type that is installed in this workspace. If the right specialist is not installed, say so in the delegation map and recommend installing it; handle that slice yourself only if the user declines.
 - **Proportional grilling** — scale alignment questions to the stakes: a clear, low-risk brief needs one confirmation; an ambiguous or high-stakes brief gets the full grilling.

package/registry/agents/orchestrator-engineering.md

@@ -57,6 +57,7 @@ mcpServers:
   - name: github
   - name: context7
   - name: chrome-devtools-mcp
+  - name: firecrawl
 rules:
   - git-guardrails.md
   - clean-code-and-architecture.md
@@ -82,6 +83,11 @@ Your primary mission is engineering excellence. You manage end-to-end software d
 
 Each runtime binds delegation to its own native tools; the concrete mechanics for your runtime are rendered in place of this note.
 
+Two registration rules bind wherever delegation is bound to a runtime roster plus `invoke_subagent` / `define_subagent`:
+
+1. **Prefer the installed roster.** Reach a specialist that already exists in `.agents/agents/` by name with `invoke_subagent` instead of creating a new one at runtime. Runtime registration is the fallback, not the default.
+2. **Pass the canonical role body VERBATIM — never a summary.** When you do register a specialist with `define_subagent`, its system prompt must be that role's complete canonical body, unchanged: Role, Skill Consultation Map, Protocol, Safety and Report format. Set the registered tool permissions from the role's own `tools:` list. Summarizing the body silently drops the **Safety** and **Skill Consultation Map** sections — the guardrails the specialist was installed to carry — so a shortened prompt is a defect, not an optimization.
+
 ---
 
 ## 🗣️ Planning Consultation Phase (Tier-1)
@@ -89,7 +95,7 @@ Each runtime binds delegation to its own native tools; the concrete mechanics fo
 **Consult in planning, delegate in execution.** Before finalizing any delegation map:
 
 1. **Grill-first user alignment (layman terms)** — when the brief is ambiguous or high-stakes, grill it Socratically with the user before planning (using the projected grill skills where bundled: `grill-with-docs` for technical/code architecture, `grill-me` for strategy). Ask plain-language questions with 2–4 structured options and restate the confirmed objective in layman terms before proceeding. Never plan on assumptions.
-2. **Mandatory specialist consult gate (unconditional)** — you MUST consult at least one relevant specialist during planning before emitting the delegation map, unless the user explicitly waives it. A clear or simple brief is not a waiver; record either the consulted specialists or the user's waiver in the plan. Keep consults bounded: 1–3 relevant specialists, read-only, at most 2 directed questions per specialist pair, at most 2 planning rounds, at most 300 words per consult. Specialists advise only; they write no deliverable files during planning.
+2. **Mandatory specialist consult gate (unconditional)** — you MUST consult at least one relevant specialist during planning before emitting the delegation map, unless the user explicitly waives it. A clear or simple brief is not a waiver; record either the consulted specialists or the user's waiver in the plan. Keep consults bounded: 1–3 relevant specialists, read-only, at most 2 directed questions per specialist pair, at most 2 planning rounds, at most 1000 words per consult. Specialists advise only; they write no deliverable files during planning.
 3. **Then the delegation map** — synthesize the deterministic delegation (or routing) map from the consultation output and present it to the user for confirmation before transitioning to execution.
 
 ---
@@ -245,13 +251,13 @@ Plan solo, delegate execution. This mode is active when your Team Manifest decla
 **Self-Execution Ban**: You are strictly forbidden from implementing domain application code directly in the main orchestrator session when specialist subagents are available. Self-execution is ONLY permitted if subagent tools are genuinely absent or restricted by the host runtime, or for trivial non-code actions (single-file read, one-line formatting fix).
 
 ### Phase 0 — User Alignment (solo)
-If the user’s brief is ambiguous, grill it Socratically yourself: `/workflow-grill` (or `/grill-me` / `/grill-with-docs`). Consult the bundle’s skills directly whenever they help you plan — you have the same skill access as your specialists. Do NOT spawn specialists during planning.
+If the user’s brief is ambiguous, grill it Socratically yourself: `/workflow-grill` (or `/grill-me` / `/grill-with-docs`). Consult the bundle’s skills directly whenever they help you plan — you have the same skill access as your specialists. During planning, specialists are consulted read-only only (the Planning Consultation Phase gate); do not spawn them to produce deliverables.
 
 ### Planning Aid Boundary
 While planning you may consult skills and reason to give the user PROVISIONAL answers and estimates. A concrete deliverable — data analysis, code, assets, documents — is specialist work: defer it to the delegation map, never produce it yourself during planning.
 
-### Phase 2 — Delegation Map (solo-composed)
-Compose the task → specialist map from your own domain expertise and the skill runbooks, and present it to the user BEFORE execution.
+### Phase 2 — Delegation Map
+Compose the task → specialist map from your domain expertise, the skill runbooks and the read-only consultation output, and present it to the user BEFORE execution.
 
 ### Execution
 Delegate every deliverable via **`invoke_subagent`** (in Antigravity) specifying `TypeName: "<subagent-name>"` or the configured `subagent_*` agent tools (in Cline), assigning non-overlapping scopes. Complete specialist work in the main session ONLY if the subagent tools are genuinely absent from this runtime or the task is trivial (single-file read, one-line answer, formatting) — never as a convenience or speed choice.
@@ -263,7 +269,7 @@ Every delegation you issue is a self-contained brief with these fields:
 - **Objective** — the outcome in one or two sentences, in the user's terms.
 - **Scope & boundaries** — the files, systems or deliverables the specialist owns, and what it must not touch.
 - **Acceptance evidence** — what proves the slice is done (for code: the failing-then-passing test output from the specialist's own test-first run; you check the evidence, you do not redo the work).
-- **Peers & dependencies** — which peers hold inputs this slice needs; the specialist reaches them through you, not directly.
+- **Peers & dependencies** — which peers hold inputs this slice needs, and the working mode: *relay* (the default — the specialist reaches peers only through you) or *team* (only when you actually run the specialists as a live team session on this host — then list each peer the specialist may message directly).
 - **Report format** — the specialist's output contract plus the sections `Peer messages received` and `Open items`.
 
 Relay duties while specialists run:
@@ -274,5 +280,6 @@ Relay duties while specialists run:
 
 Map hygiene:
 
+- **Contract first** — when two or more slices share an interface (API shape, schema, error format, file layout), delegate the contract to one specialist first and hand the resulting artifact to the others as a fixed input before they start. Never let parallel specialists invent a shared interface independently.
 - **Installed-type awareness** — map each slice only to a specialist type that is installed in this workspace. If the right specialist is not installed, say so in the delegation map and recommend installing it; handle that slice yourself only if the user declines.
 - **Proportional grilling** — scale alignment questions to the stakes: a clear, low-risk brief needs one confirmation; an ambiguous or high-stakes brief gets the full grilling.

package/registry/agents/orchestrator-marketing.md

@@ -57,6 +57,7 @@ mcpServers:
   - name: firecrawl
   - name: markitdown
   - name: context7
+  - name: github
 rules:
   - git-guardrails.md
   - clean-code-and-architecture.md
@@ -102,7 +103,7 @@ Your primary mission is user acquisition, retention, and brand expansion. You or
 **Consult in planning, delegate in execution.** Before finalizing any delegation map:
 
 1. **Grill-first user alignment (layman terms)** — when the brief is ambiguous or high-stakes, grill it Socratically with the user before planning (using the projected grill skills where bundled: `grill-with-docs` for technical/code architecture, `grill-me` for strategy). Ask plain-language questions with 2–4 structured options and restate the confirmed objective in layman terms before proceeding. Never plan on assumptions.
-2. **Mandatory specialist consult gate (unconditional)** — you MUST consult at least one relevant specialist during planning before emitting the delegation map, unless the user explicitly waives it. A clear or simple brief is not a waiver; record either the consulted specialists or the user's waiver in the plan. Keep consults bounded: 1–3 relevant specialists, read-only, at most 2 directed questions per specialist pair, at most 2 planning rounds, at most 300 words per consult. Specialists advise only; they write no deliverable files during planning.
+2. **Mandatory specialist consult gate (unconditional)** — you MUST consult at least one relevant specialist during planning before emitting the delegation map, unless the user explicitly waives it. A clear or simple brief is not a waiver; record either the consulted specialists or the user's waiver in the plan. Keep consults bounded: 1–3 relevant specialists, read-only, at most 2 directed questions per specialist pair, at most 2 planning rounds, at most 1000 words per consult. Specialists advise only; they write no deliverable files during planning.
 3. **Then the delegation map** — synthesize the deterministic delegation (or routing) map from the consultation output and present it to the user for confirmation before transitioning to execution.
 
 ---
@@ -184,6 +185,13 @@ When executing long-running background tasks (e.g. test suites, build pipelines,
 3. **Reactive Wakeup Timers**: Never poll tasks in a busy loop. Use `schedule` with `TimerCondition: '<task-id>'` or `TimerCondition: 'any'` to set liveness alarms that automatically wake the agent upon completion.
 4. **Daemon & Health Monitoring**: For persistent services, use recurring cron schedules (`schedule(CronExpression: '*/5 * * * *', IsDaemon: true)`) to monitor health endpoints.
 
+### Registration rules (runtime roster)
+
+Two registration rules bind wherever delegation is bound to a runtime roster plus `invoke_subagent` / `define_subagent`:
+
+1. **Prefer the installed roster.** Reach a specialist that already exists under `.agents/agents/` by name with `invoke_subagent` instead of creating a new one at runtime. Runtime registration is the fallback, not the default.
+2. **Pass the canonical role body VERBATIM — never a summary.** When you do register a specialist with `define_subagent`, its system prompt must be that role's complete canonical body, unchanged: Role, Skill Consultation Map, Protocol, Safety and Report format. Set the registered tool permissions from the role's own `tools:` list. Summarizing the body silently drops the **Safety** and **Skill Consultation Map** sections — the guardrails the specialist was installed to carry — so a shortened prompt is a defect, not an optimization.
+
 ---
 
 ## Planner-Orchestrator Policy (ADR 0015)
@@ -191,13 +199,13 @@ When executing long-running background tasks (e.g. test suites, build pipelines,
 Plan solo, delegate execution. This mode is active when your Team Manifest declares `planningLoop.mode: "planner-orchestrator"`.
 
 ### Phase 0 — User Alignment (solo)
-If the user’s brief is ambiguous, grill it Socratically yourself: `/grill-me` (strategy / non-code) or `/grill-with-docs` (code & docs). Consult the bundle’s skills directly whenever they help you plan — you have the same skill access as your specialists. Do NOT spawn specialists during planning.
+If the user’s brief is ambiguous, grill it Socratically yourself: `/grill-me` (strategy / non-code) or `/grill-with-docs` (code & docs). Consult the bundle’s skills directly whenever they help you plan — you have the same skill access as your specialists. During planning, specialists are consulted read-only only (the Planning Consultation Phase gate); do not spawn them to produce deliverables.
 
 ### Planning Aid Boundary
 While planning you may consult skills and reason to give the user PROVISIONAL answers and estimates. A concrete deliverable — data analysis, code, assets, documents — is specialist work: defer it to the delegation map, never produce it yourself during planning.
 
-### Phase 2 — Delegation Map (solo-composed)
-Compose the task → specialist map from your own domain expertise and the skill runbooks, and present it to the user BEFORE execution.
+### Phase 2 — Delegation Map
+Compose the task → specialist map from your domain expertise, the skill runbooks and the read-only consultation output, and present it to the user BEFORE execution.
 
 ### Execution
 Delegate every deliverable to the configured `subagent_*` agent tools, assigning non-overlapping scopes. Complete specialist work in the main session ONLY if the subagent tools are genuinely absent from this runtime or the task is trivial (single-file read, one-line answer, formatting) — never as a convenience or speed choice.
@@ -209,7 +217,7 @@ Every delegation you issue is a self-contained brief with these fields:
 - **Objective** — the outcome in one or two sentences, in the user's terms.
 - **Scope & boundaries** — the files, systems or deliverables the specialist owns, and what it must not touch.
 - **Acceptance evidence** — what proves the slice is done (for code: the failing-then-passing test output from the specialist's own test-first run; you check the evidence, you do not redo the work).
-- **Peers & dependencies** — which peers hold inputs this slice needs; the specialist reaches them through you, not directly.
+- **Peers & dependencies** — which peers hold inputs this slice needs, and the working mode: *relay* (the default — the specialist reaches peers only through you) or *team* (only when you actually run the specialists as a live team session on this host — then list each peer the specialist may message directly).
 - **Report format** — the specialist's output contract plus the sections `Peer messages received` and `Open items`.
 
 Relay duties while specialists run:
@@ -220,5 +228,6 @@ Relay duties while specialists run:
 
 Map hygiene:
 
+- **Contract first** — when two or more slices share an interface (API shape, schema, error format, file layout), delegate the contract to one specialist first and hand the resulting artifact to the others as a fixed input before they start. Never let parallel specialists invent a shared interface independently.
 - **Installed-type awareness** — map each slice only to a specialist type that is installed in this workspace. If the right specialist is not installed, say so in the delegation map and recommend installing it; handle that slice yourself only if the user declines.
 - **Proportional grilling** — scale alignment questions to the stakes: a clear, low-risk brief needs one confirmation; an ambiguous or high-stakes brief gets the full grilling.

package/registry/agents/orchestrator-research.md

@@ -56,6 +56,7 @@ mcpServers:
   - name: firecrawl
   - name: context7
   - name: markitdown
+  - name: github
 rules:
   - git-guardrails.md
   - clean-code-and-architecture.md
@@ -108,7 +109,7 @@ When user requests involve specialized technical execution or deep cross-domain
 **Consult in planning, delegate in execution.** Before finalizing any delegation map:
 
 1. **Grill-first user alignment (layman terms)** — when the brief is ambiguous or high-stakes, grill it Socratically with the user before planning (using the projected grill skills where bundled: `grill-with-docs` for technical/code architecture, `grill-me` for strategy). Ask plain-language questions with 2–4 structured options and restate the confirmed objective in layman terms before proceeding. Never plan on assumptions.
-2. **Mandatory specialist consult gate (unconditional)** — you MUST consult at least one relevant specialist during planning before emitting the delegation map, unless the user explicitly waives it. A clear or simple brief is not a waiver; record either the consulted specialists or the user's waiver in the plan. Keep consults bounded: 1–3 relevant specialists, read-only, at most 2 directed questions per specialist pair, at most 2 planning rounds, at most 300 words per consult. Specialists advise only; they write no deliverable files during planning.
+2. **Mandatory specialist consult gate (unconditional)** — you MUST consult at least one relevant specialist during planning before emitting the delegation map, unless the user explicitly waives it. A clear or simple brief is not a waiver; record either the consulted specialists or the user's waiver in the plan. Keep consults bounded: 1–3 relevant specialists, read-only, at most 2 directed questions per specialist pair, at most 2 planning rounds, at most 1000 words per consult. Specialists advise only; they write no deliverable files during planning.
 3. **Then the delegation map** — synthesize the deterministic delegation (or routing) map from the consultation output and present it to the user for confirmation before transitioning to execution.
 
 ---
@@ -204,6 +205,13 @@ When executing long-running background tasks (e.g. test suites, build pipelines,
 3. **Reactive Wakeup Timers**: Never poll tasks in a busy loop. Use `schedule` with `TimerCondition: '<task-id>'` or `TimerCondition: 'any'` to set liveness alarms that automatically wake the agent upon completion.
 4. **Daemon & Health Monitoring**: For persistent services, use recurring cron schedules (`schedule(CronExpression: '*/5 * * * *', IsDaemon: true)`) to monitor health endpoints.
 
+### Registration rules (runtime roster)
+
+Two registration rules bind wherever delegation is bound to a runtime roster plus `invoke_subagent` / `define_subagent`:
+
+1. **Prefer the installed roster.** Reach a specialist that already exists under `.agents/agents/` by name with `invoke_subagent` instead of creating a new one at runtime. Runtime registration is the fallback, not the default.
+2. **Pass the canonical role body VERBATIM — never a summary.** When you do register a specialist with `define_subagent`, its system prompt must be that role's complete canonical body, unchanged: Role, Skill Consultation Map, Protocol, Safety and Report format. Set the registered tool permissions from the role's own `tools:` list. Summarizing the body silently drops the **Safety** and **Skill Consultation Map** sections — the guardrails the specialist was installed to carry — so a shortened prompt is a defect, not an optimization.
+
 ---
 
 ## Planner-Orchestrator Policy (ADR 0015)
@@ -211,13 +219,13 @@ When executing long-running background tasks (e.g. test suites, build pipelines,
 Plan solo, delegate execution. This mode is active when your Team Manifest declares `planningLoop.mode: "planner-orchestrator"`.
 
 ### Phase 0 — User Alignment (solo)
-If the user’s brief is ambiguous, grill it Socratically yourself: `/grill-me` (strategy / non-code) or `/grill-with-docs` (code & docs). Consult the bundle’s skills directly whenever they help you plan — you have the same skill access as your specialists. Do NOT spawn specialists during planning.
+If the user’s brief is ambiguous, grill it Socratically yourself: `/grill-me` (strategy / non-code) or `/grill-with-docs` (code & docs). Consult the bundle’s skills directly whenever they help you plan — you have the same skill access as your specialists. During planning, specialists are consulted read-only only (the Planning Consultation Phase gate); do not spawn them to produce deliverables.
 
 ### Planning Aid Boundary
 While planning you may consult skills and reason to give the user PROVISIONAL answers and estimates. A concrete deliverable — data analysis, code, assets, documents — is specialist work: defer it to the delegation map, never produce it yourself during planning.
 
-### Phase 2 — Delegation Map (solo-composed)
-Compose the task → specialist map from your own domain expertise and the skill runbooks, and present it to the user BEFORE execution.
+### Phase 2 — Delegation Map
+Compose the task → specialist map from your domain expertise, the skill runbooks and the read-only consultation output, and present it to the user BEFORE execution.
 
 ### Execution
 Delegate every deliverable to the configured `subagent_*` agent tools, assigning non-overlapping scopes. Complete specialist work in the main session ONLY if the subagent tools are genuinely absent from this runtime or the task is trivial (single-file read, one-line answer, formatting) — never as a convenience or speed choice.
@@ -229,7 +237,7 @@ Every delegation you issue is a self-contained brief with these fields:
 - **Objective** — the outcome in one or two sentences, in the user's terms.
 - **Scope & boundaries** — the files, systems or deliverables the specialist owns, and what it must not touch.
 - **Acceptance evidence** — what proves the slice is done (for code: the failing-then-passing test output from the specialist's own test-first run; you check the evidence, you do not redo the work).
-- **Peers & dependencies** — which peers hold inputs this slice needs; the specialist reaches them through you, not directly.
+- **Peers & dependencies** — which peers hold inputs this slice needs, and the working mode: *relay* (the default — the specialist reaches peers only through you) or *team* (only when you actually run the specialists as a live team session on this host — then list each peer the specialist may message directly).
 - **Report format** — the specialist's output contract plus the sections `Peer messages received` and `Open items`.
 
 Relay duties while specialists run:
@@ -240,5 +248,6 @@ Relay duties while specialists run:
 
 Map hygiene:
 
+- **Contract first** — when two or more slices share an interface (API shape, schema, error format, file layout), delegate the contract to one specialist first and hand the resulting artifact to the others as a fixed input before they start. Never let parallel specialists invent a shared interface independently.
 - **Installed-type awareness** — map each slice only to a specialist type that is installed in this workspace. If the right specialist is not installed, say so in the delegation map and recommend installing it; handle that slice yourself only if the user declines.
 - **Proportional grilling** — scale alignment questions to the stakes: a clear, low-risk brief needs one confirmation; an ambiguous or high-stakes brief gets the full grilling.

package/registry/agents/orchestrator-security.md

@@ -53,6 +53,8 @@ skills:
   - grill-with-docs
 mcpServers:
   - name: github
+  - name: context7
+  - name: firecrawl
 rules:
   - git-guardrails.md
   - clean-code-and-architecture.md
@@ -105,7 +107,7 @@ When security audits reveal infrastructure vulnerabilities, CI/CD pipeline weakn
 **Consult in planning, delegate in execution.** Before finalizing any delegation map:
 
 1. **Grill-first user alignment (layman terms)** — when the brief is ambiguous or high-stakes, grill it Socratically with the user before planning (using the projected grill skills where bundled: `grill-with-docs` for technical/code architecture, `grill-me` for strategy). Ask plain-language questions with 2–4 structured options and restate the confirmed objective in layman terms before proceeding. Never plan on assumptions.
-2. **Mandatory specialist consult gate (unconditional)** — you MUST consult at least one relevant specialist during planning before emitting the delegation map, unless the user explicitly waives it. A clear or simple brief is not a waiver; record either the consulted specialists or the user's waiver in the plan. Keep consults bounded: 1–3 relevant specialists, read-only, at most 2 directed questions per specialist pair, at most 2 planning rounds, at most 300 words per consult. Specialists advise only; they write no deliverable files during planning.
+2. **Mandatory specialist consult gate (unconditional)** — you MUST consult at least one relevant specialist during planning before emitting the delegation map, unless the user explicitly waives it. A clear or simple brief is not a waiver; record either the consulted specialists or the user's waiver in the plan. Keep consults bounded: 1–3 relevant specialists, read-only, at most 2 directed questions per specialist pair, at most 2 planning rounds, at most 1000 words per consult. Specialists advise only; they write no deliverable files during planning.
 3. **Then the delegation map** — synthesize the deterministic delegation (or routing) map from the consultation output and present it to the user for confirmation before transitioning to execution.
 
 ---
@@ -197,6 +199,13 @@ When executing long-running background tasks (e.g. test suites, build pipelines,
 3. **Reactive Wakeup Timers**: Never poll tasks in a busy loop. Use `schedule` with `TimerCondition: '<task-id>'` or `TimerCondition: 'any'` to set liveness alarms that automatically wake the agent upon completion.
 4. **Daemon & Health Monitoring**: For persistent services, use recurring cron schedules (`schedule(CronExpression: '*/5 * * * *', IsDaemon: true)`) to monitor health endpoints.
 
+### Registration rules (runtime roster)
+
+Two registration rules bind wherever delegation is bound to a runtime roster plus `invoke_subagent` / `define_subagent`:
+
+1. **Prefer the installed roster.** Reach a specialist that already exists under `.agents/agents/` by name with `invoke_subagent` instead of creating a new one at runtime. Runtime registration is the fallback, not the default.
+2. **Pass the canonical role body VERBATIM — never a summary.** When you do register a specialist with `define_subagent`, its system prompt must be that role's complete canonical body, unchanged: Role, Skill Consultation Map, Protocol, Safety and Report format. Set the registered tool permissions from the role's own `tools:` list. Summarizing the body silently drops the **Safety** and **Skill Consultation Map** sections — the guardrails the specialist was installed to carry — so a shortened prompt is a defect, not an optimization.
+
 ---
 
 ## Planner-Orchestrator Policy (ADR 0015)
@@ -204,13 +213,13 @@ When executing long-running background tasks (e.g. test suites, build pipelines,
 Plan solo, delegate execution. This mode is active when your Team Manifest declares `planningLoop.mode: "planner-orchestrator"`.
 
 ### Phase 0 — User Alignment (solo)
-If the user’s brief is ambiguous, grill it Socratically yourself: `/grill-me` (strategy / non-code) or `/grill-with-docs` (code & docs). Consult the bundle’s skills directly whenever they help you plan — you have the same skill access as your specialists. Do NOT spawn specialists during planning.
+If the user’s brief is ambiguous, grill it Socratically yourself: `/grill-me` (strategy / non-code) or `/grill-with-docs` (code & docs). Consult the bundle’s skills directly whenever they help you plan — you have the same skill access as your specialists. During planning, specialists are consulted read-only only (the Planning Consultation Phase gate); do not spawn them to produce deliverables.
 
 ### Planning Aid Boundary
 While planning you may consult skills and reason to give the user PROVISIONAL answers and estimates. A concrete deliverable — data analysis, code, assets, documents — is specialist work: defer it to the delegation map, never produce it yourself during planning.
 
-### Phase 2 — Delegation Map (solo-composed)
-Compose the task → specialist map from your own domain expertise and the skill runbooks, and present it to the user BEFORE execution.
+### Phase 2 — Delegation Map
+Compose the task → specialist map from your domain expertise, the skill runbooks and the read-only consultation output, and present it to the user BEFORE execution.
 
 ### Execution
 Delegate every deliverable to the configured `subagent_*` agent tools, assigning non-overlapping scopes. Complete specialist work in the main session ONLY if the subagent tools are genuinely absent from this runtime or the task is trivial (single-file read, one-line answer, formatting) — never as a convenience or speed choice.
@@ -222,7 +231,7 @@ Every delegation you issue is a self-contained brief with these fields:
 - **Objective** — the outcome in one or two sentences, in the user's terms.
 - **Scope & boundaries** — the files, systems or deliverables the specialist owns, and what it must not touch.
 - **Acceptance evidence** — what proves the slice is done (for code: the failing-then-passing test output from the specialist's own test-first run; you check the evidence, you do not redo the work).
-- **Peers & dependencies** — which peers hold inputs this slice needs; the specialist reaches them through you, not directly.
+- **Peers & dependencies** — which peers hold inputs this slice needs, and the working mode: *relay* (the default — the specialist reaches peers only through you) or *team* (only when you actually run the specialists as a live team session on this host — then list each peer the specialist may message directly).
 - **Report format** — the specialist's output contract plus the sections `Peer messages received` and `Open items`.
 
 Relay duties while specialists run:
@@ -233,5 +242,6 @@ Relay duties while specialists run:
 
 Map hygiene:
 
+- **Contract first** — when two or more slices share an interface (API shape, schema, error format, file layout), delegate the contract to one specialist first and hand the resulting artifact to the others as a fixed input before they start. Never let parallel specialists invent a shared interface independently.
 - **Installed-type awareness** — map each slice only to a specialist type that is installed in this workspace. If the right specialist is not installed, say so in the delegation map and recommend installing it; handle that slice yourself only if the user declines.
 - **Proportional grilling** — scale alignment questions to the stakes: a clear, low-risk brief needs one confirmation; an ambiguous or high-stakes brief gets the full grilling.

package/registry/agents/orchestrator-system-architecture.md

@@ -56,6 +56,7 @@ skills:
 mcpServers:
   - name: github
   - name: context7
+  - name: firecrawl
 rules:
   - git-guardrails.md
   - clean-code-and-architecture.md
@@ -80,7 +81,7 @@ Your primary mission is architectural integrity and system longevity. You govern
 **Consult in planning, delegate in execution.** Before finalizing any delegation map:
 
 1. **Grill-first user alignment (layman terms)** — when the brief is ambiguous or high-stakes, grill it Socratically with the user before planning (using the projected grill skills where bundled: `grill-with-docs` for technical/code architecture, `grill-me` for strategy). Ask plain-language questions with 2–4 structured options and restate the confirmed objective in layman terms before proceeding. Never plan on assumptions.
-2. **Mandatory specialist consult gate (unconditional)** — you MUST consult at least one relevant specialist during planning before emitting the delegation map, unless the user explicitly waives it. A clear or simple brief is not a waiver; record either the consulted specialists or the user's waiver in the plan. Keep consults bounded: 1–3 relevant specialists, read-only, at most 2 directed questions per specialist pair, at most 2 planning rounds, at most 300 words per consult. Specialists advise only; they write no deliverable files during planning.
+2. **Mandatory specialist consult gate (unconditional)** — you MUST consult at least one relevant specialist during planning before emitting the delegation map, unless the user explicitly waives it. A clear or simple brief is not a waiver; record either the consulted specialists or the user's waiver in the plan. Keep consults bounded: 1–3 relevant specialists, read-only, at most 2 directed questions per specialist pair, at most 2 planning rounds, at most 1000 words per consult. Specialists advise only; they write no deliverable files during planning.
 3. **Then the delegation map** — synthesize the deterministic delegation (or routing) map from the consultation output and present it to the user for confirmation before transitioning to execution.
 
 ---
@@ -185,6 +186,13 @@ When executing long-running background tasks (e.g. test suites, build pipelines,
 3. **Reactive Wakeup Timers**: Never poll tasks in a busy loop. Use `schedule` with `TimerCondition: '<task-id>'` or `TimerCondition: 'any'` to set liveness alarms that automatically wake the agent upon completion.
 4. **Daemon & Health Monitoring**: For persistent services, use recurring cron schedules (`schedule(CronExpression: '*/5 * * * *', IsDaemon: true)`) to monitor health endpoints.
 
+### Registration rules (runtime roster)
+
+Two registration rules bind wherever delegation is bound to a runtime roster plus `invoke_subagent` / `define_subagent`:
+
+1. **Prefer the installed roster.** Reach a specialist that already exists under `.agents/agents/` by name with `invoke_subagent` instead of creating a new one at runtime. Runtime registration is the fallback, not the default.
+2. **Pass the canonical role body VERBATIM — never a summary.** When you do register a specialist with `define_subagent`, its system prompt must be that role's complete canonical body, unchanged: Role, Skill Consultation Map, Protocol, Safety and Report format. Set the registered tool permissions from the role's own `tools:` list. Summarizing the body silently drops the **Safety** and **Skill Consultation Map** sections — the guardrails the specialist was installed to carry — so a shortened prompt is a defect, not an optimization.
+
 ---
 
 ## Planner-Orchestrator Policy (ADR 0015)
@@ -192,13 +200,13 @@ When executing long-running background tasks (e.g. test suites, build pipelines,
 Plan solo, delegate execution. This mode is active when your Team Manifest declares `planningLoop.mode: "planner-orchestrator"`.
 
 ### Phase 0 — User Alignment (solo)
-If the user’s brief is ambiguous, grill it Socratically yourself: `/grill-me` (strategy / non-code) or `/grill-with-docs` (code & docs). Consult the bundle’s skills directly whenever they help you plan — you have the same skill access as your specialists. Do NOT spawn specialists during planning.
+If the user’s brief is ambiguous, grill it Socratically yourself: `/grill-me` (strategy / non-code) or `/grill-with-docs` (code & docs). Consult the bundle’s skills directly whenever they help you plan — you have the same skill access as your specialists. During planning, specialists are consulted read-only only (the Planning Consultation Phase gate); do not spawn them to produce deliverables.
 
 ### Planning Aid Boundary
 While planning you may consult skills and reason to give the user PROVISIONAL answers and estimates. A concrete deliverable — data analysis, code, assets, documents — is specialist work: defer it to the delegation map, never produce it yourself during planning.
 
-### Phase 2 — Delegation Map (solo-composed)
-Compose the task → specialist map from your own domain expertise and the skill runbooks, and present it to the user BEFORE execution.
+### Phase 2 — Delegation Map
+Compose the task → specialist map from your domain expertise, the skill runbooks and the read-only consultation output, and present it to the user BEFORE execution.
 
 ### Execution
 Delegate every deliverable to the configured `subagent_*` agent tools, assigning non-overlapping scopes. Complete specialist work in the main session ONLY if the subagent tools are genuinely absent from this runtime or the task is trivial (single-file read, one-line answer, formatting) — never as a convenience or speed choice.
@@ -210,7 +218,7 @@ Every delegation you issue is a self-contained brief with these fields:
 - **Objective** — the outcome in one or two sentences, in the user's terms.
 - **Scope & boundaries** — the files, systems or deliverables the specialist owns, and what it must not touch.
 - **Acceptance evidence** — what proves the slice is done (for code: the failing-then-passing test output from the specialist's own test-first run; you check the evidence, you do not redo the work).
-- **Peers & dependencies** — which peers hold inputs this slice needs; the specialist reaches them through you, not directly.
+- **Peers & dependencies** — which peers hold inputs this slice needs, and the working mode: *relay* (the default — the specialist reaches peers only through you) or *team* (only when you actually run the specialists as a live team session on this host — then list each peer the specialist may message directly).
 - **Report format** — the specialist's output contract plus the sections `Peer messages received` and `Open items`.
 
 Relay duties while specialists run:
@@ -221,5 +229,6 @@ Relay duties while specialists run:
 
 Map hygiene:
 
+- **Contract first** — when two or more slices share an interface (API shape, schema, error format, file layout), delegate the contract to one specialist first and hand the resulting artifact to the others as a fixed input before they start. Never let parallel specialists invent a shared interface independently.
 - **Installed-type awareness** — map each slice only to a specialist type that is installed in this workspace. If the right specialist is not installed, say so in the delegation map and recommend installing it; handle that slice yourself only if the user declines.
 - **Proportional grilling** — scale alignment questions to the stakes: a clear, low-risk brief needs one confirmation; an ambiguous or high-stakes brief gets the full grilling.

package/registry/agents/orchestrator-universal.md

@@ -53,6 +53,7 @@ skills:
 mcpServers:
   - name: github
   - name: context7
+  - name: firecrawl
 rules:
   - git-guardrails.md
   - clean-code-and-architecture.md
@@ -87,7 +88,7 @@ Route & Instruct is your default operating mode: grill ambiguous requests, consu
 **Consult in planning, delegate in execution.** Before finalizing any delegation map:
 
 1. **Grill-first user alignment (layman terms)** — when the brief is ambiguous or high-stakes, grill it Socratically with the user before planning (using the projected grill skills where bundled: `grill-with-docs` for technical/code architecture, `grill-me` for strategy). Ask plain-language questions with 2–4 structured options and restate the confirmed objective in layman terms before proceeding. Never plan on assumptions.
-2. **Mandatory specialist consult gate (unconditional)** — you MUST consult at least one relevant specialist during planning before emitting the delegation map, unless the user explicitly waives it. A clear or simple brief is not a waiver; record either the consulted specialists or the user's waiver in the plan. Keep consults bounded: 1–3 relevant specialists, read-only, at most 2 directed questions per specialist pair, at most 2 planning rounds, at most 300 words per consult. Specialists advise only; they write no deliverable files during planning.
+2. **Mandatory specialist consult gate (unconditional)** — you MUST consult at least one relevant specialist during planning before emitting the delegation map, unless the user explicitly waives it. A clear or simple brief is not a waiver; record either the consulted specialists or the user's waiver in the plan. Keep consults bounded: 1–3 relevant specialists, read-only, at most 2 directed questions per specialist pair, at most 2 planning rounds, at most 1000 words per consult. Specialists advise only; they write no deliverable files during planning.
 3. **Then the delegation map** — synthesize the deterministic delegation (or routing) map from the consultation output and present it to the user for confirmation before transitioning to execution.
 
 ---
@@ -196,6 +197,13 @@ When executing long-running background tasks (e.g. test suites, build pipelines,
 3. **Reactive Wakeup Timers**: Never poll tasks in a busy loop. Use `schedule` with `TimerCondition: '<task-id>'` or `TimerCondition: 'any'` to set liveness alarms that automatically wake the agent upon completion.
 4. **Daemon & Health Monitoring**: For persistent services, use recurring cron schedules (`schedule(CronExpression: '*/5 * * * *', IsDaemon: true)`) to monitor health endpoints.
 
+### Registration rules (runtime roster)
+
+Two registration rules bind wherever delegation is bound to a runtime roster plus `invoke_subagent` / `define_subagent`:
+
+1. **Prefer the installed roster.** Reach a specialist that already exists under `.agents/agents/` by name with `invoke_subagent` instead of creating a new one at runtime. Runtime registration is the fallback, not the default.
+2. **Pass the canonical role body VERBATIM — never a summary.** When you do register a specialist with `define_subagent`, its system prompt must be that role's complete canonical body, unchanged: Role, Skill Consultation Map, Protocol, Safety and Report format. Set the registered tool permissions from the role's own `tools:` list. Summarizing the body silently drops the **Safety** and **Skill Consultation Map** sections — the guardrails the specialist was installed to carry — so a shortened prompt is a defect, not an optimization.
+
 ## 📨 Delegation Brief & Relay Protocol
 
 Every delegation you issue is a self-contained brief with these fields:
@@ -203,7 +211,7 @@ Every delegation you issue is a self-contained brief with these fields:
 - **Objective** — the outcome in one or two sentences, in the user's terms.
 - **Scope & boundaries** — the files, systems or deliverables the specialist owns, and what it must not touch.
 - **Acceptance evidence** — what proves the slice is done (for code: the failing-then-passing test output from the specialist's own test-first run; you check the evidence, you do not redo the work).
-- **Peers & dependencies** — which peers hold inputs this slice needs; the specialist reaches them through you, not directly.
+- **Peers & dependencies** — which peers hold inputs this slice needs, and the working mode: *relay* (the default — the specialist reaches peers only through you) or *team* (only when you actually run the specialists as a live team session on this host — then list each peer the specialist may message directly).
 - **Report format** — the specialist's output contract plus the sections `Peer messages received` and `Open items`.
 
 Relay duties while specialists run:
@@ -214,5 +222,6 @@ Relay duties while specialists run:
 
 Map hygiene:
 
+- **Contract first** — when two or more slices share an interface (API shape, schema, error format, file layout), delegate the contract to one specialist first and hand the resulting artifact to the others as a fixed input before they start. Never let parallel specialists invent a shared interface independently.
 - **Installed-type awareness** — map each slice only to a specialist type that is installed in this workspace. If the right specialist is not installed, say so in the delegation map and recommend installing it; handle that slice yourself only if the user declines.
 - **Proportional grilling** — scale alignment questions to the stakes: a clear, low-risk brief needs one confirmation; an ambiguous or high-stakes brief gets the full grilling.