A good task specification tells the agent what outcome is required and how success will be checked. Include:
the current problem and the expected behavior
the relevant files or interfaces
the important edge cases
constraints and clear non-goals
the tests or commands that should pass
Keep the task small enough for one coherent change. Point to a current example instead of describing every style rule. State which files or public contracts must stay unchanged, and which actions need approval. If important information is missing, tell the agent to stop and ask instead of guessing. Guide the implementation, but leave out details the agent can safely discover from the repository.
Rewriting in plainer words…
This answer doesn't lend itself to a diagram - it reads best . No credits were charged.
Why point to an existing example instead of writing out style rules?One file shows naming, structure and error handling together, and the agent can copy it. Pick an example that is current and matches the pattern you want.
The spec says 'don't touch these files.' How do you make sure that actually holds?A prompt alone can't enforce it. Back it with tool permissions or a sandbox, tests on the public contract, and a check of the diff before merge.
What goes wrong if you over-specify how the agent should implement it?The spec gets long, the key limits get buried, and the agent may follow stale steps over what the repo shows. Give the outcome and limits instead.
What you can say
A good task spec tells the agent what outcome I need and how we'll check that it's done.
So I describe the current problem and the expected behavior, point to the relevant files or interfaces, and call out the edge cases that matter.
I list constraints and clear non-goals, name the tests or commands that should pass, and say which files or public contracts must stay unchanged and which actions need my approval.
I keep it small enough for one coherent change, and for style I point to a current example in the repo instead of describing every rule.
If important information is missing, I tell the agent to stop and ask instead of guessing.
The trade-off is how much to write. I guide the implementation but leave out what the agent can safely discover from the repository, so the spec stays short and the key points stand out.
Weak answers to avoid
Hands over a vague goal'Fix the login bug' leaves the agent to guess the expected behavior and scope. State the current problem, the expected behavior and the files involved.
Gives no way to check successWithout tests or commands to run, the agent decides for itself when it's done. Name what must pass so the result can be checked, not just claimed.
Spells out every implementation stepIt spends effort on details the agent can find in the repo and buries what matters. Give the outcome, constraints and non-goals, and point to an example.
Leaves out boundaries and approvalsWith no non-goals or protected contracts, the agent may refactor or change public APIs. Say what must stay unchanged and which actions need approval first.
Interview lens
Likely follow-ups, what you can say, and the weak answers to avoid.
