FredrinEverything else in Fredrin is mechanism. This is the part that decides what comes back.
Brief it like a competent stranger
The Worker is a good engineer who has never seen your codebase and cannot ask you a follow-up question at 2am. Write for that reader.
Say what outcome you want, not what code to write. "Users should stay signed in for thirty days" beats "add a maxAge to the session cookie". The second one is you doing the agent's job, badly, from memory.
Point at the territory if you know it. "This is somewhere in the invite flow" saves a search. Being wrong about it costs nothing, because the agent will check.
Say how you will know it worked. This is the one people skip, and it is the one that changes the output most.
Acceptance checks earn their keep
A ticket's plan has an Acceptance checks section for a reason. It is both the list the Worker works to and the list you scan when the diff arrives.
The difference between a vague check and a real one is the difference between a review that takes thirty seconds and one that takes ten minutes:
| Vague | Real |
|---|---|
| Handles errors | Returns 409 with the existing record when the slug is taken |
| Works on mobile | No horizontal scroll at 320px |
| Is tested | A test covers the expired-token path |
| Fast enough | The list query stays under 200ms with 10k rows |
What to leave out
Do not write the implementation. If you have already decided the approach, say the approach in one line. Do not paste pseudocode.
Do not restate your conventions. Anything true of every ticket in the repo belongs in project context, where every Worker reads it automatically. Repeating it in each ticket is how it drifts.
Do not bundle. Three changes in one ticket produce one diff you cannot review in a glance and one branch you cannot partially ship. Three tickets run at the same time anyway.
Sizing
One ticket should be one pull request you would be happy to review.
Too big is the common failure. If the description has an "and also", it is probably two tickets. If it names three subsystems, it is probably a goal.
Too small is a real failure too, just a rarer one. A ticket that says "rename this variable" costs more to file, run and review than to do yourself.
When you genuinely do not know
Run it in Plan mode. The Worker researches the ticket, asks up to three questions only a human can answer, and hands back a plan without writing any code.
That is the right tool for a request with a real fork in it. It is not a substitute for thinking about the ticket, but it is very good at finding the decision you had not noticed you were making.
Sending work back
When a diff is not right, be specific in the same way. The Worker resumes the same session with everything it already knew, so a precise correction usually costs one round trip and a vague one costs several.
Next steps
- Tickets - the rest of the card.
- Project memory - where the things you would otherwise repeat belong.
- Review and merge - reading the diff against the checks.