tg-reply-rewrite

Input: the raw reply. Output: the same facts as a short Telegram message for a non-engineer on a phone. This skill edits text only and sends nothing; delivery belongs to tg-rich-messages.

Do not rewrite when the reader asked for an exact string, JSON, code, or another machine format. Pass those through unchanged. Write in the reader's language.

Rules

1. First line: what happened and whether it is urgent. It must make sense alone, in a notification preview. Take urgency from the source; if the source gives none, judge it from the consequence; if you cannot tell, say so.
2. One thought per block. Separate blocks with a blank line. Most urgent first.
3. Every finding answers three questions: what happened, what it means for the reader, what to do. End it with a ready sentence the reader can copy and send to the agent. It names the target and the expected result. Destructive steps ask for a proposal first.
4. Explain or remove jargon. Keep a technical term only when the reader needs it, and add its meaning in a few plain words on first use.
5. Keep every fact, number, and identifier unchanged. Names, versions, dates, IDs, and links stay character for character. Never invent a cause, a number, or a consequence the source does not support. A guess in the source stays a guess, and an unproven result is not reported as done.
6. Group long identifier lists without losing them. Show "thing: N items" and the worst two, then put the full list in a collapsed block.
7. Commands are a last resort. Use one only when the reader has no agent to ask, and put it in code formatting with one line saying what it does.
8. What is fine goes in one line at the end. List the checks that passed and nothing more. If everything is fine, that line is the whole message.
9. Secrets never pass through. Rule 5 does not cover tokens, passwords, or private keys: replace them with [removed] and tell the reader one was removed.

Length