emit scripts with the plan #156
Description
What's happening now: Each subtask in a DevPlan (like "1.2.3: Implement auth middleware") gets sent to Haiku as a natural language prompt. Haiku reads the full context (CLAUDE.md + DEVELOPMENT_PLAN.md), interprets what to do, and generates/executes code. That's a lot of tokens burned on tasks where the what to do is deterministic even if the how to implement requires LLM reasoning.
Where shell scripts would be a clear win — the "mechanical" subtasks:
Many subtasks in a typical DevPlan are essentially boilerplate orchestration: create directory structures, initialize packages, set up config files, run linters, install dependencies, scaffold file templates, create git branches, run test suites, update progress markers in DEVELOPMENT_PLAN.md. These don't need an LLM at all. A scripts/0.1.1-init-project.sh that runs mkdir -p, npm init, writes a base tsconfig.json, etc. is faster, deterministic, and costs zero tokens.
Where a hybrid approach makes sense:
For subtasks that have both mechanical and creative parts, you could split them. The shell script handles the scaffolding (create files, set up imports, write boilerplate), and then a much smaller, more focused Haiku prompt handles only the logic that actually requires reasoning — like "implement the validation logic in src/validators/auth.ts given these constraints." That shrinks the Haiku prompt from "here's the entire context, figure out what to do" to "here's one focused function to write."
Concrete implementation approach for the MCP server:
The devplan_generate_plan tool could emit a scripts/ directory alongside DEVELOPMENT_PLAN.md, with one shell script per subtask (or per task). Each script would contain the deterministic portions: file creation, directory setup, dependency installation, boilerplate code via heredocs, git operations, progress tracking updates. The script could also embed a focused prompt file (prompts/1.2.3.md) that contains only the minimal context Haiku needs for the creative portion.
The execution flow becomes: run scripts/1.2.3.sh which does all the mechanical work, then if AI reasoning is needed, the script outputs a prompt that gets piped to Haiku with just the delta context — not the entire DEVELOPMENT_PLAN.md.
Where it gets tricky:
The value of Haiku-executable plans is that they adapt. A shell script is brittle if earlier subtasks deviated from the plan (different file names, changed APIs, etc.). You'd want the scripts to be somewhat defensive — checking if files exist before creating them, using variables for paths rather than hardcoding, and having clear exit points where "hand off to Haiku" is the fallback. Error handling in the scripts would need to be solid so a failed mechanical step doesn't silently corrupt the project state.
Token savings estimate:
For a typical 100-subtask plan, maybe 30-40% of subtasks are purely mechanical (Phase 0 foundation, git operations, scaffolding, progress tracking). Another 30-40% are hybrid where you could cut the prompt size by 50-70% by pre-scaffolding. That's potentially a 40-60% reduction in total token usage across a full project build.
Worth doing. The devplan_generate_plan tool is the natural place to add this — it already knows the full task structure, so it can generate the scripts alongside the markdown plan.