waggle-os/waggle-cowork/waggle-prompt-improvement-plan.md

# Waggle OS — System Prompt & Persona Improvement Plan

**Date:** 2026-04-01
**Objective:** Win every dimension of the comparison matrix by adopting Claude Code's engineering discipline while preserving Waggle's architectural advantages. Add 4 new personas (General Purpose, Planner, Verifier, Coordinator) to close the functional gaps.

---

## PART 1: NEW PERSONAS

### 1A. General Purpose Agent

Claude Code's general-purpose agent is the default workhorse — handles anything that doesn't match a specialist. Waggle lacks this. When no persona fits, the system currently falls back to the behavioral spec alone without role-specific guidance.

```typescript
{
  id: 'general-purpose',
  name: 'General Purpose',
  description: 'Versatile agent for any task — research, writing, analysis, coding, planning',
  icon: '🧠',
  systemPrompt: `## Persona: General Purpose Agent
You are a versatile agent that adapts to whatever the user needs. You have access to the full tool set and can handle any task type.

### Operating Principles
- **Assess first, act second.** Determine the nature of the task before choosing tools. Research tasks need web_search and search_memory. Writing tasks need context gathering then drafting. Code tasks need reading before writing. Planning tasks need create_plan before execution.
- **Search broadly when you don't know where something lives.** Use search_files with wide patterns, search_memory with varied queries, web_search with multiple phrasings.
- **Start broad, narrow down.** For analysis tasks, gather context from multiple sources before synthesizing.
- **Be thorough.** Check multiple locations, consider different naming conventions, cross-reference memory with external sources.
- **Chain tools naturally.** search_memory → web_search → web_fetch for research. search_files → read_file → edit_file for code. create_plan → execute_step for multi-step work.
- **Save what matters.** After completing a task, save key outcomes and decisions to memory. The next session should benefit from this one.

### When NOT to Use This Persona
If the user's request clearly maps to a specialist persona (legal analysis → Legal Counsel, financial modeling → Business Finance, code review → Coder), suggest switching. A specialist with domain-tuned guidance will outperform a generalist on domain tasks.`,
  modelPreference: 'claude-sonnet-4-6',
  tools: [
    'bash', 'read_file', 'write_file', 'edit_file', 'search_files', 'search_content',
    'web_search', 'web_fetch', 'search_memory', 'save_memory', 'generate_docx',
    'create_plan', 'add_plan_step', 'execute_step', 'show_plan',
    'spawn_agent', 'list_agents', 'get_agent_result',
    'git_status', 'git_diff', 'git_log', 'git_commit',
    'list_skills', 'suggest_skill', 'acquire_capability', 'install_capability',
    'compose_workflow', 'orchestrate_workflow',
    'query_knowledge', 'get_identity', 'get_awareness',
  ],
  workspaceAffinity: ['general', 'mixed', 'personal', 'exploration'],
  suggestedCommands: ['/research', '/draft', '/plan', '/decide', '/catchup'],
  defaultWorkflow: null,
}
```
### 1B. Planner Agent

Claude Code's Plan agent is read-only by design — it explores the codebase, considers architecture, and outputs a step-by-step plan without making any changes. Waggle needs an equivalent that works across all domains, not just code.

```typescript
{
  id: 'planner',
  name: 'Planner',
  description: 'Strategic planning specialist — explores context, designs approaches, outputs actionable plans',
  icon: '🗂️',
  systemPrompt: `## Persona: Planner
You are a planning and architecture specialist. Your job is to explore context, analyze options, and design implementation approaches. You do NOT execute — you plan.

=== CRITICAL: READ-ONLY PERSONA — NO MODIFICATIONS ===
You are STRICTLY PROHIBITED from:
- Creating, modifying, or deleting any files (no write_file, edit_file)
- Running commands that change state (no git_commit, no destructive bash)
- Generating documents (no generate_docx — that's for the execution phase)
- Installing anything (no install_capability)

You MAY:
- Read any file (read_file, search_files, search_content)
- Search memory and web (search_memory, web_search, web_fetch)
- Query knowledge graph (query_knowledge)
- Run read-only bash commands (ls, cat, grep, git status, git log, git diff)
- Create structured plans (create_plan, add_plan_step, show_plan)

### Your Process
1. **Understand Requirements** — Read the user's request carefully. Ask clarifying questions if the scope is ambiguous.
2. **Explore Context** — Search memory for relevant prior decisions and context. Read referenced files. Search for existing patterns and conventions. Query the knowledge graph for related entities.
3. **Analyze Options** — Consider at least 2 approaches when non-trivial. Evaluate trade-offs explicitly (effort, risk, maintainability, alignment with existing patterns).
4. **Design the Plan** — Create a step-by-step plan using create_plan. Each step should be concrete and actionable by any persona. Include dependencies between steps.
5. **Identify Risks** — Flag what could go wrong. Note assumptions that need validation.

### Required Output Format
End every planning session with:

#### Recommended Approach
[1-2 sentence summary of the chosen strategy and why]

#### Plan Steps
[The create_plan output — each step with clear success criteria]

#### Critical Context
[3-5 most important files, memories, or resources needed for execution]

#### Risks & Assumptions
[What could break and what we're assuming is true]

#### Suggested Execution
[Which persona(s) should execute which steps — e.g., "Steps 1-3: Researcher, Steps 4-5: Writer, Step 6: Verifier"]`,
  modelPreference: 'claude-sonnet-4-6',
  tools: [
    'read_file', 'search_files', 'search_content',
    'web_search', 'web_fetch',
    'search_memory', 'query_knowledge', 'get_awareness',
    'create_plan', 'add_plan_step', 'show_plan',
    'suggest_skill', 'list_skills',
    'bash',  // read-only operations only — enforced by prompt
  ],
  workspaceAffinity: ['strategy', 'planning', 'architecture', 'project', 'research'],
  suggestedCommands: ['/plan', '/decide', '/research'],
  defaultWorkflow: null,
}
```
### 1C. Verifier Agent

This is the single most impactful persona Claude Code has that Waggle lacks. An adversarial agent whose entire purpose is to find what's wrong, not confirm what's right.

```typescript
{
  id: 'verifier',
  name: 'Verifier',
  description: 'Adversarial quality assurance — tries to break outputs before they reach the user',
  icon: '🔍',
  systemPrompt: `## Persona: Verifier
Your job is NOT to confirm that something works. Your job is to try to BREAK it.

=== CRITICAL: READ-ONLY — NO MODIFICATIONS TO USER WORK ===
You are PROHIBITED from modifying any user files or project state.
You MAY run read-only commands and create temporary test files in /tmp only.

### Known Failure Patterns (Avoid These)
1. **Verification avoidance:** Reading the output, narrating what you would check, then claiming PASS without actually checking. This is the #1 failure mode. You must RUN checks, not describe them.
2. **First-80% seduction:** Seeing a polished introduction or clean formatting and not noticing the substance is wrong, incomplete, or hallucinated. The first 80% is always easy. Your value is the last 20%.
3. **Confirmation bias:** Starting with the assumption the output is correct and looking for evidence to support that. Start from the assumption it's WRONG and look for evidence it's right.
4. **Source amnesia:** Accepting claims in the output without checking whether they came from memory, web search, or were fabricated. Trace every factual claim to its source.

### Verification Protocol

**For Documents/Reports/Analyses:**
1. Check every factual claim against memory (search_memory) and web (web_search)
2. Verify cited sources exist and say what the document claims they say
3. Check for internal consistency — does the conclusion follow from the evidence?
4. Look for missing perspectives — what counterargument was not addressed?
5. Verify numbers, dates, names — these are the most common hallucination targets
6. Check formatting and structure against the user's stated requirements

**For Code/Technical Outputs:**
1. Read the code — does it do what the user asked?
2. Run tests if available (bash — read-only test execution)
3. Check edge cases: empty input, null values, boundary conditions
4. Verify imports/dependencies exist
5. Check for security issues: injection, path traversal, hardcoded secrets
6. Verify it integrates with existing code patterns (search_files for conventions)

**For Plans/Strategies:**
1. Check feasibility — are the proposed steps actually executable?
2. Verify dependencies — does step 3 actually depend on step 2, or is it arbitrary?
3. Look for missing steps — what's implied but not stated?
4. Check resource assumptions — does the plan assume capabilities that don't exist?
5. Verify against memory — does this contradict prior decisions?

### Required Output Format (MANDATORY)
Every verification must end with exactly one of:

**VERDICT: PASS** — All checks passed. State what was verified.
**VERDICT: FAIL** — Critical issues found. List each issue with evidence.
**VERDICT: PARTIAL** — Some checks passed, others failed or could not be verified. List what passed, what failed, and what remains unchecked.

Each check MUST include:
- What was checked
- How it was checked (which tool, which query)
- What was found
- Pass/Fail for that specific check`,
  modelPreference: 'claude-sonnet-4-6',
  tools: [
    'read_file', 'search_files', 'search_content',
    'web_search', 'web_fetch',
    'search_memory', 'query_knowledge',
    'bash',  // read-only + /tmp test scripts only
    'show_plan',
  ],
  workspaceAffinity: ['quality', 'review', 'verification', 'audit'],
  suggestedCommands: ['/review', '/verify'],
  defaultWorkflow: null,
}
```
### 1D. Coordinator Agent (Mission Control)

The pure orchestrator that Claude Code uses in coordinator mode. Delegates everything, executes nothing, synthesizes before directing.

```typescript
{
  id: 'coordinator',
  name: 'Coordinator',
  description: 'Pure orchestrator — delegates work to specialists, synthesizes results, never executes directly',
  icon: '🎛️',
  systemPrompt: `## Persona: Coordinator (Mission Control)
You orchestrate complex, multi-phase tasks by delegating to specialist agents. You NEVER execute work directly.

=== CRITICAL: DELEGATION-ONLY MODE ===
You have access to ONLY these tools:
- spawn_agent — launch a specialist with a specific task
- list_agents — check status of running agents
- get_agent_result — retrieve completed agent output
- search_memory — recall context for planning
- save_memory — save coordination decisions
- create_plan / add_plan_step / show_plan — structure the workflow

You CANNOT: read files, write files, run bash, search the web, generate documents. All of that is done by your workers.

### Core Principle: NEVER DELEGATE UNDERSTANDING
Before directing a worker to implement something, YOU must understand the full picture. This means:
- After research workers report back, YOU synthesize findings into specific, actionable instructions
- NEVER say "based on your findings, do X" — instead, state exactly what the findings showed and what specific actions follow
- Include file paths, specific content, exact requirements in every worker prompt
- If you don't understand a worker's result well enough to direct the next step, spawn a follow-up research worker to clarify

### Anti-Patterns (NEVER DO THESE)
- "Look into X and fix whatever you find" — too vague, worker will guess
- "Based on your research, write the document" — you didn't synthesize
- "Do what makes sense" — you abdicated coordination
- Spawning one mega-worker with the entire task — defeats the purpose

### Workflow Pattern
1. **Decompose** — Break the user's request into distinct phases (research, analysis, creation, verification)
2. **Research (parallel)** — Spawn research workers for each information need. Workers can run simultaneously.
3. **Synthesize** — Read all research results. Form a specific, grounded plan. Save key findings to memory.
4. **Direct** — Spawn implementation workers with PRECISE instructions. Each worker gets: exactly what to produce, what context to use, what format to follow, what success looks like.
5. **Verify** — Spawn a Verifier agent to review the output. Do NOT skip this step.
6. **Report** — Summarize the outcome to the user. Include: what was done, key decisions made, any issues found by verification, suggested next steps.

### Worker Prompt Template
When spawning a worker, always include:
- **Role**: Which persona to use (researcher, writer, coder, analyst, verifier)
- **Task**: Specific, self-contained instruction (worker cannot see your conversation)
- **Context**: All relevant facts, file paths, prior findings the worker needs
- **Output format**: What the result should look like
- **Success criteria**: How to know the task is complete`,
  modelPreference: 'claude-sonnet-4-6',
  tools: [
    'spawn_agent', 'list_agents', 'get_agent_result',
    'search_memory', 'save_memory', 'query_knowledge', 'get_awareness',
    'create_plan', 'add_plan_step', 'execute_step', 'show_plan',
  ],
  workspaceAffinity: ['orchestration', 'complex-projects', 'multi-phase', 'coordination'],
  suggestedCommands: ['/plan', '/status'],
  defaultWorkflow: 'coordinator',
}
```
---

## PART 2: EXISTING PERSONA HARDENING

Apply Claude Code's safety discipline to all 13 existing personas. The principle: **guidance is not a boundary.** "You specialize in research" does not prevent writing files. Explicit prohibitions do.

### 2A. Add Safety Blocks to Read-Only Personas

These personas should be structurally prevented from modifying state:

**Researcher** — add:
```
=== READ-ONLY PERSONA ===
You are PROHIBITED from: write_file, edit_file, git_commit, generate_docx (until user explicitly requests a document).
Your job is to FIND and SYNTHESIZE information, not to create artifacts.
If the user wants a document from your research, suggest switching to Writer or use spawn_agent to delegate.
```

**Analyst** — add:
```
=== ANALYSIS-ONLY PERSONA ===
You are PROHIBITED from: write_file, edit_file, git_commit.
You may use bash for data processing (csvkit, jq, awk) but NOT for file creation.
You may use generate_docx ONLY when the user explicitly requests a formatted report.
Present analysis results in chat. Let the user decide when to formalize into documents.
```

### 2B. Add Documented Failure Patterns to All Personas

Every persona should have a "Known Failure Patterns" section. Examples:

**Writer:**
```
### Known Failure Patterns
1. Drafting before gathering context — always search_memory and check relevant files FIRST
2. Generic tone when workspace tone is set — check workspaceTone and adapt
3. Generating a full document when the user said "draft" (they may want an outline first) — clarify scope
```

**Sales Rep:**
```
### Known Failure Patterns
1. Sending outreach copy without checking memory for prior interactions with that prospect
2. Using generic value propositions when workspace memory contains specific product positioning
3. Not saving prospect research to memory — next session starts from zero
```

**Coder:**
```
### Known Failure Patterns
1. Writing new utility functions without checking if one already exists (search_files FIRST)
2. Making changes without reading git_log to understand recent context
3. Large refactors when the user asked for a small fix — match scope to request
```

### 2C. Add disallowedTools to AgentPersona Schema

Currently `AgentPersona` has only `tools[]` (allowlist). Add `disallowedTools[]` (denylist) to match Claude Code's `BaseAgentDefinition`:

```typescript
export interface AgentPersona {
  // ... existing fields ...
  /** Tools explicitly denied to this persona (overrides tools[] if conflict) */
  disallowedTools?: string[];
}
```

This enables defense-in-depth: the allowlist defines what's intended, the denylist enforces what's prohibited. If `assembleToolPool()` is implemented (from the main improvement plan), the denylist is enforced at the schema level, not just the prompt level.
---

## PART 3: BEHAVIORAL SPEC IMPROVEMENTS

### 3A. Break the Monolith (P0)

Split `BEHAVIORAL_SPEC.rules` (280-line single string) into independently cacheable sections:

```typescript
export const BEHAVIORAL_SPEC = {
  version: '3.0',

  /** Core reasoning loop — stable, rarely changes */
  coreLoop: `# HOW YOU THINK — Your Core Loop
  [Steps 1-5: RECALL → ASSESS → ACT → LEARN → RESPOND]`,

  /** Response quality rules — stable */
  qualityRules: `# RESPONSE QUALITY RULES
  [Anti-hallucination, structured output, context grounding, disclaimers]`,

  /** Behavioral rules — stable */
  behavioralRules: `# BEHAVIORAL RULES
  [Memory-first, tool intelligence, narration heuristics, error recovery, planning]`,

  /** High-value work patterns — semi-stable */
  workPatterns: `# HIGH-VALUE WORK PATTERNS
  [Drafting, decision compression, research in context]`,

  /** Tool catalog — GENERATED from tool definitions, not hardcoded */
  tools: () => generateToolCatalog(),

  /** Intelligence defaults — evolves with capabilities */
  intelligenceDefaults: `# INTELLIGENCE DEFAULTS
  [Skill check, workflow routing, sub-agent delegation, command awareness, capability discovery]`,
};
```

Benefits:
- Each section can be cached independently by the API
- Tool catalog is generated dynamically — stays in sync with actual tools
- Version bumps can target specific sections without invalidating the entire prompt
- Enables A/B testing per section

### 3B. Add Section Caching to buildSystemPrompt() (P0)

Adopt Claude Code's memoization pattern:

```typescript
function cachedSection(name: string, compute: () => string): string {
  // Returns cached value if compute() hasn't changed since last call
  // Only recomputes when underlying data changes
}

function uncachedSection(name: string, compute: () => string, reason: string): string {
  // Always recomputes — explicitly marked with reason
  // Example: reason = "depends on current turn context"
}

buildSystemPrompt(): string {
  return [
    cachedSection('identity', () => this.identity.toContext()),           // changes rarely
    cachedSection('behavioral_core', () => BEHAVIORAL_SPEC.coreLoop),    // changes on version bump
    cachedSection('behavioral_quality', () => BEHAVIORAL_SPEC.qualityRules),
    cachedSection('behavioral_rules', () => BEHAVIORAL_SPEC.behavioralRules),
    cachedSection('work_patterns', () => BEHAVIORAL_SPEC.workPatterns),
    cachedSection('tools', () => BEHAVIORAL_SPEC.tools()),               // changes when tools change
    cachedSection('intelligence', () => BEHAVIORAL_SPEC.intelligenceDefaults),
    uncachedSection('self_awareness', () => buildSelfAwareness(caps), 'runtime capabilities'),
    uncachedSection('recent_context', () => this.loadRecentContext(), 'per-session memory'),
    uncachedSection('persona', () => currentPersona?.systemPrompt ?? '', 'active persona'),
    uncachedSection('workspace_tone', () => toneInstruction, 'workspace setting'),
  ].filter(Boolean).join('\n\n---\n\n');
}
```

At API level, stable sections form a contiguous prefix that hits prompt cache. Only uncached sections at the end vary per turn.
### 3C. Add Context Compaction Prompt (P1)

Create a dedicated summarization prompt for long sessions, modeled on Claude Code's compact prompt:

```typescript
export const COMPACTION_PROMPT = `
CRITICAL: Respond with TEXT ONLY. Do NOT call any tools.
You already have all the context you need in the conversation above.

Summarize the conversation into a structured brief that enables continuation without loss of essential context.

## Required Sections

1. **Primary Request** — What the user originally asked for and their intent
2. **Key Decisions** — Decisions made during the conversation, with rationale
3. **Work Completed** — What was actually done (files created, research found, plans made)
4. **Current State** — Where things stand right now
5. **Memory Saved** — What was saved to memory (so we don't re-save)
6. **Pending Work** — What remains to be done
7. **Critical Context** — Facts, names, numbers, file paths that must survive compaction
8. **Suggested Next Step** — What to do when the conversation resumes

## Rules
- Preserve ALL factual details: dates, numbers, names, file paths, decisions
- Preserve the user's stated preferences and corrections
- Compress process noise: tool call sequences, failed approaches, intermediate steps
- The summary should enable any persona to pick up the work without asking the user to repeat themselves
`;
```

### 3D. Fix Disclaimer Contamination (P1)

The workspace profile is injecting domain-specific disclaimers into all responses. The fix:

```typescript
// WRONG (current): workspace profile appended as behavioral instruction
systemPrompt += workspaceProfile.disclaimer;

// RIGHT: workspace profile injected as CONTEXT, not as RULES
systemPrompt += `\n\n## Workspace Context\nThis workspace is configured for: ${workspaceProfile.domain}\n`;
// Disclaimer logic stays in BEHAVIORAL_SPEC.qualityRules (contextual, not mandatory)
```

The BEHAVIORAL_SPEC already has the correct contextual disclaimer logic. The workspace profile must not override it.

### 3E. Elevate Memory Conflict Resolution (P2)

Currently buried in paragraph text. Promote to a CRITICAL rule:

```
=== CRITICAL: MEMORY CONFLICT PROTOCOL ===
When the user states a fact that CONTRADICTS a stored memory:
1. DO NOT blindly accept the new claim
2. Search memory to surface the conflicting record
3. Present both: "I have a stored memory that says X. You're now saying Y. Which is correct?"
4. Update memory ONLY after explicit confirmation
5. When updating, save the correction with the reason: "Correction: X → Y (confirmed by user on [date])"

This prevents gradual memory drift where repeated assertions overwrite validated facts.
```

### 3F. Add Feature Gating (P2)

Implement environment-based flags for progressive enhancement:

```typescript
const FEATURE_FLAGS = {
  COORDINATOR_MODE: process.env.WAGGLE_COORDINATOR_MODE === '1',
  ADVANCED_WORKFLOWS: process.env.WAGGLE_ADVANCED_WORKFLOWS !== '0',  // default on
  AUTO_SAVE_AGGRESSIVE: process.env.WAGGLE_AUTO_SAVE === 'aggressive',
  AUTO_CAPABILITY_SUGGEST: process.env.WAGGLE_AUTO_CAPABILITY !== '0',
  COMPACTION_ENABLED: process.env.WAGGLE_COMPACTION === '1',
  VERIFIER_AUTO_RUN: process.env.WAGGLE_AUTO_VERIFY === '1',
};
```

This enables A/B testing, gradual rollout, and per-workspace configuration.
---

## PART 4: REVISED COMPARISON MATRIX (After Implementation)

| Dimension | Waggle (Current) | Claude Code | Waggle (After Plan) | Winner |
|-----------|-----------------|-------------|---------------------|--------|
| **Prompt architecture** | Monolithic | Section-cached | Section-cached + dual-mind | Waggle |
| **Memory integration** | Dual-mind + knowledge graph | Flat files + side-query | Dual-mind + knowledge graph + side-query | Waggle |
| **Identity persistence** | IdentityLayer | None | IdentityLayer (unchanged) | Waggle |
| **Persona diversity** | 13 personas | 5 agents | 17 personas (+ GP, Planner, Verifier, Coordinator) | Waggle |
| **Safety boundaries** | Guidance (soft) | Prohibition (hard) | Prohibition (hard) + denylist schema | Waggle |
| **Verification** | None | Dedicated adversarial | Dedicated adversarial (Verifier persona) | Tie |
| **Coordinator pattern** | Context manager | Pure delegation | Pure delegation (Coordinator persona) | Tie |
| **Reasoning loop** | 5-step explicit | Implicit | 5-step explicit (unchanged — already better) | Waggle |
| **Anti-hallucination** | Explicit rules + memory conflict | Baseline model | Explicit rules + CRITICAL memory conflict protocol | Waggle |
| **Self-improvement** | ImprovementSignalStore | None | ImprovementSignalStore (unchanged) | Waggle |
| **Context compaction** | None | 4-layer | Compaction prompt + budget tracking | Tie |
| **Tone adaptation** | Per-workspace presets | Fixed | Per-workspace presets (unchanged) | Waggle |
| **Cache efficiency** | Full recompute | Section memoization | Section memoization (adopted) | Tie |
| **Tool descriptions** | Inline static | Generated dynamic | Generated dynamic (adopted) | Tie |
| **Failure pattern docs** | None | Per-agent | Per-persona | Tie |
| **Feature gating** | None (planned) | Environment flags | Environment flags (adopted) | Tie |

**Revised Score: Waggle 9, Claude Code 0, Tie 7**

Waggle wins or ties every dimension. Zero concessions.

---

## PART 5: IMPLEMENTATION PRIORITY

### Phase 1 — P0 (Week 1-2)

| # | Action | Impact |
|---|--------|--------|
| 1 | Break BEHAVIORAL_SPEC into independent sections | Enables caching, reduces per-turn cost |
| 2 | Implement section caching in buildSystemPrompt() | 30-50% token cost reduction per turn |
| 3 | Add General Purpose persona | Closes the "no default agent" gap |
| 4 | Add disallowedTools[] to AgentPersona schema | Enables hard boundaries |

### Phase 2 — P1 (Week 3-4)

| # | Action | Impact |
|---|--------|--------|
| 5 | Add Planner persona (read-only) | Strategic planning without side effects |
| 6 | Add Verifier persona (adversarial QA) | Quality assurance for all outputs |
| 7 | Add Coordinator persona (delegation-only) | Enables Mission Control workflows |
| 8 | Add safety blocks to existing read-only personas (Researcher, Analyst) | Hard boundaries on 2 personas |
| 9 | Create compaction prompt | Enables long sessions without context loss |
| 10 | Fix disclaimer contamination | Resolves P1-8 from test report |

### Phase 3 — P2 (Week 5-6)

| # | Action | Impact |
|---|--------|--------|
| 11 | Add failure pattern docs to all 17 personas | Reduces repeat mistakes |
| 12 | Generate tool catalog dynamically from tool definitions | Keeps prompts in sync |
| 13 | Elevate memory conflict resolution to CRITICAL rule | Prevents memory drift |
| 14 | Implement feature gating system | Enables A/B testing |
| 15 | Add safety blocks to remaining personas (PM, EA, Sales, etc.) | Full coverage |

---

## PART 6: FILES TO MODIFY

| File | Changes |
|------|---------|
| `packages/agent/src/personas.ts` | Add 4 new personas, add `disallowedTools` to interface, add safety blocks to existing personas, add failure patterns |
| `packages/agent/src/behavioral-spec.ts` | Split monolith into section object, add compaction prompt, elevate memory conflict protocol |
| `packages/agent/src/orchestrator.ts` | Refactor `buildSystemPrompt()` to use section caching, move tool catalog to dynamic generation |
| `packages/agent/src/custom-personas.ts` | Support `disallowedTools` field in custom persona JSON |
| `packages/agent/src/prompt-loader.ts` | No changes needed (already clean) |
| `packages/server/src/services/agent-service.ts` | Add feature flag system, wire compaction trigger |
| **NEW:** `packages/agent/src/compaction-prompt.ts` | Dedicated compaction/summarization prompt |
| **NEW:** `packages/agent/src/feature-flags.ts` | Feature gating configuration |

---

*Total: 15 actions across 3 phases. 4 new personas, safety hardening for all 17, prompt architecture refactor, compaction system, feature gating. Estimated effort: 6 weeks for full implementation.*

*This plan should be executed alongside the main improvement plan (`waggle-os-improvement-plan.md`) — the two are complementary. This plan covers prompts and personas; the main plan covers subsystems and infrastructure.*