@ngxtm/devkit 3.18.0 → 3.20.0

package/merged-commands/incident-response-incident-response.md

@@ -45,19 +45,19 @@ Orchestrate multi-agent incident response with modern SRE practices for rapid re
 ## Phase 1: Detection & Triage
 
 ### 1. Incident Detection and Classification
-- Use Task tool with subagent_type="incident-responder"
+- Use Task tool with subagent_type="general-purpose"
 - Prompt: "URGENT: Detect and classify incident: $ARGUMENTS. Analyze alerts from PagerDuty/Opsgenie/monitoring. Determine: 1) Incident severity (P0-P3), 2) Affected services and dependencies, 3) User impact and business risk, 4) Initial incident command structure needed. Check error budgets and SLO violations."
 - Output: Severity classification, impact assessment, incident command assignments, SLO status
 - Context: Initial alerts, monitoring dashboards, recent changes
 
 ### 2. Observability Analysis
-- Use Task tool with subagent_type="observability-monitoring::observability-engineer"
+- Use Task tool with subagent_type="general-purpose"
 - Prompt: "Perform rapid observability sweep for incident: $ARGUMENTS. Query: 1) Distributed tracing (OpenTelemetry/Jaeger), 2) Metrics correlation (Prometheus/Grafana/DataDog), 3) Log aggregation (ELK/Splunk), 4) APM data, 5) Real User Monitoring. Identify anomalies, error patterns, and service degradation points."
 - Output: Observability findings, anomaly detection, service health matrix, trace analysis
 - Context: Severity level from step 1, affected services
 
 ### 3. Initial Mitigation
-- Use Task tool with subagent_type="incident-responder"
+- Use Task tool with subagent_type="general-purpose"
 - Prompt: "Implement immediate mitigation for P$SEVERITY incident: $ARGUMENTS. Actions: 1) Traffic throttling/rerouting if needed, 2) Feature flag disabling for affected features, 3) Circuit breaker activation, 4) Rollback assessment for recent deployments, 5) Scale resources if capacity-related. Prioritize user experience restoration."
 - Output: Mitigation actions taken, temporary fixes applied, rollback decisions
 - Context: Observability findings, severity classification
@@ -65,19 +65,19 @@ Orchestrate multi-agent incident response with modern SRE practices for rapid re
 ## Phase 2: Investigation & Root Cause Analysis
 
 ### 4. Deep System Debugging
-- Use Task tool with subagent_type="error-debugging::debugger"
+- Use Task tool with subagent_type="general-purpose"
 - Prompt: "Conduct deep debugging for incident: $ARGUMENTS using observability data. Investigate: 1) Stack traces and error logs, 2) Database query performance and locks, 3) Network latency and timeouts, 4) Memory leaks and CPU spikes, 5) Dependency failures and cascading errors. Apply Five Whys analysis."
 - Output: Root cause identification, contributing factors, dependency impact map
 - Context: Observability analysis, mitigation status
 
 ### 5. Security Assessment
-- Use Task tool with subagent_type="security-scanning::security-auditor"
+- Use Task tool with subagent_type="general-purpose"
 - Prompt: "Assess security implications of incident: $ARGUMENTS. Check: 1) DDoS attack indicators, 2) Authentication/authorization failures, 3) Data exposure risks, 4) Certificate issues, 5) Suspicious access patterns. Review WAF logs, security groups, and audit trails."
 - Output: Security assessment, breach analysis, vulnerability identification
 - Context: Root cause findings, system logs
 
 ### 6. Performance Engineering Analysis
-- Use Task tool with subagent_type="application-performance::performance-engineer"
+- Use Task tool with subagent_type="general-purpose"
 - Prompt: "Analyze performance aspects of incident: $ARGUMENTS. Examine: 1) Resource utilization patterns, 2) Query optimization opportunities, 3) Caching effectiveness, 4) Load balancer health, 5) CDN performance, 6) Autoscaling triggers. Identify bottlenecks and capacity issues."
 - Output: Performance bottlenecks, resource recommendations, optimization opportunities
 - Context: Debug findings, current mitigation state
@@ -85,13 +85,13 @@ Orchestrate multi-agent incident response with modern SRE practices for rapid re
 ## Phase 3: Resolution & Recovery
 
 ### 7. Fix Implementation
-- Use Task tool with subagent_type="backend-development::backend-architect"
+- Use Task tool with subagent_type="general-purpose"
 - Prompt: "Design and implement production fix for incident: $ARGUMENTS based on root cause. Requirements: 1) Minimal viable fix for rapid deployment, 2) Risk assessment and rollback capability, 3) Staged rollout plan with monitoring, 4) Validation criteria and health checks. Consider both immediate fix and long-term solution."
 - Output: Fix implementation, deployment strategy, validation plan, rollback procedures
 - Context: Root cause analysis, performance findings, security assessment
 
 ### 8. Deployment and Validation
-- Use Task tool with subagent_type="deployment-strategies::deployment-engineer"
+- Use Task tool with subagent_type="general-purpose"
 - Prompt: "Execute emergency deployment for incident fix: $ARGUMENTS. Process: 1) Blue-green or canary deployment, 2) Progressive rollout with monitoring, 3) Health check validation at each stage, 4) Rollback triggers configured, 5) Real-time monitoring during deployment. Coordinate with incident command."
 - Output: Deployment status, validation results, monitoring dashboard, rollback readiness
 - Context: Fix implementation, current system state
@@ -99,13 +99,13 @@ Orchestrate multi-agent incident response with modern SRE practices for rapid re
 ## Phase 4: Communication & Coordination
 
 ### 9. Stakeholder Communication
-- Use Task tool with subagent_type="content-marketing::content-marketer"
+- Use Task tool with subagent_type="general-purpose"
 - Prompt: "Manage incident communication for: $ARGUMENTS. Create: 1) Status page updates (public-facing), 2) Internal engineering updates (technical details), 3) Executive summary (business impact/ETA), 4) Customer support briefing (talking points), 5) Timeline documentation with key decisions. Update every 15-30 minutes based on severity."
 - Output: Communication artifacts, status updates, stakeholder briefings, timeline log
 - Context: All previous phases, current resolution status
 
 ### 10. Customer Impact Assessment
-- Use Task tool with subagent_type="incident-responder"
+- Use Task tool with subagent_type="general-purpose"
 - Prompt: "Assess and document customer impact for incident: $ARGUMENTS. Analyze: 1) Affected user segments and geography, 2) Failed transactions or data loss, 3) SLA violations and contractual implications, 4) Customer support ticket volume, 5) Revenue impact estimation. Prepare proactive customer outreach list."
 - Output: Customer impact report, SLA analysis, outreach recommendations
 - Context: Resolution progress, communication status
@@ -113,19 +113,19 @@ Orchestrate multi-agent incident response with modern SRE practices for rapid re
 ## Phase 5: Postmortem & Prevention
 
 ### 11. Blameless Postmortem
-- Use Task tool with subagent_type="documentation-generation::docs-architect"
+- Use Task tool with subagent_type="general-purpose"
 - Prompt: "Conduct blameless postmortem for incident: $ARGUMENTS. Document: 1) Complete incident timeline with decisions, 2) Root cause and contributing factors (systems focus), 3) What went well in response, 4) What could improve, 5) Action items with owners and deadlines, 6) Lessons learned for team education. Follow SRE postmortem best practices."
 - Output: Postmortem document, action items list, process improvements, training needs
 - Context: Complete incident history, all agent outputs
 
 ### 12. Monitoring and Alert Enhancement
-- Use Task tool with subagent_type="observability-monitoring::observability-engineer"
+- Use Task tool with subagent_type="general-purpose"
 - Prompt: "Enhance monitoring to prevent recurrence of: $ARGUMENTS. Implement: 1) New alerts for early detection, 2) SLI/SLO adjustments if needed, 3) Dashboard improvements for visibility, 4) Runbook automation opportunities, 5) Chaos engineering scenarios for testing. Ensure alerts are actionable and reduce noise."
 - Output: New monitoring configuration, alert rules, dashboard updates, runbook automation
 - Context: Postmortem findings, root cause analysis
 
 ### 13. System Hardening
-- Use Task tool with subagent_type="backend-development::backend-architect"
+- Use Task tool with subagent_type="general-purpose"
 - Prompt: "Design system improvements to prevent incident: $ARGUMENTS. Propose: 1) Architecture changes for resilience (circuit breakers, bulkheads), 2) Graceful degradation strategies, 3) Capacity planning adjustments, 4) Technical debt prioritization, 5) Dependency reduction opportunities. Create implementation roadmap."
 - Output: Architecture improvements, resilience patterns, technical debt items, roadmap
 - Context: Postmortem action items, performance analysis

package/merged-commands/integrate/polar.md

@@ -5,7 +5,7 @@ argument-hint: [tasks]
 
 Think harder.
 Activate `payment-integration` skill.
-Plan & start implementing payment integration with [Polar.sh](https://polar.sh/docs/llms-full.txt) follow the Orchestration Protocol, Core Responsibilities, Subagents Team and Development Rules: 
+Plan & start implementing payment integration with [Polar.sh](https://polar.sh/docs/llms-full.txt) follow the Orchestration Protocol, Core Responsibilities, and Development Rules:
 <tasks>$ARGUMENTS</tasks>
 
 ---
@@ -23,6 +23,6 @@ Plan & start implementing payment integration with [Polar.sh](https://polar.sh/d
 
 ## Workflow:
 
-- **Scout**: Use `scout` subagent to find related resources, documents, and code snippets in the current codebase.
-- **Plan**: Trigger slash command `/plan:fast <detailed-instruction-prompt>` to create an implementation plan based on the reports from `scout` subagent.
+- **Scout**: Use Task agent for scouting to find related resources, documents, and code snippets in the current codebase: Task(subagent_type="general-purpose", prompt="You are a scout. Find related resources...", description="Scout codebase")
+- **Plan**: Trigger slash command `/plan:fast <detailed-instruction-prompt>` to create an implementation plan based on the reports from Task agent.
 - **Implementation**: Trigger slash command `/code <plan>` to implement the plan.

package/merged-commands/integrate/sepay.md

@@ -5,7 +5,7 @@ argument-hint: [tasks]
 
 Think harder.
 Activate `payment-integration` skill.
-Plan & start implementing payment integration with [https://developer.sepay.vn/vi](https://developer.sepay.vn/vi) follow the Orchestration Protocol, Core Responsibilities, Subagents Team and Development Rules: 
+Plan & start implementing payment integration with [https://developer.sepay.vn/vi](https://developer.sepay.vn/vi) follow the Orchestration Protocol, Core Responsibilities, and Development Rules:
 <tasks>$ARGUMENTS</tasks>
 
 ---
@@ -23,6 +23,6 @@ Plan & start implementing payment integration with [https://developer.sepay.vn/v
 
 ## Workflow:
 
-- **Scout**: Use `scout` subagent to find related resources, documents, and code snippets in the current codebase.
-- **Plan**: Trigger slash command `/plan:fast <detailed-instruction-prompt>` to create an implementation plan based on the reports from `scout` subagent.
+- **Scout**: Use Task agent for scouting to find related resources, documents, and code snippets in the current codebase: Task(subagent_type="general-purpose", prompt="You are a scout. Find related resources...", description="Scout codebase")
+- **Plan**: Trigger slash command `/plan:fast <detailed-instruction-prompt>` to create an implementation plan based on the reports from Task agent.
 - **Implementation**: Trigger slash command `/code <plan>` to implement the plan.

package/merged-commands/journal.md

@@ -2,6 +2,6 @@
 description: ⚡ Write some journal entries.
 ---
 
-Use the `journal-writer` subagent to explore the memories and recent code changes, and write some journal entries.
+Use a Task agent for journal writing to explore the memories and recent code changes, and write some journal entries: Task(subagent_type="general-purpose", prompt="You are a journal-writer. Explore memories and recent code changes, write journal entries...", description="Write journal entries")
 Journal entries should be concise and focused on the most important events, key changes, impacts, and decisions.
 Keep journal entries in the `./docs/journals/` directory.

package/merged-commands/learn.md

@@ -1,16 +1,21 @@
 ---
 name: learn
 description: Guided project building — you code, AI mentors. Build your own product step-by-step with best practices and deep understanding.
-argument-hint: [topic]
+argument-hint: [topic] [--plan <path>]
 ---
 
-# Learn Mode v3.1
+# Learn Mode v3.2
 
 > Build your product. Design the architecture. Write every line. Understand every decision.
 
 ## Activation
 
 `/learn "topic"` — e.g., `/learn "JWT auth in Express"`, `/learn "build real-time chat"`
+`/learn --plan <path>` — Learn by following an existing plan (topic auto-extracted from plan title)
+`/learn "topic" --plan <path>` — Learn with custom topic + existing plan
+
+e.g., `/learn --plan plans/skill-sync-rewrite/plan.md`
+e.g., `/learn "upstream sync" --plan plans/skill-sync-rewrite/plan.md`
 
 ---
 
@@ -18,7 +23,17 @@ argument-hint: [topic]
 
 1. **Resume check**: Look in `learn/` for existing file matching topic. If found, read its YAML frontmatter and offer to resume from last checkpoint via `AskUserQuestion`.
 
-2. **Language detection**: Scan project for config files to identify primary language.
+2. **Plan import check**: If arguments contain `--plan <path>`:
+   a. Read the plan file at `<path>`. Validate it exists and has content.
+   b. **Topic resolution**: If no topic provided in arguments, extract from plan's YAML frontmatter `title` field.
+   c. Detect plan structure:
+      - **Single-file plan**: no `phase-XX` files referenced → tasks = plan's task list
+      - **Multi-phase plan**: has `## Phases` table with phase-XX links → each phase = potential learn module
+   d. If multi-phase: ask user via `AskUserQuestion` which phase(s) to learn.
+   e. Read selected phase file(s) for detailed tasks.
+   f. Store parsed steps for REVIEW phase.
+
+3. **Language detection** (skip if `--plan` already implies language from plan context): Scan project for config files to identify primary language.
 
 | Language | Config Files | Verify: Syntax | Verify: Run/Test |
 |----------|-------------|----------------|------------------|
@@ -70,6 +85,8 @@ step: 0
 total_steps: 0
 difficulty: {deep|standard|quick}
 teaching: {guided|scaffolded|demonstrated}
+plan_source: "{path or none}"
+plan_type: {single|multi-phase|none}
 started: {ISO timestamp}
 updated: {ISO timestamp}
 ---
@@ -93,9 +110,32 @@ Update frontmatter: `phase: LEARN`
 
 ---
 
+## Phase 3-ALT: REVIEW (only when --plan provided, replaces Phase 3 + 4)
+
+> Understand the plan before building. Light touch — not redesign.
+
+1. **Summarize**: Present plan overview to user:
+   > "This plan proposes: {overview}. It has {N} steps targeting {files}."
+   > Key decisions: {list key decisions from plan}
+
+2. **Socratic check** (skip in Quick difficulty): Ask 1-2 questions via `AskUserQuestion`:
+   > "Before we start — why do you think {first step} comes before {later step}?"
+   > OR "What problem does {key decision} solve?"
+   Build on user's answer. Correct misconceptions if any.
+
+3. **Adapt**: Ask via `AskUserQuestion`:
+   > "Want to reorder, skip, or add any steps? Or proceed as-is?"
+   Adjust step list based on user feedback.
+
+4. **Write to tutorial file**: Record plan source, overview, and adapted steps.
+
+Update frontmatter: `phase: REVIEW`, `total_steps: {N}`
+
+---
+
 ## Phase 3: DESIGN (Socratic architecture thinking)
 
-> User thinks first, AI guides — not the other way around.
+> **Skip this phase entirely if `--plan` was provided.** Go to Phase 3-ALT: REVIEW instead.
 
 1. **Frame the problem**: AI presents the high-level problem to solve:
    > "We need to build {topic}. Before I suggest anything — how would YOU approach this? What components or pieces do you think we need?"
@@ -134,6 +174,8 @@ Update frontmatter: `phase: DESIGN`
 
 ## Phase 4: PLAN (concrete implementation steps)
 
+> **Skip this phase entirely if `--plan` was provided.** Steps come from REVIEW phase instead.
+
 1. **Break down the chosen design** into 3-7 concrete, verifiable steps. Each step should:
    - Have a clear goal (what's done when this step is complete)
    - Build on previous steps (incremental, testable progress)
@@ -155,6 +197,10 @@ Update frontmatter: `phase: PLAN`, `total_steps: {N}`
 
 ## Phase 5: BUILD (core phase)
 
+> If `--plan` was provided, steps come from REVIEW phase (imported plan).
+> If no `--plan`, steps come from Phase 4 (PLAN) as usual.
+> Everything else in BUILD works identically for both paths.
+
 1. **For each step from the PLAN phase, follow the teaching mode**:
 
 ### Guided Mode (user codes everything)
@@ -267,6 +313,7 @@ Display: `Tutorial saved: learn/{filename}.md`
 
 ## Version History
 
+- **3.2.0** - Added --plan flag: import existing plan files, REVIEW phase replaces DESIGN+PLAN for plan-driven learning. Flow with plan: INIT → LEARN → REVIEW → BUILD → WRAP-UP
 - **3.1.0** - Added DESIGN phase (Socratic architecture) and PLAN phase (concrete steps). Full flow: INIT → LEARN → DESIGN → PLAN → BUILD → WRAP-UP
 - **3.0.0** - Teaching modes (guided/scaffolded/demonstrated), best-practice review, explain-back checkpoints, user-codes-first philosophy
 - **2.0.0** - Rewrite: adaptive difficulty via codingLevel, 4 phases, WebSearch, Socratic method, resume support, tiered verify, 17 languages, codebase-aware

package/merged-commands/linear-claude-skill.md

@@ -387,13 +387,13 @@ For detailed helper script usage, see **troubleshooting.md**.
 
 ### Parallel Agent Execution
 
-For bulk operations or background execution, use the `Linear-specialist` subagent:
+For bulk operations or background execution, use the `Linear-specialist` Task agent:
 
 ```javascript
 Task({
   description: "Update Linear issues",
   prompt: "Mark ENG-101, ENG-102, ENG-103 as Done",
-  subagent_type: "Linear-specialist"
+  subagent_type: "general-purpose"
 })
 ```
 

package/merged-commands/loki-mode.md

@@ -137,7 +137,7 @@ If bugs are found in these files, document them in `.loki/CONTINUITY.md` under "
 | - Identify highest priority unblocked task                        |
 +-------------------------------------------------------------------+
 | ACT: Execute the task                                             |
-| - Dispatch subagent via Task tool OR execute directly             |
+| - Dispatch Task agent via Task tool OR execute directly             |
 | - Write code, run tests, fix issues                               |
 | - Commit changes atomically (git checkpoint)                      |
 +-------------------------------------------------------------------+
@@ -175,7 +175,7 @@ If bugs are found in these files, document them in `.loki/CONTINUITY.md` under "
 ### Task Tool Model Parameter
 ```python
 # Opus for planning/architecture ONLY
-Task(subagent_type="Plan", model="opus", description="Design system architecture", prompt="...")
+Task(subagent_type="general-purpose", model="opus", description="Design system architecture", prompt="...")
 
 # Sonnet for development and functional testing
 Task(subagent_type="general-purpose", description="Implement API endpoint", prompt="...")
@@ -286,7 +286,7 @@ Task(description="Refactor database layer for performance", prompt="...")     #
 - **Direct Routing:** Minimal context - just the task and relevant file(s)
 - **Supervisor Mode:** Full context - CONTINUITY.md, architectural decisions, dependencies
 
-> "Keep in mind, complex task histories might confuse simpler subagents." - AWS Best Practices
+> "Keep in mind, complex task histories might confuse simpler Task agents." - AWS Best Practices
 
 ### E2E Testing with Playwright MCP (Anthropic Harness Pattern)
 
@@ -325,7 +325,7 @@ mcp_servers = {
 | Metric | What to Track | Store In |
 |--------|---------------|----------|
 | Wall time | Seconds from start to completion | `.loki/metrics/efficiency/` |
-| Agent count | Number of subagents spawned | `.loki/metrics/efficiency/` |
+| Agent count | Number of Task agents spawned | `.loki/metrics/efficiency/` |
 | Retry count | Attempts before success | `.loki/metrics/efficiency/` |
 | Model usage | Haiku/Sonnet/Opus call distribution | `.loki/metrics/efficiency/` |
 
@@ -351,12 +351,12 @@ See `references/tool-orchestration.md` for full implementation details.
 
 ---
 
-## Structured Prompting for Subagents
+## Structured Prompting for Task Agents
 
 **Single-Responsibility Principle:** Each agent should have ONE clear goal and narrow scope.
 ([UiPath Best Practices](https://www.uipath.com/blog/ai/agent-builder-best-practices))
 
-**Every subagent dispatch MUST include:**
+**Every Task agent dispatch MUST include:**
 
 ```markdown
 ## GOAL (What success looks like)
@@ -446,7 +446,7 @@ See `references/agent-types.md` for complete definitions and capabilities.
 - **NEVER** skip code review between tasks
 - **NEVER** proceed with unfixed Critical/High/Medium issues
 - **NEVER** dispatch reviewers sequentially (always parallel - 3x faster)
-- **NEVER** dispatch multiple implementation subagents in parallel (conflicts)
+- **NEVER** dispatch multiple implementation Task agents in parallel (conflicts)
 - **NEVER** implement without reading task requirements first
 
 ### Review Anti-Patterns
@@ -466,7 +466,7 @@ See `references/agent-types.md` for complete definitions and capabilities.
 - **ALWAYS** wait for all reviewers before aggregating
 - **ALWAYS** fix Critical/High/Medium immediately
 - **ALWAYS** re-run ALL 3 reviewers after fixes
-- **ALWAYS** checkpoint state before spawning subagents
+- **ALWAYS** checkpoint state before spawning Task agents
 
 ---
 
@@ -618,14 +618,14 @@ context_budget:
   reserve: "90% for model reasoning"
 ```
 
-### Sub-Agents for Context Isolation
+### Task Agents for Context Isolation
 
-**Use sub-agents to prevent token waste on noisy subtasks:**
+**Use Task agents to prevent token waste on noisy subtasks:**
 
 ```
-Main agent (focused) --> Sub-agent (file search)
-                     --> Sub-agent (test running)
-                     --> Sub-agent (linting)
+Main agent (focused) --> Task agent (file search)
+                     --> Task agent (test running)
+                     --> Task agent (linting)
 ```
 
 See `references/production-patterns.md` for full practitioner patterns.
@@ -690,7 +690,7 @@ Loki Mode with PRD at path/to/prd   # Start with PRD
 |-------|-------|
 | Trigger | "Loki Mode" or "Loki Mode with PRD at [path]" |
 | Skip When | Need human approval, want to review plan first, single small task |
-| Related Skills | subagent-driven-development, executing-plans |
+| Related Skills | task-agent-driven-development, executing-plans |
 
 ---
 

package/merged-commands/machine-learning-ops-ml-pipeline.md

@@ -46,7 +46,7 @@ The multi-agent approach ensures each aspect is handled by domain experts:
 ## Phase 1: Data & Requirements Analysis
 
 <Task>
-subagent_type: data-engineer
+subagent_type: general-purpose
 prompt: |
   Analyze and design data pipeline for ML system with requirements: $ARGUMENTS
 
@@ -73,7 +73,7 @@ prompt: |
 </Task>
 
 <Task>
-subagent_type: data-scientist
+subagent_type: general-purpose
 prompt: |
   Design feature engineering and model requirements for: $ARGUMENTS
   Using data architecture from: {phase1.data-engineer.output}
@@ -103,7 +103,7 @@ prompt: |
 ## Phase 2: Model Development & Training
 
 <Task>
-subagent_type: ml-engineer
+subagent_type: general-purpose
 prompt: |
   Implement training pipeline based on requirements: {phase1.data-scientist.output}
   Using data pipeline: {phase1.data-engineer.output}
@@ -131,7 +131,7 @@ prompt: |
 </Task>
 
 <Task>
-subagent_type: python-pro
+subagent_type: general-purpose
 prompt: |
   Optimize and productionize ML code from: {phase2.ml-engineer.output}
 
@@ -160,7 +160,7 @@ prompt: |
 ## Phase 3: Production Deployment & Serving
 
 <Task>
-subagent_type: mlops-engineer
+subagent_type: general-purpose
 prompt: |
   Design production deployment for models from: {phase2.ml-engineer.output}
   With optimized code from: {phase2.python-pro.output}
@@ -194,7 +194,7 @@ prompt: |
 </Task>
 
 <Task>
-subagent_type: kubernetes-architect
+subagent_type: general-purpose
 prompt: |
   Design Kubernetes infrastructure for ML workloads from: {phase3.mlops-engineer.output}
 
@@ -223,7 +223,7 @@ prompt: |
 ## Phase 4: Monitoring & Continuous Improvement
 
 <Task>
-subagent_type: observability-engineer
+subagent_type: general-purpose
 prompt: |
   Implement comprehensive monitoring for ML system deployed in: {phase3.mlops-engineer.output}
   Using Kubernetes infrastructure: {phase3.kubernetes-architect.output}

package/merged-commands/mcp-management.md

@@ -15,7 +15,7 @@ MCP is an open protocol enabling AI agents to connect to external tools and data
 - Progressive disclosure of MCP capabilities (load only what's needed)
 - Intelligent tool/prompt/resource selection based on task requirements
 - Multi-server management from single config file
-- Context-efficient: subagents handle MCP discovery and execution
+- Context-efficient: Task agents handle MCP discovery and execution
 - Persistent tool catalog: automatically saves discovered tools to JSON for fast reference
 
 ## When to Use This Skill
@@ -25,7 +25,7 @@ Use this skill when:
 2. **Task-Based Tool Selection**: Analyzing which MCP tools are relevant for a specific task
 3. **Executing MCP Tools**: Calling MCP tools programmatically with proper parameter handling
 4. **MCP Integration**: Building or debugging MCP client implementations
-5. **Context Management**: Avoiding context pollution by delegating MCP operations to subagents
+5. **Context Management**: Avoiding context pollution by delegating MCP operations to Task agents
 
 ## Core Capabilities
 
@@ -80,7 +80,7 @@ echo "Take a screenshot of https://example.com" | gemini -y -m gemini-2.5-flash
 npx tsx scripts/cli.ts call-tool memory create_entities '{"entities":[...]}'
 ```
 
-**Fallback: mcp-manager Subagent**
+**Fallback: mcp-manager Task agent**
 
 See [references/gemini-cli-integration.md](references/gemini-cli-integration.md) for complete examples.
 
@@ -106,14 +106,14 @@ echo "Take a screenshot of https://example.com. Return JSON only per GEMINI.md i
 - Automatic tool discovery
 - Structured JSON responses (parseable by Claude)
 - GEMINI.md auto-loaded for consistent formatting
-- Faster than subagent orchestration
+- Faster than Task agent orchestration
 - No natural language ambiguity
 
 See [references/gemini-cli-integration.md](references/gemini-cli-integration.md) for complete guide.
 
-### Pattern 2: Subagent-Based Execution (Fallback)
+### Pattern 2: Task Agent-Based Execution (Fallback)
 
-Use `mcp-manager` agent when Gemini CLI unavailable. Subagent discovers tools, selects relevant ones, executes tasks, reports back.
+Use `mcp-manager` agent when Gemini CLI unavailable. Task agent discovers tools, selects relevant ones, executes tasks, reports back.
 
 **Benefit**: Main context stays clean, only relevant tool definitions loaded when needed.
 
@@ -166,7 +166,7 @@ npx tsx cli.ts list-tools  # Saves to assets/tools.json
 npx tsx cli.ts call-tool memory create_entities '{"entities":[...]}'
 ```
 
-**Method 3: mcp-manager Subagent**
+**Method 3: mcp-manager Task agent**
 
 See [references/gemini-cli-integration.md](references/gemini-cli-integration.md) for complete guide.
 
@@ -193,7 +193,7 @@ See [references/mcp-protocol.md](references/mcp-protocol.md) for:
    - Use when: Need specific tool/server control
    - Execute: `npx tsx scripts/cli.ts call-tool <server> <tool> <args>`
 
-3. **mcp-manager Subagent** (Fallback): Context-efficient delegation
+3. **mcp-manager Task agent** (Fallback): Context-efficient delegation
    - Use when: Gemini unavailable or failed
    - Keeps main context clean
 

package/merged-commands/multi-agent-patterns.md

@@ -12,7 +12,7 @@ Master orchestrator, peer-to-peer, and hierarchical multi-agent architectures
 Use this skill when working with master orchestrator, peer-to-peer, and hierarchical multi-agent architectures.
 # Multi-Agent Architecture Patterns
 
-Multi-agent architectures distribute work across multiple language model instances, each with its own context window. When designed well, this distribution enables capabilities beyond single-agent limits. When designed poorly, it introduces coordination overhead that negates benefits. The critical insight is that sub-agents exist primarily to isolate context, not to anthropomorphize role division.
+Multi-agent architectures distribute work across multiple language model instances, each with its own context window. When designed well, this distribution enables capabilities beyond single-agent limits. When designed poorly, it introduces coordination overhead that negates benefits. The critical insight is that Task agents exist primarily to isolate context, not to anthropomorphize role division.
 
 ## When to Activate
 
@@ -26,7 +26,7 @@ Activate this skill when:
 
 ## Core Concepts
 
-Multi-agent systems address single-agent context limitations through distribution. Three dominant patterns exist: supervisor/orchestrator for centralized control, peer-to-peer/swarm for flexible handoffs, and hierarchical for layered abstraction. The critical design principle is context isolation—sub-agents exist primarily to partition context rather than to simulate organizational roles.
+Multi-agent systems address single-agent context limitations through distribution. Three dominant patterns exist: supervisor/orchestrator for centralized control, peer-to-peer/swarm for flexible handoffs, and hierarchical for layered abstraction. The critical design principle is context isolation—Task agents exist primarily to partition context rather than to simulate organizational roles.
 
 Effective multi-agent systems require explicit coordination protocols, consensus mechanisms that avoid sycophancy, and careful attention to failure modes including bottlenecks, divergence, and error propagation.
 
@@ -75,20 +75,20 @@ When to use: Complex tasks with clear decomposition, tasks requiring coordinatio
 
 Advantages: Strict control over workflow, easier to implement human-in-the-loop interventions, ensures adherence to predefined plans.
 
-Disadvantages: Supervisor context becomes bottleneck, supervisor failures cascade to all workers, "telephone game" problem where supervisors paraphrase sub-agent responses incorrectly.
+Disadvantages: Supervisor context becomes bottleneck, supervisor failures cascade to all workers, "telephone game" problem where supervisors paraphrase Task agent responses incorrectly.
 
 **The Telephone Game Problem and Solution**
-LangGraph benchmarks found supervisor architectures initially performed 50% worse than optimized versions due to the "telephone game" problem where supervisors paraphrase sub-agent responses incorrectly, losing fidelity.
+LangGraph benchmarks found supervisor architectures initially performed 50% worse than optimized versions due to the "telephone game" problem where supervisors paraphrase Task agent responses incorrectly, losing fidelity.
 
-The fix: implement a `forward_message` tool allowing sub-agents to pass responses directly to users:
+The fix: implement a `forward_message` tool allowing Task agents to pass responses directly to users:
 
 ```python
 def forward_message(message: str, to_user: bool = True):
     """
-    Forward sub-agent response directly to user without supervisor synthesis.
-    
+    Forward Task agent response directly to user without supervisor synthesis.
+
     Use when:
-    - Sub-agent response is final and complete
+    - Task agent response is final and complete
     - Supervisor synthesis would lose important details
     - Response format must be preserved exactly
     """
@@ -97,9 +97,9 @@ def forward_message(message: str, to_user: bool = True):
     return {"type": "supervisor_input", "content": message}
 ```
 
-With this pattern, swarm architectures slightly outperform supervisors because sub-agents respond directly to users, eliminating translation errors.
+With this pattern, swarm architectures slightly outperform supervisors because Task agents respond directly to users, eliminating translation errors.
 
-Implementation note: Implement direct pass-through mechanisms allowing sub-agents to pass responses directly to users rather than through supervisor synthesis when appropriate.
+Implementation note: Implement direct pass-through mechanisms allowing Task agents to pass responses directly to users rather than through supervisor synthesis when appropriate.
 
 **Pattern 2: Peer-to-Peer/Swarm**
 The peer-to-peer pattern removes central control, allowing agents to communicate directly based on predefined protocols. Any agent can transfer control to any other through explicit handoff mechanisms.
@@ -137,17 +137,17 @@ Disadvantages: Coordination overhead between layers, potential for misalignment
 
 ### Context Isolation as Design Principle
 
-The primary purpose of multi-agent architectures is context isolation. Each sub-agent operates in a clean context window focused on its subtask without carrying accumulated context from other subtasks.
+The primary purpose of multi-agent architectures is context isolation. Each Task agent operates in a clean context window focused on its subtask without carrying accumulated context from other subtasks.
 
 **Isolation Mechanisms**
-Full context delegation: For complex tasks where the sub-agent needs complete understanding, the planner shares its entire context. The sub-agent has its own tools and instructions but receives full context for its decisions.
+Full context delegation: For complex tasks where the Task agent needs complete understanding, the planner shares its entire context. The Task agent has its own tools and instructions but receives full context for its decisions.
 
-Instruction passing: For simple, well-defined subtasks, the planner creates instructions via function call. The sub-agent receives only the instructions needed for its specific task.
+Instruction passing: For simple, well-defined subtasks, the planner creates instructions via function call. The Task agent receives only the instructions needed for its specific task.
 
 File system memory: For complex tasks requiring shared state, agents read and write to persistent storage. The file system serves as the coordination mechanism, avoiding context bloat from shared state passing.
 
 **Isolation Trade-offs**
-Full context delegation provides maximum capability but defeats the purpose of sub-agents. Instruction passing maintains isolation but limits sub-agent flexibility. File system memory enables shared state without context passing but introduces latency and consistency challenges.
+Full context delegation provides maximum capability but defeats the purpose of Task agents. Instruction passing maintains isolation but limits Task agent flexibility. File system memory enables shared state without context passing but introduces latency and consistency challenges.
 
 The right choice depends on task complexity, coordination needs, and acceptable latency.