Decomposition & planning
Break a task into steps an agent can do well, and make it plan before it acts.
Agents are reliable on small, well-scoped steps and unreliable on big, vague ones. Most of the skill of prompting a hard task is cutting it into pieces the agent can actually nail.
Split by decision, not by size
A good sub-task has one clear decision and a checkable result. "Find every call site of this function" is a clean step; "refactor the module" is a bundle of decisions hiding as one. When a step still feels ambiguous, split again.
Make it plan first
For anything non-trivial, have the agent produce a plan before it acts — the list of steps, the files it will touch, the order. A plan is cheap to review and cheap to correct; a half-done wrong execution is not. It also surfaces bad assumptions before they cost anything.
Let each step verify
Decomposition pairs with verification: each step should end in a checkable state, so an error is caught at the step that caused it rather than three steps later.
The tell
If the context keeps growing and the agent starts contradicting itself, the task is too big for one pass. That's a decomposition signal, not a bigger-model signal.
This plan-then-execute-then-verify discipline is exactly the kind of thing worth capturing as a skill so you don't re-specify it every time.