Docs
Reply and approve
EarShots writes the first version and holds the audit trail. A person reads it, then sends it from the original post.
The review flow
- 1
Open the post
Quick review opens a focused window with the full text, the author, the track, the reasoning, and your queue position. Nothing is truncated, so you read what the person actually wrote. - 2
Draft Reply
Press Draft Reply for a first version pulled from your documentation, or Improve Reply to tighten something you wrote. Citations appear next to the draft. - 3
Edit and save
Your edits autosave as a draft with version history, so you can step back or hand a half-written reply to a teammate. - 4
Approve
Approving records who signed off and when. It does not publish anything. - 5
Copy reply and open original post
This copies your text and opens the original thread in a new tab. You paste and send there, in your own account.
Replying in another language
Set a reply language for the workspace and drafts come back in it. Code, commands, error messages, and links stay untouched.
Blog posts work differently
A blog post, tutorial or newsletter opens with an accuracy check instead of a reply box. EarShots checks every claim it makes about your product against your documentation. See Ground Truth.
Somebody else's repository
GitHub issues, pull requests, and discussions almost always sit in a repository your team does not own. EarShots reads that signal and keeps it in Context Buzz, but it never drafts or saves a reply there. Showing up in a work thread to talk about your product rarely lands well. Open the post when you want to read it, and act on what you learn somewhere you own.