The Problem
Some people can give a clean project update in thirty seconds. Other people open their mouth and bring the whole backstory with them.
I am usually in the second group.
The update starts simple: “The migration is on track.” Then the supporting context leaks in. Why the migration exists. What broke last week. Which edge case changed the plan. Why the old approach was worse. Which part is technically interesting. By the time I stop talking, the room has more information, but not necessarily more clarity.
This is easy to misread as a personality trait. Some people are concise. Some people ramble. You either have the communication gene or you do not.
I do not think that is right.
Rambling is often a filtering problem. You know too much context and have not practiced deciding what the room actually needs. A project update does not need the whole story. It needs the current state, what changed, what matters next, and whether anyone needs to act.
That filtering skill can be trained.
The Idea
I built coherent as part of my public skill library, devinat1/skills, for that training loop.
The point is not to have an agent write a better version of what I meant. That would solve the immediate sentence and skip the part where I get better. The useful move is harsher and smaller: say the messy version out loud, get told what to cut, then try again.
That matters because clarity is not just the final wording. Clarity is the judgment underneath the wording. What is the core point? Which details support it? Which details are true but irrelevant right now? Which caveat protects accuracy, and which caveat is just hedging?
If the agent writes the polished version, I can nod along and think, “yeah, that sounds better.” But I did not practice the judgment. I outsourced it.
coherent keeps the work on my side. It critiques the attempt instead of replacing it.
The Project Update Version
A bad project update usually does not fail because it is false. It fails because it is unfiltered.
Something like:
We are mostly on track with the billing migration, but there were a few weird things with the old invoice records, and I had to go back through the webhook path because there was this edge case around retries, and I think the actual issue is that the old system was mixing subscription state with payment state, so I am cleaning that up, but it means the backfill needs another pass.
All of that might be accurate. It is also too much.
The clearer version is not necessarily shorter because shorter is morally better. It is shorter because the room needs the shape before it needs the internals:
The billing migration is still on track. The only change is that the invoice backfill needs one more pass because old webhook retries exposed inconsistent records. No decision needed today; I will flag it if that threatens the timeline.
That version keeps the meaning. It cuts the tour.
This is the exact kind of rep coherent is for. Not “make this sound smarter.” Not “turn this into executive-speak.” Just: remove the parts that do not help the listener understand what matters.
Practice, don’t outsource
The critique makes the failure visible:
- You buried the status under the backstory.
- You explained the technical cause before saying whether the timeline changed.
- You included three details that are true but not needed for this room.
Then I try again. That repetition trains the decision, rather than outsourcing it to an editor.
Takeaway
Clear communication is not a personality trait. It is a practiced ability to preserve meaning while cutting noise.
For technical people, the hard part is that the noise is usually real information. The extra context is not nonsense. It is often accurate, relevant to the work, and interesting to explain. But a status update is not a memory dump. It is a tool for helping other people understand what matters now.
coherent is useful because it treats clarity like a rep. Say the messy thing. Cut what does not serve the listener. Try again without losing the truth.
That is how rambling turns into communication.