Creates structured implementation plans with TDD task breakdown, dependency management, and capability assignment. Use when user says "plan this", "create a plan for [task]", "break down [feature]", "how should we implement [x]", "list all plans", or "switch to [plan]". Assigns best-fit agent, relevant skills, and model tier to each task using cached capabilities from context loading phase (Phase 0).
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
Creates structured implementation plans with TDD task breakdown, dependency management, and capability assignment. Use when user says "plan this", "create a plan for [task]", "break down [feature]", "how should we implement [x]", "list all plans", or "switch to [plan]". Assigns best-fit agent, relevant skills, and model tier to each task using cached capabilities from context loading phase (Phase 0).
* marks the active plan (matches current_track.id)
Exclude preview- prefixed files unless --all is passed
Sort by created descending (newest first)
Switch Plan
Switch the active plan to <track_id>:
Read state.json
Find <track_id> in plans[]. If not found, check .mycelium/plans/ for a matching file and register it first. If still not found, error: "Plan <track_id> not found."
Set the current active plan (the one with status: "in_progress") to "paused" in both plans[] and its plan file frontmatter
Set the target plan to "in_progress" in both plans[] and its plan file frontmatter
Update current_track to point to the target plan
Show confirmation: "Switched to plan <track_id>"
Suggest /mycelium-work or /mycelium-continue to resume
Planning Guidance
This section provides comprehensive guidance for creating detailed implementation plans with proper task decomposition and dependency management.
Plan Structure
Every plan follows this template (stored in templates/plans/plan.md.template):
---
feature: "Feature Name"
created: YYYY-MM-DD
status: active
complexity: M
estimated_tasks: 5
parallel_capable: true
---
## Overview
[1-2 paragraph description of what's being built and why]
## Success Criteria
[Measurable outcomes that define "done"]
## Phase 1: {Phase Name}### Task 1.1: {Task Title}**Status:** [ ]
**Complexity:** T/S/M/L
**blockedBy:** []
**blocks:** [1.2, 2.1]
**agent:** general-purpose
**skills:** [tdd, verification]
**model:** sonnet
**Description:**
[What needs to be done]
**Acceptance Criteria:**- [ ] Criterion 1
- [ ] Criterion 2
**Test Plan:**
[How to verify this works]
[More tasks...]
## Phase 2: {Phase Name}
[More phases...]
## Deviations Log
[Track changes from original plan]
## Final Checklist- [ ] All tests passing
- [ ] Code review complete
- [ ] Documentation updated
Shared interfaces: Define interface first, then parallelize implementations
Success Criteria Definition
Make success measurable and objective:
Good Success Criteria
✅ "All API endpoints return < 200ms p95 latency"
✅ "Test coverage > 85% for new code"
✅ "Zero SQL injection vulnerabilities in security scan"
✅ "Documentation includes working examples for each endpoint"
Bad Success Criteria
❌ "API is fast enough"
❌ "Good test coverage"
❌ "Secure implementation"
❌ "Well documented"
When creating plans, use cached capabilities to assign agent/skills/model to each task:
Step 1: Load Cached Capabilities
// Read from state.json (cached by Phase 0: Context Loading)const state = read(".mycelium/state.json")
const capabilities = state.discovered_capabilitiesif (!capabilities || !capabilities.skills) {
error("❌ Capabilities not cached. Run /mycelium-context-load first.")
return
}
// Available capabilities:// - capabilities.skills: Array of {name, description, source, plugin}// - capabilities.agents: Array of {name, description, source}// - capabilities.mcp_tools: Array of {name, server, description}
Step 2: Assign to Each Task
For each task in the plan:
### Task 1.1: Setup auth module**agent:**general-purpose# Best-fit from cached agents**skills:** [tdd, verification] # Relevant from cached skills**model:**sonnet# haiku/sonnet/opus based on complexity
Assignment Logic:
functionassignCapabilities(task) {
// 1. Agent Assignment// Default: general-purpose for most tasks// Explore: for research/read-only tasks// Bash: for git/command tasks
task.agent = selectAgent(task.description, capabilities.agents)
// 2. Skills Assignment// Always include tdd for implementation tasks// Add verification for validation tasks// Add relevant plugin skills based on task type
task.skills = selectSkills(task.description, task.agent, capabilities.skills)
// 3. Model Assignment// Haiku: trivial tasks (T complexity)// Sonnet: most tasks (S/M complexity) - DEFAULT// Opus: complex/critical tasks (L complexity, security, architecture)
task.model = selectModel(task.complexity, task.description)
}
Step 3: Verify Assignments
// Validate all assignments exist in cached capabilitiesfor (task of tasks) {
// Check agent existsif (!capabilities.agents.some(a => a.name === task.agent)) {
error(`Agent not found: ${task.agent}`)
// Fallback to general-purpose
task.agent = "general-purpose"
}
// Check skills existfor (skill of task.skills) {
if (!capabilities.skills.some(s => s.name === skill)) {
error(`Skill not found: ${skill}`)
// Remove invalid skill
task.skills = task.skills.filter(s => s !== skill)
}
}
// Model doesn't need validation (haiku/sonnet/opus are always available)
}
Important: Capabilities are discovered in Phase 0 (Context Loading) and cached in state.json. This phase LOADS and USES the cache, it does NOT discover capabilities.
Common Pitfalls
Too Large Tasks
❌ Problem: Tasks > 500 lines or > 8 hours
✅ Solution: Split into smaller, testable units
Vague Acceptance Criteria
❌ Problem: "Works correctly"
✅ Solution: "Returns 200 for valid request with JSON response matching schema"
Missing Dependencies
❌ Problem: Tasks blocked on unidentified dependencies
✅ Solution: Explicitly map all dependencies before starting
Over-Planning
❌ Problem: Planning every detail up front
✅ Solution: Plan current phase in detail, later phases at high level
Plans change during implementation. Track deviations:
## Deviations Log### YYYY-MM-DD: Changed Task 2.3 Approach**Original:** Use library X for parsing
**New:** Implement custom parser
**Reason:** Library X doesn't handle edge case Y
**Impact:** +1 task, +2 hours
When to Deviate
Acceptable reasons:
New information discovered
Original approach blocked
Better solution found
Requirements changed
When to Replan
Major deviations require replanning:
50% tasks changed
Core architecture changed
Requirements significantly changed
Timeline/resources changed
Quick Example
# Create a new plan
/mycelium-plan "Add user authentication"# List all plans
/mycelium-plan --list
# Switch to a different plan
/mycelium-plan --switch auth_20260210
# Create another plan (previous one auto-pauses)
/mycelium-plan "Optimize database queries"
Important
Plans are LIVING DOCUMENTS - updated in-place during execution
All tasks follow TDD: tests before implementation
Tasks have explicit dependencies (blockedBy/blocks)
Default to parallel execution - minimize dependencies
Creating a new plan auto-pauses the previous active plan - no plans are lost
Backward compatible - works when plans[] doesn't exist (falls back to globbing .mycelium/plans/)
Issue: "All tasks marked as blocked"
Cause: Dependency chain not properly initialized
Solution: Ensure at least one task has blockedBy: [] to start execution
