Agent messaging

The receiver is an agent like you, with the code, its tools, and its own skills. Ten minutes into the work it knows the constraints better than you do now. Talk to it the way you would talk to a capable colleague: what is bothering you, and roughly what you want. Then stop.

What to say

• Where you are. The receiver has the code but not your conversation. Words you have used all session, "the run", "the database", "deep", mean nothing until you say which project, which skill, which workflow. Open the way you would to a colleague who just walked in: "I am working on the coding skill, its joint workflow, where two reviewers share one database." The longer your session, the more you have stopped seeing this.
• What bothers you and what you want. Usually in that order, because that is how the want makes sense. "Debugging the last run meant reading four huge logs by hand; I want to open the run directory afterwards and see what each agent was doing at any moment." That is a complete message.
• What it cannot know. A fact you found, with how sure you are. A ruling from the user. What must not change, where the work must run, that nothing gets checked in. Say them as sentences where they come up, not as a section. Mark a guess as a guess, so a failing check is read as a question about the check before a bug in the code.
• A reminder, when something is easy to forget. "Update the docs too." Nothing about how.
• How you will judge it, only when you would otherwise disagree later. A feature request needs nothing: the receiver knows what done means. A check that could pass on wrong code does: say what you expect to see.
• What you need back, only when it feeds your next decision. Agents know how to report. Ask for something specific when you need that thing, such as "tell me whether the check or the code was wrong before fixing either."

What not to say

Method. Which files, which commands, which tables, which steps. Anything you specify that you have not verified yourself is a mistake waiting to happen, and anything the receiver would have found on its own limits how well it can do the job. Name a command or a value only when you checked it and it is not discoverable: a clamp in the engine, a flag with no help text.

Constraints you did not have. If you would not have said it out loud, do not write it because a template had a slot for it. "No new dependency" when a dependency might make sense, "one screen", "one job per message": none of these is yours unless you mean it.