Context
Currently /debug is a 227-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/debug.md (227 lines)
- Full inline workflow implementation
- Uses: Bash, Read, Write, Edit, Grep, Glob, TodoWrite
- Handles systematic debugging with issue tracking
No Agent: No corresponding src/claude/agents/devflow/debug.md
Question
Should we create a dedicated debug sub-agent to:
- Reduce token usage in command execution
- Separate concerns (command = UX, agent = implementation)
- 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
- Easier to maintain debugging logic separately
- Agent could be reused outside slash command context
Cons of Creating Agent:
- Debug workflow may need interactive user input (like /release)
- Additional file/complexity to maintain
- Current inline approach works fine
Decision Needed
Should /debug follow the simple wrapper pattern (launch agent) or keep inline workflow?
Related
Context
Currently
/debugis a 227-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/debug.md(227 lines)No Agent: No corresponding
src/claude/agents/devflow/debug.mdQuestion
Should we create a dedicated
debugsub-agent to:Trade-offs
Pros of Creating Agent:
Cons of Creating Agent:
Decision Needed
Should
/debugfollow the simple wrapper pattern (launch agent) or keep inline workflow?Related