Tw93 (@HiTw93) “Funny enough, this is already the third post in my Waza skill design series. Tod” — TopicDigg

Funny enough, this is already the third post in my Waza skill design series. Today’s one is about /think, the skill I use for solution design before writing code. I have two settings in Claude Code that I find especially useful. The first is /model opusplan, which means planning is done with Opus while execution runs on the regular Sonnet model. That helps me save Max usage for the places where it matters more. The second is that I usually run Claude Code with alias c="claude --dangerously-skip-permissions". I would not recommend that to less technical users. I use it because I know what it is doing, and mostly because I am lazy. Back to /think. How do you get the strongest model to produce better technical plans? It starts with the model itself. Models tend to avoid taking a position. I prefer engineers who can give a clear recommendation. So the first thing I do is require the model to have a point of view. It must state its recommendation, explain what evidence could overturn it, and avoid empty lines like “There are many ways to think about this.” Giving two or three options is fine, but it has to make a clear recommendation, and it must always include a minimal option. But a plan is not done just because it sounds good. The second step is to make it argue against itself. Under what conditions would this plan fail? If those problems can be fixed, the fixes should be folded back into the plan and the revised version presented again. If the plan breaks under certain conditions, it has to say exactly where and why it fails. That way, by the time the plan reaches you, the tradeoffs are already visible. I also go fairly deep on validating the premises before planning starts. First, it checks whether it is even looking at the right part of the codebase. I have seen models produce plans against the wrong path. Then it looks for older technical design docs to avoid reinventing work that already exists. After that, it searches GitHub to see whether similar problems have already been solved elsewhere. Only after those three steps does it start proposing solutions. That helps prevent the entire plan from being built on a bad assumption. There is also complexity grading. If the work touches more than eight files or introduces a new service, the plan must explicitly call out the scale. If data flows across more than three components, it has to draw an ASCII diagram and look for cycles. API keys and third-party dependencies also have to be listed during the planning phase, so you do not waste time or end up with a plan that depends on shaky assumptions. There is one more hard rule. The plan cannot contain things like TBD, TODO, “we can decide this later,” or vague phrases like “similar to step N.” That goes back to model behavior again. Once you leave that kind of escape hatch, execution tends to drift, skip work, or fill in the blanks poorly. I try not to leave the model any room to wiggle out of precision. The output format is also strict: what we are doing, what we are not doing, which option was chosen and why, three to five decision factors, and a clear list of unknowns. /think does not write code. Execution only starts after the user approves the plan. When I built this skill, I was really trying to capture how strong technical experts approach solution design: investigate first, form a clear recommendation, make decisions decisively, leave no loose ends, and improve the plan immediately when something invalidates it. If you have better ideas for planning and solution design, feel free to contribute to Waza.