πͺ Orchestrator Mode
Available anytime during your journey
Don't want to think about which mode to use? Orchestrator mode automatically delegates tasks to the right mode for the job.
Purposeβ
In Orchestrator mode, 1M Code acts as a project manager. It will:
- Analyze what you're trying to do
- Choose the best mode for each task
- Delegate work automatically
- Coordinate across multiple modes
When to Use This Modeβ
Use Orchestrator mode when:
- You have a complex, multi-part task
- You're not sure which mode to use
- You want to describe what you want without managing modes
- You're working on something that spans multiple phases
How It Worksβ
The Orchestrator doesn't do the work itselfβit delegates:
You: "I want to add a dark mode feature to my app."
Orchestrator thinks:
1. This needs a design decision β Plan mode
2. Then implementation β Build mode
3. Then testing β Test mode
Orchestrator:
"I'll break this into subtasks and delegate to the right modes..."
Available Toolsβ
| Tool | Purpose |
|---|---|
new_task | Create subtasks in other modes |
The Orchestrator's main tool is delegation. It creates subtasks and assigns them to specialized modes.
Example Promptsβ
Multi-Step Tasksβ
I want to add user authentication to my app.
The Orchestrator will:
- Create a Plan subtask to design the auth flow
- Create a Build subtask to implement it
- Create a Test subtask to verify it works
- Create a Guard subtask to check security
Unclear Requirementsβ
Make my app better.
The Orchestrator will:
- Ask clarifying questions
- Break "better" into specific improvements
- Delegate each improvement to the right mode
End-to-End Featuresβ
I want users to be able to share their progress on social media.
The Orchestrator will:
- Spec: Define what sharing means
- Plan: Design the sharing architecture
- Build: Implement the share button
- Test: Verify sharing works
- Sell: Add to marketing messaging
When to Use Orchestratorβ
Good for Orchestratorβ
- Complex features that span multiple phases
- When you're not sure where to start
- Big tasks that need breaking down
- When you want to describe outcomes, not process
Better to Use Specific Modesβ
- Single-step tasks (just use Build mode)
- Learning concepts (just use Ask mode)
- Fixing a bug (just use Debug mode)
- You know exactly what you need
How Subtasks Workβ
When Orchestrator creates a subtask:
- It describes what needs to be done
- It specifies which mode to use
- The subtask runs in that mode
- Results come back to the Orchestrator
- Orchestrator coordinates next steps
You can see all subtasks in the chat history.
Example: Building a Featureβ
You: "Add a settings page where users can change their reminder interval."
Orchestrator response:
I'll break this down into subtasks:
Subtask 1: Plan (ποΈ Plan mode) Design the settings page layout and data storage
Subtask 2: Build (π» Build mode) Create the settings page component
Subtask 3: Build (π» Build mode) Implement interval selection and saving
Subtask 4: Test (π§ͺ Test mode) Verify settings persist correctly
Starting with Subtask 1...
Tips for Using Orchestratorβ
Be Clear About Goalsβ
Tell it what you want to achieve, not how to do it:
- β "Users should be able to reset their password"
- β "Create a password reset page with a form..."
Trust the Processβ
The Orchestrator knows which modes to use. Let it work.
Review Subtasksβ
You can see and approve each subtask before it runs.
Step In When Neededβ
If a subtask isn't quite right, you can take over in that mode.
Switching to Orchestrator Modeβ
When you have a complex task, switch to Orchestrator:
Slash command: /orchestrator
Or just say: "I have a big task: [describe it]"
When to Switch Outβ
Exit Orchestrator mode when:
- You want more direct control
- Tasks are simple and specific
- You're learning and want to understand each step
- Subtasks aren't matching what you need
A walkthrough video for Orchestrator mode is in production. Check back soon or join our Discord for updates.