I read Thoughtworks’ retreat notes on the future of software engineering ( pdf ) and this line jumped out: “if an AI generates code from a spec, the spec is now the highest-leverage artifact for catching errors. Bad specs produce bad code at scale.” I don’t really do spec-driven development, but I do use plan mode for almost every change. What I hadn’t really clocked until recently is that you can influence the format and structure of the plan output with a few simple repo-level instructions in CLAUDE.md (i.e., it’s pretty prompt-led). So I tried to treat the plan as the “spec” and make it more consistent / skimmable by adding repo instructions that nudge the plan into a structured template. I also experimented with integrating EARS (Easy Approach to Requirements Syntax) so parts of the plan read more like testable requirements rather than a free-form checklist. EARS: https://alistairmavin.com/ears/ Armin Ronacher’s post that helped me think about plan mode this way: https://lucumr.pocoo.org/2025/12/17/what-is-plan-mode/ Here are the instructions I added ( CLAUDE.md ): https://gist.github.com/SamBoyd/249c131c0ca674e4919f0945c7e99195 And an example plan produced with those instructions: https://gist.github.com/SamBoyd/1b3f3b4df916cced9519f07e37c2ef81 It does seem possible to reliably influence plan structure with brief instructions. The open question for me is how to make this higher-leverage without turning plans into verbose bureaucracy. Questions for folks here: Do you have a “default plan template” you reuse across repos? What sections do you standardize (requirements, implementation steps, verification, risks, rollout)? Have you tried EARS (or any similar requirement-style formatting) in plans? What worked? How do you keep plans skimmable while still being specific enough to catch mistakes early? Any examples of instructions you’ve found consistently improve plan quality? submitted by /u/magicsrb
Originally posted by u/magicsrb on r/ClaudeCode
You must log in or # to comment.