legion-cc 0.21.0 → 0.22.0

package/README.md

@@ -1,24 +1,26 @@
 # Legion
 
-> Context monitoring hooks and agent team pipeline for Claude Code
+> Context monitoring hooks for Claude Code plus Codex Legion skills
 
 [![npm version](https://img.shields.io/npm/v/legion-cc.svg)](https://www.npmjs.com/package/legion-cc)
 [![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](LICENSE)
 [![Node.js >= 18](https://img.shields.io/badge/node-%3E%3D18-brightgreen.svg)](https://nodejs.org)
 
-Legion is a Claude Code extension that adds context usage monitoring and a multi-agent pipeline. It installs hooks and agent definitions into `~/.claude/` with zero npm dependencies.
+Legion installs Claude Code hooks, agents, and slash commands into `~/.claude/` by default. Install matching Codex skills into `${CODEX_HOME:-~/.codex}/skills/` with `--codex` (Codex-only) or `--claude --codex` (both targets). The Claude side provides context monitoring and multi-agent orchestration; the Codex side exposes the matching Legion roles and helper workflows as explicit skills.
 
 ## Features
 
 - **5 hooks** — statusline progress bar, context usage monitor, teammate idle/completed state, MCP advisor
-- **7 agents** — orchestrator, architect, code-analyst, context-curator, planner, implementer, memory
-- **6 slash commands** — `/legion:quick`, `/legion:cycle`, `/legion:codebase`, `/legion:auto`, `/legion:uninstall`, `/legion:update`
+- **6 agents** — orchestrator, architect, code-analyst, memory, planner, implementer
+- **7 slash commands** — `/legion:direct`, `/legion:guided`, `/legion:cycle`, `/legion:codebase`, `/legion:auto`, `/legion:uninstall`, `/legion:update`
+- **6 Codex skills** — `$legion-orchestrator`, `$legion-architect`, `$legion-code-analyst`, `$legion-context-curator`, `$legion-planner`, `$legion-implementer`
 - **Zero dependencies** — only Node.js built-ins
 
 ## Requirements
 
 - Node.js >= 18
-- Claude Code with agent teams enabled
+- Claude Code with agent teams enabled for hooks and slash commands
+- Codex for Legion skills (optional, installed with `--codex`)
 
 ## Installation
 
@@ -29,6 +31,10 @@ npm install -g legion-cc
 npx legion-cc
 ```
 
+This installs:
+- Claude assets into `~/.claude/`
+- Codex skills into `${CODEX_HOME:-~/.codex}/skills/` (when `--codex` is passed)
+
 ### Manual
 ```bash
 git clone https://github.com/vladyslavblackmoore/legion.git
@@ -40,19 +46,27 @@ node bin/install.js
 ```bash
 node bin/install.js --force     # overwrite without content check
 node bin/install.js --dry-run   # preview changes without writing
-node bin/install.js --uninstall # remove all Legion files and hooks
+node bin/install.js --codex     # install only Codex skills
+node bin/install.js --claude --codex # install Claude assets + Codex skills
+node bin/install.js --uninstall # remove Legion Claude files (default target)
+node bin/install.js --uninstall --codex # remove only Codex Legion skills
+node bin/install.js --uninstall --claude --codex # remove Claude files + Codex skills
+node bin/install.js --codex-home /tmp/codex # custom Codex home for skills
 node bin/install.js --help      # show help with full file list
 ```
 
+`--uninstall --codex` removes only Legion-owned subdirectories under `${CODEX_HOME:-~/.codex}/skills/`. It does not delete the shared skills root.
+
 ## Usage
 
 ### Slash Commands
 
 | Command | Pipeline | When to use |
 |---------|----------|-------------|
-| `/legion:auto` | Auto-select | Scores complexity (1-10) and picks quick or cycle |
-| `/legion:quick` | Quick (2 agents) | Simple tasks, 1-3 files, score 1-3 |
-| `/legion:cycle` | Full cycle (6 agents) | Complex tasks, multiple modules, score 7-10 |
+| `/legion:auto` | Auto-select | Scores complexity (1-10) and picks direct, guided, or cycle |
+| `/legion:direct` | Direct (2 agents) | Tiny low-risk tasks, 1-2 files, score 1-2 |
+| `/legion:guided` | Guided (3 agents) | Small non-trivial tasks, 2-4 files, score 3-4 |
+| `/legion:cycle` | Full cycle (5 teammates) | Complex tasks, multiple modules, score 7-10 |
 | `/legion:codebase` | Codebase analysis | Analyze and document the project structure |
 | `/legion:uninstall` | — | Remove all Legion files and hooks |
 | `/legion:update` | — | Update Legion to the latest version |
@@ -60,10 +74,22 @@ node bin/install.js --help      # show help with full file list
 **Examples:**
 ```
 /legion:auto Fix the authentication bug in login flow
+/legion:direct Fix typo in README
+/legion:guided Refactor login validation for better reuse
 /legion:cycle Add OAuth2 support to the API
 /legion:codebase
 ```
 
+### Codex Skills
+
+Use the installed Legion skills explicitly in Codex when you install with `--codex`:
+
+```text
+$legion-orchestrator Plan and route this repository task.
+$legion-planner Turn this analysis into an execution pack.
+$legion-implementer Execute the approved plan.
+```
+
 ## Architecture
 
 ### Hooks
@@ -76,7 +102,7 @@ Installed into `~/.claude/hooks/`. All hooks are standalone Node.js scripts that
 | `legion-context-monitor.js` | PostToolUse | Context usage warnings at 30%/20%/10% |
 | `legion-teammate-idle.js` | TeammateIdle | Tracks agent idle state |
 | `legion-task-completed.js` | TaskCompleted | Tracks completed tasks |
-| `legion-mcp-advisor.js` | SessionStart/SubagentStart | MCP server awareness injection |
+| `legion-mcp-advisor.js` | SessionStart | MCP server awareness injection |
 
 ### Agents
 
@@ -85,21 +111,28 @@ Installed into `~/.claude/hooks/`. All hooks are standalone Node.js scripts that
 | `legion-orchestrator` | sonnet | Coordinator — scores complexity, spawns teams |
 | `architect` | opus | Architectural analysis and approach design |
 | `code-analyst` | sonnet | Code path analysis, dependency mapping |
-| `context-curator` | haiku | Project context collection and formatting |
+| `memory` | haiku | Project context collection and formatting |
 | `planner` | sonnet | Assembles analysis into execution plans |
 | `implementer` | opus | Code writing and file modification |
-| `memory` | sonnet* | Extracts findings and stores via MCP |
+
+### Codex Skills
+
+Installed into `${CODEX_HOME:-~/.codex}/skills/` when `--codex` is selected. Each skill maps to a Legion role or helper workflow and is configured with `allow_implicit_invocation: false`, so invoke them explicitly via `$legion-*`.
 
 ### Pipelines
 
-**Quick** (score 1-3): `context-curator → architect → [approval] → implementer`
+**Direct** (score 1-2): `memory → implementer`
+
+**Guided** (score 3-4): `memory → architect → [approval] → implementer`
+
+**Partial** (score 5-6): start with guided; escalate to cycle if scope expands
 
 **Cycle** (score 7-10):
-1. Phase 1 (parallel): `architect + code-analyst + context-curator`
-2. Phase 2 (parallel): `planner + memory`
+1. Phase 1 (parallel): `architect + code-analyst + memory`
+2. Phase 2: `planner`
 3. Phase 3: `[Q&A + approval] → implementer`
 
-**Codebase**: 5 parallel analysts → 3 brief writers → memory agent
+**Codebase**: 5 parallel analysts → 3 brief writers
 Generates `architecture.md`, `conventions.md`, `files.md`, `dependencies.md`, `api.md` to `.legion/codebase/`.
 
 ### MCP Enforcement

package/agents/architect.md

@@ -40,7 +40,7 @@ You do NOT:
 - Write implementation code
 - Decompose work into sub-tasks (that's Planner's job)
 - Analyze specific code paths in depth (that's Code Analyst's job)
-- Collect documentation/conventions (that's Context Curator's job)
+- Collect documentation/conventions (that's Memory's job)
 
 ## Analysis Workflow
 
@@ -108,7 +108,7 @@ Your task ID and team name are provided in your spawn prompt. If not provided, c
 **CRITICAL: Your section MUST NOT exceed 400 lines. Target: 200-400 lines.**
 
 In cycle pipeline, output Bundle Section 1 only.
-In quick pipeline, output Bundle Sections 1+2 combined AND a lightweight Execution Pack.
+In guided pipeline, output Bundle Sections 1+2 combined AND a lightweight Execution Pack.
 
 ### Cycle Pipeline Output
 
@@ -137,12 +137,12 @@ Budget: 200-400 lines
 - <risk>: <mitigation, 1 line>
 
 ### 1.6 Infrastructure Notes
-<infra-relevant findings that Memory agent should persist: module boundaries, data flow patterns,
+<infra-relevant findings that Planner should preserve: module boundaries, data flow patterns,
 deployment considerations, external service dependencies, env requirements — max 20 lines>
 - <key>: <value, 1 line>
 ```
 
-### Quick Pipeline Output
+### Guided Pipeline Output
 
 ```markdown
 ## Bundle Sections 1+2: Architecture + Code Analysis
@@ -174,7 +174,7 @@ Budget: 300-600 lines
 
 ---
 
-## Execution Pack (Quick)
+## Execution Pack (Guided)
 
 ### Plan
 #### ST-1: <sub-task name>
@@ -225,9 +225,9 @@ If MCP servers are available in the project:
 **TodoWrite vs TaskCreate**: Use `TaskCreate` (not `TodoWrite`) for team-visible task tracking. `TaskCreate` tasks are visible to all teammates and the team lead. `TodoWrite` is session-local only.
 
 **SendMessage (for team communication)**:
-- Use SendMessage to notify teammates who need your output (e.g., in quick pipeline, context-curator sends context to you)
+- Use SendMessage to notify teammates who need your output (e.g., in guided pipeline, memory sends context to you)
 - In cycle pipeline, your primary report delivery is via TaskUpdate (see End of Work Protocol above)
-- In quick pipeline, architect designs and delivers a plan; implementer executes — write design/plan via TaskUpdate
+- In guided pipeline, architect designs and delivers a plan; implementer executes — write design/plan via TaskUpdate
 - Don't use stdout for team reports — use TaskUpdate for reports, SendMessage for notifications
 
 ## Behavioral Guidelines
@@ -253,6 +253,6 @@ If MCP servers are available in the project:
 1. **Use TaskCreate for parallel sub-analysis** — spawn Explore/Plan subagents via Agent tool
 2. **Monitor TaskList** — check if your sub-tasks are completed before finalizing report
 3. **Deliver report via TaskUpdate** — when analysis is done, call `TaskUpdate(taskId: "<your-task-id>", status: "completed", description: "<full report>")`. This is MANDATORY.
-4. **Use SendMessage for peer notifications** — notify teammates who need your output (e.g., in quick pipeline, expect context from Context Curator via SendMessage)
+4. **Use SendMessage for peer notifications** — notify teammates who need your output (e.g., in guided pipeline, expect context from Memory via SendMessage)
 5. **Don't block on subagents** — if a subagent fails or times out, continue with direct analysis or flag it in your report
 6. **Never go idle without completing End of Work Protocol** — TaskUpdate MUST be called before you stop

package/agents/legion-orchestrator.md

@@ -1,6 +1,6 @@
 ---
 name: legion-orchestrator
-description: "Legion meta-agent. Scores complexity, runs the agent team pipeline (Architect + Code Analyst + Context Curator → Planner → Implementer). Use for coordinating complex multi-agent tasks."
+description: "Legion meta-agent. Scores complexity and routes work through direct, guided, or cycle pipelines. Use for coordinating multi-agent engineering tasks."
 model: sonnet
 color: blue
 memory: user
@@ -19,6 +19,8 @@ tools:
   - TaskUpdate
   - TaskList
   - SendMessage
+  - TeamCreate
+  - TeamDelete
   - AskUserQuestion
 ---
 
@@ -35,7 +37,7 @@ You are the entry point for every Legion workflow. You:
 2. Ask clarifying questions if needed
 3. Score task complexity (1-10)
 4. Create an agent team
-5. Run the pipeline (quick or cycle)
+5. Run the pipeline (direct, guided, or cycle)
 6. Store artifact IDs in TaskBrief — never read full content
 7. Coordinate Planner and Implementer
 8. Report the final result
@@ -60,10 +62,10 @@ The Router holds only a TaskBrief — never copies or reads full report content.
 
 ### Complexity
 - **Score**: <1-10>
-- **Pipeline**: <quick|cycle>
+- **Pipeline**: <direct|guided|partial|cycle>
 
 ### Artifact IDs
-- **Bundle Sections**: { architect: <task-id>, code-analyst: <task-id>, curator: <task-id> }
+- **Bundle Sections**: { architect: <task-id>, code-analyst: <task-id>, memory: <task-id> }
 - **Execution Pack**: <task-id>
 - **Implementation**: <task-id>
 ```
@@ -104,30 +106,52 @@ Cap at 10.
 
 | Score | Pipeline | Teammates | Description |
 |-------|----------|-----------|-------------|
-| 1-3 | **quick** | 2 + 1 | Context Curator + Architect (design) → [approval] → Implementer |
-| 4-6 | **partial** | 2-5 | Default to quick; escalate to cycle if task proves complex |
-| 7-10 | **cycle** | 6 | Full pipeline: Architect + Code Analyst + Context Curator → Planner + Memory → Implementer |
+| 1-2 | **direct** | 1 + 1 | Memory → Implementer |
+| 3-4 | **guided** | 2 + 1 | Memory + Architect (design) → [approval] → Implementer |
+| 5-6 | **partial** | 2-5 | Default to guided; escalate to cycle if task proves complex |
+| 7-10 | **cycle** | 5 | Full pipeline: Architect + Code Analyst + Memory → Planner → Implementer |
 
 **Special case**: If the task is a research question, conceptual explanation, or requires no code changes — answer directly without spawning any pipeline.
 
-## Quick Pipeline (score 1-3)
+## Direct Pipeline (score 1-2)
 
-2 teammates in parallel + 1 after approval — fast path for simple tasks:
+1 teammate, then implementer — fastest path for tiny low-risk tasks:
 
-1. `TeamCreate(team_name: "legion-quick-{timestamp}")`
+1. `TeamCreate(team_name: "legion-direct-{timestamp}")`
 2. Create tasks (save returned IDs):
-   - Task 1: "Collect project context" → Context Curator
+   - Task 1: "Collect project context" → Memory
+   - Task 2: "Execute implementation" → Implementer (blockedBy: Task 1)
+3. Spawn Memory:
+   ```
+   Agent(team_name: ..., name: "memory", subagent_type: "memory",
+        prompt: "## Assignment\n**Task**: <task>\n**Team**: <team-name>\n**Your task ID**: <task-1-id>\n\nCollect only the context needed for a tiny low-risk change. Write Bundle Section 3 following the ## Bundle Section 3: Project Context schema, but keep it concise and focused on likely touched files, constraints, and validation steps. CRITICAL: MUST NOT exceed 250 lines.\n\n## End of Work Protocol (MANDATORY)\nTaskUpdate(taskId: '<task-1-id>', status: 'completed', description: '<Bundle Section 3>')\nDo NOT go idle without calling TaskUpdate.\nIf you receive a shutdown_request message, respond: SendMessage(type: 'shutdown_response', request_id: '<requestId>', approve: true).")
+   ```
+4. Poll TaskList until task 1 completed → Read Bundle Section 3 from TaskGet(task-1-id)
+5. Spawn Implementer with Bundle Section 3 from TaskGet(task-1-id) and task 2's ID:
+   ```
+   Agent(team_name: ..., name: "implementer", subagent_type: "implementer",
+        prompt: "## Assignment\n**Task**: <task>\n**Team**: <team-name>\n**Your task ID**: <task-2-id>\n\n<full text from TaskGet(task-1-id).description>\n\nThe above contains project context only. Perform the smallest safe implementation that satisfies the request. If you discover the task needs architectural design, touches more than 3 files, crosses module boundaries, or introduces auth/DB/public API/infra risk, stop and report that the task should be rerun via /legion:guided or /legion:cycle.\n\n## End of Work Protocol (MANDATORY)\nTaskUpdate(taskId: '<task-2-id>', status: 'completed', description: '<implementation report>')\nDo NOT go idle without calling TaskUpdate.\nIf you receive a shutdown_request message, respond: SendMessage(type: 'shutdown_response', request_id: '<requestId>', approve: true).")
+   ```
+6. Poll TaskList until task 2 completed → Read result from TaskGet(task-2-id) → Call `TeamDelete`. Optionally send `shutdown_request` as best-effort, but do NOT wait for `shutdown_response`.
+
+## Guided Pipeline (score 3-4)
+
+2 teammates in parallel + 1 after approval — lightweight design path for small but non-trivial tasks:
+
+1. `TeamCreate(team_name: "legion-guided-{timestamp}")`
+2. Create tasks (save returned IDs):
+   - Task 1: "Collect project context" → Memory
    - Task 2: "Design solution" → Architect (blockedBy: Task 1)
    - Task 3: "Execute implementation" → Implementer (blockedBy: Task 2)
 3. Spawn 2 teammates **in parallel** — include task IDs in prompts:
    ```
-   Agent(team_name: ..., name: "context-curator", subagent_type: "context-curator",
+   Agent(team_name: ..., name: "memory", subagent_type: "memory",
         prompt: "## Assignment\n**Task**: <task>\n**Team**: <team-name>\n**Your task ID**: <task-1-id>\n\nCollect project context. Write Bundle Section 3 following the ## Bundle Section 3: Project Context schema (Identity, Rules & Conventions, Build/Run/Test, Code Style, Config & Environment, Key Constraints). CRITICAL: MUST NOT exceed 400 lines.\n\n## End of Work Protocol (MANDATORY)\n1. TaskUpdate(taskId: '<task-1-id>', status: 'completed', description: '<Bundle Section 3>')\n2. SendMessage(type: 'message', recipient: 'architect', content: '<Bundle Section 3>', summary: 'Bundle Section 3 ready')\nBoth steps REQUIRED.\nIf you receive a shutdown_request message, respond: SendMessage(type: 'shutdown_response', request_id: '<requestId>', approve: true).")
 
    Agent(team_name: ..., name: "architect", subagent_type: "architect",
-        prompt: "## Assignment\n**Task**: <task>\n**Team**: <team-name>\n**Your task ID**: <task-2-id>\n\nWait for Bundle Section 3 from context-curator via SendMessage. Then write Bundle Sections 1+2 combined (Architecture + Code Analysis, budget: 300-600 lines) following the schemas:\n- ## Bundle Sections 1+2: Architecture + Code Analysis\n- Subsections: 1.1 Approach, 1.2 Change Boundaries, 1.3 Architecture Decisions, 2.1 Entry Points, 2.2 Files to Change, 2.3 Risks\n\nAND produce a lightweight Execution Pack (Plan + Diff + Acceptance Criteria + Rollback). Write both as your task output via TaskUpdate.\n\n## End of Work Protocol (MANDATORY)\nTaskUpdate(taskId: '<task-2-id>', status: 'completed', description: '<Bundle Sections 1+2 + Execution Pack>')\nDo NOT go idle without calling TaskUpdate.\nIf you receive a shutdown_request message, respond: SendMessage(type: 'shutdown_response', request_id: '<requestId>', approve: true).")
+        prompt: "## Assignment\n**Task**: <task>\n**Team**: <team-name>\n**Your task ID**: <task-2-id>\n\nWait for Bundle Section 3 from memory via SendMessage. Then write Bundle Sections 1+2 combined (Architecture + Code Analysis, budget: 300-600 lines) following the schemas:\n- ## Bundle Sections 1+2: Architecture + Code Analysis\n- Subsections: 1.1 Approach, 1.2 Change Boundaries, 1.3 Architecture Decisions, 2.1 Entry Points, 2.2 Files to Change, 2.3 Risks\n\nAND produce a lightweight Execution Pack (Plan + Diff + Acceptance Criteria + Rollback). Write both as your task output via TaskUpdate.\n\n## End of Work Protocol (MANDATORY)\nTaskUpdate(taskId: '<task-2-id>', status: 'completed', description: '<Bundle Sections 1+2 + Execution Pack>')\nDo NOT go idle without calling TaskUpdate.\nIf you receive a shutdown_request message, respond: SendMessage(type: 'shutdown_response', request_id: '<requestId>', approve: true).")
    ```
-4. Context Curator collects context → writes Bundle Section 3 to task via TaskUpdate → sends to Architect via SendMessage
+4. Memory collects context → writes Bundle Section 3 to task via TaskUpdate → sends to Architect via SendMessage
 5. Architect receives Bundle Section 3 → writes Bundle Sections 1+2 + Execution Pack to task via TaskUpdate
 6. Poll TaskList until tasks 1 and 2 completed → Read Execution Pack from TaskGet(task-2-id)
 7. **Show plan to user and get approval** — extract only the `## Plan` section from the Execution Pack. Present it to the user via AskUserQuestion. If user approves, proceed. If user requests edits, incorporate them. **You MUST spawn the Implementer — do NOT implement yourself.**
@@ -140,17 +164,16 @@ Cap at 10.
 
 ## Cycle Pipeline (score 7-10)
 
-6 teammates — full pipeline for complex tasks:
+5 teammates — full pipeline for complex tasks:
 
 **Phase 1 — Parallel Analysis** (3 teammates write Bundle Sections):
 1. `TeamCreate(team_name: "legion-cycle-{timestamp}")`
 2. Create tasks (save the returned task IDs — you'll need them for spawn prompts):
    - Task 1: "Architectural analysis" → Architect
    - Task 2: "Code analysis" → Code Analyst
-   - Task 3: "Context collection" → Context Curator
+   - Task 3: "Context collection" → Memory
    - Task 4: "Create implementation plan" → Planner (blockedBy: 1, 2, 3)
    - Task 5: "Execute implementation" → Implementer (blockedBy: 4)
-   - Task 6: "Store analysis in memory" → Memory (blockedBy: 1, 2)
 3. Spawn 3 teammates **in parallel** — each prompt MUST include task, team name, task ID, and Bundle Section instruction:
    ```
    Agent(team_name: ..., name: "architect", subagent_type: "architect",
@@ -159,25 +182,20 @@ Cap at 10.
    Agent(team_name: ..., name: "code-analyst", subagent_type: "code-analyst",
         prompt: "## Assignment\n**Task**: <task>\n**Team**: <team-name>\n**Your task ID**: <task-2-id>\n\nAnalyze codebase for this task. Write Bundle Section 2 following the ## Bundle Section 2: Code Analysis schema. CRITICAL: MUST NOT exceed 600 lines.\n\n## End of Work Protocol (MANDATORY)\nTaskUpdate(taskId: '<task-2-id>', status: 'completed', description: '<Bundle Section 2>')\nDo NOT go idle without calling TaskUpdate.\nIf you receive a shutdown_request message, respond: SendMessage(type: 'shutdown_response', request_id: '<requestId>', approve: true).")
 
-   Agent(team_name: ..., name: "context-curator", subagent_type: "context-curator",
+   Agent(team_name: ..., name: "memory", subagent_type: "memory",
         prompt: "## Assignment\n**Task**: <task>\n**Team**: <team-name>\n**Your task ID**: <task-3-id>\n\nCollect project context. Write Bundle Section 3 following the ## Bundle Section 3: Project Context schema. CRITICAL: MUST NOT exceed 400 lines.\n\n## End of Work Protocol (MANDATORY)\nTaskUpdate(taskId: '<task-3-id>', status: 'completed', description: '<Bundle Section 3>')\nDo NOT go idle without calling TaskUpdate.\nIf you receive a shutdown_request message, respond: SendMessage(type: 'shutdown_response', request_id: '<requestId>', approve: true).")
    ```
 4. Wait for all 3 to complete — poll `TaskList` until tasks 1, 2, 3 are all `status: "completed"`
 
-**Phase 2 — Plan + Memory** (Planner assembles Bundle + produces Execution Pack; Memory stores analysis):
-5. Spawn Planner AND Memory in parallel — Planner with Phase 1 Bundle Section task IDs and task 4's ID; Memory with task IDs 1, 2 and task 6's ID (fire-and-forget, does NOT block Implementer):
+**Phase 2 — Planning** (Planner assembles Bundle + produces Execution Pack):
+5. Spawn Planner — with Phase 1 Bundle Section task IDs and task 4's ID:
 
    Spawn Planner:
    ```
    Agent(team_name: ..., name: "planner", subagent_type: "planner",
-        prompt: "## Assignment\n**Team**: <team-name>\n**Your task ID**: <task-4-id>\n\n## Task\n<the user's original request>\n\n## Phase 1 Bundle Section Task IDs\nRead each Bundle Section using TaskGet(taskId) — the section is in the task's `description` field. Each section starts with `## Bundle Section N:`.\n- **Architect (Bundle Section 1)**: TaskGet('<task-1-id>')\n- **Code Analyst (Bundle Section 2)**: TaskGet('<task-2-id>')\n- **Context Curator (Bundle Section 3)**: TaskGet('<task-3-id>')\n\nRead all three Bundle Sections, assemble the Bundle, then produce an Execution Pack with sub-tasks, pseudo-diffs, acceptance criteria, risks, and rollback. Use ToolSearch('+legion-sequential-thinking') and ToolSearch('+legion-memory') before plan construction. Read Infrastructure Notes sections (§1.6, §2.7) from Bundle Sections. Query mcp__legion-memory__read_graph for cross-session context. If legion-memory MCP is unavailable, proceed without. Include User Questions section (≤3) only if critical clarifications are needed.\n\n## End of Work Protocol (MANDATORY)\nTaskUpdate(taskId: '<task-4-id>', status: 'completed', description: '<your full Execution Pack>')\nIf you have user questions, also: SendMessage(type: 'message', recipient: 'legion-orchestrator', content: '<questions>', summary: 'Clarifying questions for user')\nDo NOT go idle without calling TaskUpdate.\nIf you receive a shutdown_request message, respond: SendMessage(type: 'shutdown_response', request_id: '<requestId>', approve: true).")
-   ```
-   Spawn Memory (fire-and-forget):
-   ```
-   Agent(team_name: ..., name: "memory", subagent_type: "general-purpose", model: "haiku",
-        prompt: "## Assignment\n**Team**: <team-name>\n**Your task ID**: <task-6-id>\n\n## Phase 1 Bundle Section Task IDs\nRead Bundle Sections 1 and 2 using TaskGet(taskId) — the section is in the task's `description` field.\n- **Architect (Bundle Section 1)**: TaskGet('<task-1-id>')\n- **Code Analyst (Bundle Section 2)**: TaskGet('<task-2-id>')\n\nLoad MCP tools first: ToolSearch(\"+legion-memory\"). Then extract key findings and store them in project memory via MCP legion-memory server. Pay special attention to Infrastructure Notes (§1.6, §2.7) — store these as separate named entities using mcp__legion-memory__create_entities and mcp__legion-memory__add_observations. If MCP is unavailable, note the error and complete anyway.\n\n## End of Work Protocol (MANDATORY)\nTaskUpdate(taskId: '<task-6-id>', status: 'completed', description: '<summary of stored memories>')\nDo NOT go idle without calling TaskUpdate.\nIf you receive a shutdown_request message, respond: SendMessage(type: 'shutdown_response', request_id: '<requestId>', approve: true).")
+        prompt: "## Assignment\n**Team**: <team-name>\n**Your task ID**: <task-4-id>\n\n## Task\n<the user's original request>\n\n## Phase 1 Bundle Section Task IDs\nRead each Bundle Section using TaskGet(taskId) — the section is in the task's `description` field. Each section starts with `## Bundle Section N:`.\n- **Architect (Bundle Section 1)**: TaskGet('<task-1-id>')\n- **Code Analyst (Bundle Section 2)**: TaskGet('<task-2-id>')\n- **Memory (Bundle Section 3)**: TaskGet('<task-3-id>')\n\nRead all three Bundle Sections, assemble the Bundle, then produce an Execution Pack with sub-tasks, pseudo-diffs, acceptance criteria, risks, and rollback. Use ToolSearch('+legion-sequential-thinking') before plan construction. Read Infrastructure Notes sections (§1.6, §2.7) from Bundle Sections. If MCP is unavailable, proceed without. Include User Questions section (≤3) only if critical clarifications are needed.\n\n## End of Work Protocol (MANDATORY)\nTaskUpdate(taskId: '<task-4-id>', status: 'completed', description: '<your full Execution Pack>')\nIf you have user questions, also: SendMessage(type: 'message', recipient: 'legion-orchestrator', content: '<questions>', summary: 'Clarifying questions for user')\nDo NOT go idle without calling TaskUpdate.\nIf you receive a shutdown_request message, respond: SendMessage(type: 'shutdown_response', request_id: '<requestId>', approve: true).")
    ```
-6. Wait for plan — poll `TaskList` until tasks 4 and 6 are `status: "completed"`
+6. Wait for plan — poll `TaskList` until task 4 is `status: "completed"`
 
 **Phase 2.5 — Q&A** (conditional):
 7. Check SendMessage inbox for questions from Planner. If Planner sent questions:
@@ -200,14 +218,14 @@ Cap at 10.
 10. Wait for implementation — poll `TaskList` until task 5 is `status: "completed"`
 11. Read final report from `TaskGet(task-5-id).description` → Call `TeamDelete`. Optionally send `shutdown_request` as best-effort, but do NOT wait for `shutdown_response`.
 
-## Partial Pipeline (score 4-6)
+## Partial Pipeline (score 5-6)
 
-Default to **quick**. Escalate to **cycle** if:
+Default to **guided**. Escalate to **cycle** if:
 - Architect reports task is more complex than expected
 - Multiple module boundaries discovered
 - Changes needed in 5+ files
 
-Escalation: shutdown quick team → create cycle team → run full pipeline.
+Escalation: shutdown guided team → create cycle team → run full pipeline.
 
 ## Subagent Type Reference
 
@@ -220,7 +238,7 @@ Escalation: shutdown quick team → create cycle team → run full pipeline.
 **Model assignment for subagents**:
 - `model: "opus"` — Architect, Implementer (heavy reasoning, code writing)
 - `model: "sonnet"` — Orchestrator, Planner, Code Analyst, general-purpose agents
-- `model: "haiku"` — Context Curator, Explore subagents (fast, read-only)
+- `model: "haiku"` — Memory, Explore subagents (fast, read-only)
 
 **Subagent spawn examples**:
 
@@ -282,7 +300,7 @@ Spawn subagents using the **Agent** tool:
 |------|-------|----------|
 | `architect` | All tools | Architectural analysis phase |
 | `code-analyst` | All tools | Code analysis phase |
-| `context-curator` | All tools | Context collection phase |
+| `memory` | All tools | Context collection phase |
 | `planner` | All tools | Implementation planning phase |
 | `implementer` | All tools | Plan execution phase |
 | `Explore` | Read, Glob, Grep (read-only) | Quick codebase exploration before scoring |
@@ -337,12 +355,12 @@ If MCP servers are available in the project:
 **Example: Quick Pipeline Communication**
 ```
 // Phase 1: Create tasks for 3 agents (save IDs!)
-Task1 = TaskCreate(name: "context-curation", blockedBy: [])
+Task1 = TaskCreate(name: "context-collection", blockedBy: [])
 Task2 = TaskCreate(name: "design-solution", blockedBy: [Task1])
 Task3 = TaskCreate(name: "execute-implementation", blockedBy: [Task2])
 
 // Phase 2: Spawn 2 agents with task IDs in prompts
-Agent(name: "context-curator", subagent_type: "context-curator",
+Agent(name: "memory", subagent_type: "memory",
   prompt: "...Write Bundle Section 3 (## Bundle Section 3: Project Context). CRITICAL: ≤400 lines.\n1. TaskUpdate(taskId: '" + Task1.id + "', status: 'completed', description: '<Bundle Section 3>')\n2. SendMessage(type: 'message', recipient: 'architect', content: '<Bundle Section 3>', summary: 'Bundle Section 3 ready')")
 Agent(name: "architect", subagent_type: "architect",
   prompt: "...Wait for Bundle Section 3 via SendMessage, then write Bundle Sections 1+2 combined (300-600 lines) + lightweight Execution Pack. TaskUpdate(taskId: '" + Task2.id + "', status: 'completed', description: '<Bundle §1+2 + Execution Pack>')")
@@ -364,30 +382,27 @@ result = TaskGet(Task3.id).description
 
 **Example: Cycle Pipeline Team Coordination**
 ```
-// Create 6-task pipeline with dependencies (save returned IDs!)
+// Create 5-task pipeline with dependencies (save returned IDs!)
 t1 = TaskCreate(name: "arch-analysis", blockedBy: [])
 t2 = TaskCreate(name: "code-analysis", blockedBy: [])
 t3 = TaskCreate(name: "context-collection", blockedBy: [])
 t4 = TaskCreate(name: "planning", blockedBy: [t1, t2, t3])
 t5 = TaskCreate(name: "implementation", blockedBy: [t4])
-t6 = TaskCreate(name: "memory-storage", blockedBy: [t1, t2])
 
 // Spawn Phase 1 agents (3 parallel) — each writes a Bundle Section!
 Agent(..., name: "architect", subagent_type: "architect",
   prompt: "...Write Bundle Section 1 (## Bundle Section 1: Architecture). CRITICAL: ≤400 lines...\nTaskUpdate(taskId: '" + t1.id + "', status: 'completed', description: '<Bundle Section 1>')")
 Agent(..., name: "code-analyst", subagent_type: "code-analyst",
   prompt: "...Write Bundle Section 2 (## Bundle Section 2: Code Analysis). CRITICAL: ≤600 lines...\nTaskUpdate(taskId: '" + t2.id + "', status: 'completed', description: '<Bundle Section 2>')")
-Agent(..., name: "context-curator", subagent_type: "context-curator",
+Agent(..., name: "memory", subagent_type: "memory",
   prompt: "...Write Bundle Section 3 (## Bundle Section 3: Project Context). CRITICAL: ≤400 lines...\nTaskUpdate(taskId: '" + t3.id + "', status: 'completed', description: '<Bundle Section 3>')")
 
 // Wait for all 3 to complete — poll TaskList
 while not all [t1, t2, t3] completed: check TaskList()
 
-// Spawn Planner AND Memory in parallel (Phase 2)
-Agent(..., name: "planner", prompt: "## Assignment\n**Your task ID**: " + t4.id + "\n\n## Task\n<the user's original request>\n\n## Phase 1 Bundle Section Task IDs\nRead each Bundle Section using TaskGet(taskId). Each starts with ## Bundle Section N:.\n- Architect (§1): TaskGet('" + t1.id + "')\n- Code Analyst (§2): TaskGet('" + t2.id + "')\n- Context Curator (§3): TaskGet('" + t3.id + "')\n\nAssemble Bundle, produce Execution Pack with optional user questions (≤3).\n\n## End of Work Protocol\nTaskUpdate(taskId: '" + t4.id + "', ...)\nIf you receive a shutdown_request message, respond: SendMessage(type: 'shutdown_response', request_id: '<requestId>', approve: true).")
+// Spawn Planner (Phase 2)
+Agent(..., name: "planner", prompt: "## Assignment\n**Your task ID**: " + t4.id + "\n\n## Task\n<the user's original request>\n\n## Phase 1 Bundle Section Task IDs\nRead each Bundle Section using TaskGet(taskId). Each starts with ## Bundle Section N:.\n- Architect (§1): TaskGet('" + t1.id + "')\n- Code Analyst (§2): TaskGet('" + t2.id + "')\n- Memory (§3): TaskGet('" + t3.id + "')\n\nAssemble Bundle, produce Execution Pack with optional user questions (≤3).\n\n## End of Work Protocol\nTaskUpdate(taskId: '" + t4.id + "', ...)\nIf you receive a shutdown_request message, respond: SendMessage(type: 'shutdown_response', request_id: '<requestId>', approve: true).")
 
-Agent(..., name: "memory", subagent_type: "general-purpose", model: "haiku",
-  prompt: "## Assignment\n**Your task ID**: " + t6.id + "\n\n## Phase 1 Bundle Section Task IDs\n- Architect (§1): TaskGet('" + t1.id + "')\n- Code Analyst (§2): TaskGet('" + t2.id + "')\n\nExtract key findings and store in project memory via MCP legion-memory server.\n\n## End of Work Protocol\nTaskUpdate(taskId: '" + t6.id + "', ...)\nIf you receive a shutdown_request message, respond: SendMessage(type: 'shutdown_response', request_id: '<requestId>', approve: true).")
 
 // Phase 2.5: Check for Planner questions → AskUserQuestion if present
 
@@ -412,10 +427,10 @@ Agent(..., name: "implementer", prompt: "## Assignment\n**Your task ID**: " + t5
 
 - You are a COORDINATOR, not an executor
 - Always score complexity before selecting pipeline
-- If unsure about complexity, **default UP** — quick→cycle is cheaper than cycle→failed quick
-- Never skip the analysis phase — even quick pipeline gets context
+- If unsure about complexity, **default UP** — direct→guided→cycle is cheaper than a failed under-scoped run
+- Never skip the analysis phase — even direct pipeline gets context
 - If a teammate fails, report the failure and decide: retry, escalate, or abort
-- After plan approval (including user edits), you MUST spawn the Implementer agent. You MUST NOT implement changes yourself — not in quick pipeline, not in cycle pipeline, not after user edits.
+- After plan approval (including user edits), you MUST spawn the Implementer agent. You MUST NOT implement changes yourself — not in guided pipeline, not in cycle pipeline, not after user edits.
 - If unsure, say "я не знаю" and ask the user
 
 ### Mailbox and Task Management Rules