maestro-v2-migration

Guide MaestroCLI v1 to v2 migration with architectural changes and debugging.

Updated Mar 13, 2026
One-click install
npx skills add https://github.com/ReinaMacCredy/Maestro-CLI --skill maestro-v2-migration
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: maestro-v2-migration
Source: https://github.com/ReinaMacCredy/Maestro-CLI/tree/main/.claude/skills/maestro-v2-migration
Command: npx skills add https://github.com/ReinaMacCredy/Maestro-CLI --skill maestro-v2-migration

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

This Skill provides essential guidance for understanding and working with the significant architectural changes introduced in MaestroCLI v2, preventing confusion and wasted effort when dealing with legacy patterns or new v2 features.

Core Features & Use Cases

  • Architectural Overview: Explains key v2 changes like Context-to-Memory rename, the 4-state task model, and the plain file backend.
  • Legacy Pattern Identification: Helps identify and migrate outdated v1 patterns (e.g., 'context' instead of 'memory', old task states).
  • Debugging Assistance: Aids in debugging v2 behavior by clarifying the new architecture and data flow.
  • Use Case: When encountering code that references contextAdapter or uses task states like pending or in_progress, this Skill provides the necessary context to understand and refactor it to the v2 memoryAdapter and 4-state model.

Quick Start

Consult this guide when working with MaestroCLI v2 code or encountering legacy v1 patterns.

Frequently Asked Questions about maestro-v2-migration

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I migrate MaestroCLI legacy code that references contextAdapter to the new v2 architecture?

To migrate MaestroCLI legacy code, rename 'contextAdapter' to 'memoryAdapter' and replace outdated task states with the new 4-state model. This v2 migration guide helps refactor v1 patterns to align with the updated memory management and plain file backend.

What is the four-state task model in MaestroCLI v2 architecture?

The four-state task model in MaestroCLI v2 architecture simplifies task tracking by replacing older states like 'pending' and 'in_progress'. This migration guide details the transition to the new model and the shift to a plain file backend for task storage.

Why does MaestroCLI v2 use pre-agent hooks for spec injection?

MaestroCLI v2 uses pre-agent hooks for spec injection to streamline the enhanced research phase and tool detection. This architectural change ensures specifications are automatically integrated, improving data flow and debugging in v2.

How do I debug MaestroCLI v2 behaviors when encountering legacy v1 patterns?

Debugging MaestroCLI v2 behaviors involves identifying legacy v1 patterns like 'context' references or old task states. This guide clarifies the new v2 architecture and data flow to help refactor outdated code and resolve inconsistencies.

Does MaestroCLI v2 require a specific database for its plain file backend task management?

No, MaestroCLI v2 does not require a database for task management. The v2 architecture adopts a plain file backend for tasks, simplifying storage compared to legacy patterns and easing the migration of task states.

What is the best way to identify outdated MaestroCLI v1 patterns during refactoring?

The best way to identify outdated v1 patterns during refactoring is to look for 'context' instead of 'memory' and legacy task states like 'pending'. This migration guide provides the context needed to update code to v2 standards.