feat(plan): add bite-sized work item decomposition

[mvanhorn]

Summary

• Adds Phase 5.5: Work Item Decomposition to /ce:plan that generates structured, bite-sized work items
• Each task is 2-5 minutes with exact file paths, complete code, verification commands, and commit boundaries
• ## Work Items section added to MORE template (3-8 tasks) and A LOT template (5-15 tasks grouped by phase)
• MINIMAL template unchanged - quick issues stay quick
• No changes to ce:work needed - structured format is valid markdown it already parses

Motivation

/ce:work Phase 1 Step 3 says "Use TodoWrite to break plan into actionable tasks" - but this decomposition happens ad-hoc at runtime, without the planning context. Plans should do the heavy lifting (80/20 philosophy).

Superpowers (42K stars) attributes much of its quality to this exact pattern - their plans produce 2-5 minute steps with exact paths, complete code, run commands, and expected output.

Related: #146 "Plan with files"

Changes

File	Lines	What
commands/ce/plan.md	+98	Phase 5.5 instructions + Work Items in MORE and A LOT templates
.claude-plugin/plugin.json	+1/-1	Version bump 2.38.1 -> 2.38.2
CHANGELOG.md	+6	Entry for this change

Test plan

• Run /ce:plan "add user auth" and select MORE - verify Work Items section appears with file paths, code, and verification commands
• Run /ce:plan "simple typo fix" and select MINIMAL - verify no Work Items section
• Run /ce:plan "major refactor" and select A LOT - verify Work Items grouped into phases
• Run /ce:work on a plan with Work Items - verify TodoWrite picks up tasks correctly

---

Closes #245
Refs #146

Generated with Claude Code

[tmchow]

@mvanhorn we've got another conflict to resolve

[mvanhorn]

Rebased onto main - conflict resolved. Should be good to go now.

[tmchow]

@mvanhorn wondering about the metric based on time. Did you experiment with any other way to decompose and settle on that as a way?

[mvanhorn]

The time metric came from Superpowers (obra/superpowers) - they found that "2-5 minutes per step" was the granularity that kept agents and developers moving without getting stuck mid-task. I tried a few alternatives during development:

• Lines of code (e.g., "each step should be <30 lines") - too variable across languages and change types. A 10-line regex fix can take longer than a 50-line boilerplate addition.
• File count ("one file per step") - doesn't map well to cross-cutting changes where you touch 3 files for one logical unit of work.
• Complexity buckets (simple/medium/hard) - too subjective, agents interpret these inconsistently.

Time worked best because it's universal and correlates with cognitive load - if a step takes >5 minutes, it probably has hidden complexity that should be split. That said, it's a guideline for the planning agent, not a hard constraint. Open to other approaches if you have ideas.

[tmchow]

Oops i missed this. drop this

[tmchow]

The time metric came from Superpowers (obra/superpowers) - they found that "2-5 minutes per step" was the granularity that kept agents and developers moving without getting stuck mid-task. I tried a few alternatives during development:

• Lines of code (e.g., "each step should be <30 lines") - too variable across languages and change types. A 10-line regex fix can take longer than a 50-line boilerplate addition.
• File count ("one file per step") - doesn't map well to cross-cutting changes where you touch 3 files for one logical unit of work.
• Complexity buckets (simple/medium/hard) - too subjective, agents interpret these inconsistently.

Time worked best because it's universal and correlates with cognitive load - if a step takes >5 minutes, it probably has hidden complexity that should be split. That said, it's a guideline for the planning agent, not a hard constraint. Open to other approaches if you have ideas.

No I think i'm gtg on this suggestion. I was mainly curious to what else you considered that I may not have leading up to your PR. After the one changelog feedback to yank I think this is gtg but i'll want to just sit with it a bit to think a bit more before merging.