Evaluate: Should /plan-next-steps command have dedicated sub-agent?

[dean0x]

Context

Currently /plan-next-steps is a 212-line inline command without a dedicated sub-agent. Other commands like /catch-up (29 lines) and /commit (28 lines) delegate to sub-agents that handle the heavy lifting.

Current State

Command: src/claude/commands/devflow/plan-next-steps.md (212 lines)

• Full inline workflow implementation
• Uses: TodoWrite, Read, Write, Edit, MultiEdit, Bash, Grep, Glob, Task
• Extracts actionable next steps from discussion and saves to todo list

No Agent: No corresponding src/claude/agents/devflow/plan-next-steps.md

Question

Should we create a dedicated plan-next-steps sub-agent to:

1. Reduce token usage in command execution
2. Separate concerns (command = UX, agent = implementation)
3. Follow pattern used by catch-up, commit, research commands

Trade-offs

Pros of Creating Agent:

• Consistent pattern with other commands
• Lower token cost per invocation
• Agent could be reused for automated task extraction
• Easier to maintain task extraction logic separately

Cons of Creating Agent:

• Workflow is tightly coupled to current conversation context
• Direct access to TodoWrite might be needed by command
• Current inline approach is focused and specific

Decision Needed

Should /plan-next-steps follow the simple wrapper pattern (launch agent) or keep inline workflow?

Special Consideration

This command bridges conversation to action items. It may need direct access to:

• Current conversation context (what agent sees)
• TodoWrite tool (for immediate todo list updates)
• Current agent state

An agent invocation might lose important conversation context that the parent agent has.

Related

• Evaluate: Should /debug command have dedicated sub-agent? #11 (debug agent evaluation)
• Evaluate: Should /devlog command have dedicated sub-agent? #12 (devlog agent evaluation)