delegation-bootstrap

name	delegation-bootstrap
description	Bootstrap the orchestrator + sub-agent delegation pattern for any Copilot CLI agent. Adds delegation on top of existing setups like GENESIS. Use when asked to "set up delegation", "add sub-agents", "bootstrap orchestrator", "enable delegation", "check delegation status", or "evolve my agent".

Delegation Bootstrap

Purpose

Transform any Copilot CLI agent from a "do everything myself" assistant into an orchestrator that delegates information gathering to sub-agents. This keeps the orchestrator's context window clean for synthesis, decision-making, and conversation — instead of flooding it with raw API output, transcripts, and query results.

This skill is additive — it layers the delegation pattern on top of whatever agent setup you already have (GENESIS, custom, or from scratch). It never overwrites existing files.

Prerequisites

• Copilot CLI installed and authenticated
• An existing agent definition in ~/.copilot/agents/ (or willingness to create one)
• A ~/.copilot/.working-memory/ directory (GENESIS creates this; if missing, we'll create it)

Commands

1. Bootstrap (bootstrap, set up delegation, add delegation)

Scaffold the delegation layer. Follow these steps IN ORDER:

Step 1: Discover existing setup

Check for these files and directories:

~/.copilot/agents/*.agent.md          — existing agent definitions
~/.copilot/.working-memory/           — working memory directory
~/.copilot/.working-memory/agent-briefing.md  — existing delegation framework
~/.copilot/.working-memory/rules.md   — existing operational rules
~/.copilot/skills/                    — existing skills
~/.copilot/copilot-instructions.md    — global instructions

Report what exists and what's missing. If agent-briefing.md already exists, warn that delegation may already be set up and suggest running status instead.

Step 2: Identify the orchestrator agent

Look in ~/.copilot/agents/ for the user's primary CoS/assistant agent. If multiple exist, ask which one should become the orchestrator. If none exist, offer to create a minimal one.

Step 3: Inject orchestrator instructions

Add this block to the agent definition (in the ## Role or ## Operating Model section, or create one). Do NOT remove existing content — append or integrate:

## Operating Model

**You are an orchestrator, not a data gatherer.** All information retrieval — API queries, search results, transcript analysis, file lookups — is delegated to sub-agents via the `task` tool. This keeps your context clean for synthesis, decision-making, and conversation.

When you need information:
1. Read `.working-memory/agent-briefing.md` for the delegation framework
2. Launch sub-agents with focused prompts
3. Synthesize the distilled results

**Never pull raw data into your own context.** If you're writing a query, running a CLI command for data, or reading a full transcript — stop. Delegate it.

Step 4: Create agent-briefing.md

If ~/.copilot/.working-memory/agent-briefing.md doesn't exist, create it with the STARTER TEMPLATE below. If the directory doesn't exist, create it first.

STARTER TEMPLATE — agent-briefing.md:

# Agent Briefing — Sub-Agent Delegation Framework

_Read by your orchestrator at session boot. Defines how to dispatch sub-agents._

## Purpose

Your orchestrator delegates information gathering to sub-agents via the `task` tool. This keeps the main context clean and focused on synthesis, decision-making, and user interaction.

## How to Dispatch Sub-Agents

### Prompt Construction Rules

Every sub-agent prompt should follow this pattern:

1. **Point to rules**: Tell the agent to read `~/.copilot/.working-memory/rules.md` for operational constraints.
2. **Point to the skill** (if one exists): Tell the agent to read the relevant `~/.copilot/skills/{skill-name}/SKILL.md` and follow its instructions. Do NOT paste CLI commands into the prompt — the skill file is the source of truth.
3. **Specify the task**: What specific question or data you need.
4. **Specify the return format**: Exactly what to return (keeps responses focused and context-efficient).

### Example Prompt

Read these files first:

1. ~/.copilot/.working-memory/rules.md
2. ~/.copilot/skills/{skill-name}/SKILL.md

Follow the skill instructions to {do the specific task}.

RETURN: {exactly what format you want back}

## Agent Type Selection

| Task | Agent Type | Why |
|------|-----------|-----|
| File/code search, vault lookups | `explore` | Fast, read-only, safe to run in parallel |
| API queries, CLI tools, complex reasoning | `general-purpose` | Needs full tool access + reasoning |
| Build/test/lint execution | `task` | Returns brief summary on success, full output on failure |
| Code review | `code-review` | Specialized for diff analysis |

## Parallel Execution

Launch multiple independent sub-agents simultaneously when possible. If you need data from three sources (e.g., Teams + ADO + email), dispatch three agents at once instead of sequentially.

## Agent Roster

_Start with the built-in agent types above. As you identify recurring dispatch patterns, add named agents here._

| Agent | Role | Agent Type | When to Use |
|-------|------|-----------|-------------|
| (none yet) | — | — | Add your first named agent when you notice you're writing the same dispatch prompt repeatedly |

## Key Rules for Sub-Agents

If a sub-agent can't read files (e.g., `explore` agents doing grep/glob only), embed critical rules directly in the prompt instead of pointing to rules.md.

Step 5: Ensure rules.md exists

If ~/.copilot/.working-memory/rules.md doesn't exist, create it with this starter:

# Rules — Operational Rules from Experience

_Each rule prevents a class of mistakes. When something goes wrong, add a one-liner here._

## General
- Present all times in the user's local timezone
- External actions (messages, work item updates, anything public-facing) get user approval first

## Sub-Agent Delegation
- Never pull raw transcripts, full result sets, or unfiltered API responses into the orchestrator's context
- Every sub-agent prompt must include: (1) read rules.md, (2) read relevant SKILL.md if one exists, (3) specify exact return format
- Never paste CLI commands from a skill into a sub-agent prompt — point the agent at the SKILL.md file instead

Step 6: Print the growth roadmap

After scaffolding, print this:

DELEGATION BOOTSTRAP COMPLETE

You're at Phase 1. Here's how the system grows from use:

Phase 1: DELEGATE (you are here)
  Your agent dispatches sub-agents instead of doing everything inline.
  The prompt template keeps results focused and context-efficient.

Phase 2: LEARN (happens from mistakes)
  When something breaks, add a rule to rules.md. Sub-agents read it
  before executing. Your system develops an immune system.

Phase 3: CODIFY (happens from repetition)
  When you write the same sub-agent prompt twice, extract it into a
  SKILL.md. Sub-agents read the skill file instead of getting
  instructions pasted in. Skills are codified automation.

Phase 4: SPECIALIZE (happens from domain gravity)
  When you always dispatch with the same framing for a domain, create
  a named agent in ~/.copilot/agents/. The roster in agent-briefing.md
  grows from usage, not upfront planning.

Phase 5: CONNECT (happens from team adoption)
  When teammates run their own orchestrators, agents can coordinate
  across boundaries — shared context, complementary specialists.

Each phase emerges naturally. Don't force it. Use the system, notice
patterns, and evolve when a pattern repeats enough to codify.

Run "delegation status" anytime to see where you are and what's next.

---

2. Status (status, check delegation, delegation status)

Assess the current state of the delegation system and determine the user's phase.

Checks to perform:

Phase 1 indicators:
  [ ] Agent definition contains orchestrator instructions
  [ ] agent-briefing.md exists
  [ ] rules.md exists

Phase 2 indicators:
  [ ] rules.md has more than the starter rules (user has added their own)
  Count: how many rules total?

Phase 3 indicators:
  [ ] Skills directory has SKILL.md files that sub-agents reference
  Count: how many skills with SKILL.md?

Phase 4 indicators:
  [ ] Named agents beyond the primary CoS exist in agents/
  [ ] agent-briefing.md roster has entries
  Count: how many named agents?

Phase 5 indicators:
  [ ] Evidence of cross-agent coordination (shared context, team dispatching)

Output format:

DELEGATION STATUS

  Phase: {1-5} — {DELEGATE|LEARN|CODIFY|SPECIALIZE|CONNECT}

  ✅ Orchestrator instructions in agent definition
  ✅ agent-briefing.md exists
  ✅ rules.md exists (14 rules)
  ✅ 8 skills with SKILL.md files
  ⬜ 0 named agents in roster (next evolution)

  NEXT STEP: You're dispatching "general-purpose" for everything.
  Think about which domain you dispatch to most often. That's your
  first named agent. Create an agent definition in ~/.copilot/agents/
  and add it to the roster in agent-briefing.md.

Provide a specific, actionable suggestion for the next evolution step based on what's missing.

---

3. Evolve (evolve, evolve delegation, next step)

Guide the user through their next natural evolution step. Based on their current phase:

Phase 1 → 2 (DELEGATE → LEARN): Ask: "What went wrong recently? A CLI command that failed? A query that returned bad data? A sub-agent that misunderstood your intent?" Then help them write a rule and add it to rules.md.

Phase 2 → 3 (LEARN → CODIFY): Ask: "What sub-agent prompt have you written more than once? Show me a recent example." Then help them extract it into a SKILL.md in a new skill directory.

Phase 3 → 4 (CODIFY → SPECIALIZE): Ask: "Which domain do you dispatch sub-agents to most often? ADO queries? Teams searches? Meeting analysis?" Then help them create a named agent definition in ~/.copilot/agents/ and add it to the roster.

Phase 4 → 5 (SPECIALIZE → CONNECT): Ask: "Who else on your team runs a CoS or orchestrator agent? What would it look like if your agents could share context or dispatch to each other's specialists?" Then help them think through the coordination model.

Constraints

• Additive only — never overwrite existing files. Check before creating, merge if needed.
• Portable — use ~ or ~/.copilot/ paths, never hardcode usernames or absolute paths.
• Opinionated but minimal — give the pattern, not a complete system. The system grows from use.
• Works with or without GENESIS — don't assume any particular agent framework.
• No hardcoded agent names — the user picks their own character/identity.
• Respect existing content — when injecting into an agent definition, preserve everything that's already there.