client-reply
Drafts a reply to a client's feedback round or business question in plain, non-technical language, in your language and voice. It only drafts; you send.
- Group
- Session and communication
- Kind
- Action
- Writes
- Nothing; the draft stays in the chat
- Asks before
- Nothing to approve: it never sends; it asks for any missing fact
When it runs
When you ask to answer a client, or to turn technical notes into a message for one:
- reply to the client
- write to the client
- put this in plain language
- answer the feedback
What it does
- Collects the input. The client's message or feedback round, the technical facts (bug summary, PR, commits, notes) and what you want to say. If the reply depends on a missing fact, such as a date or whether something is fixed, it asks; it never invents dates, prices or promises.
- Matches language and voice. It writes in the language of the client's message, otherwise in yours, and follows any voice rule in your instructions (for example first person singular instead of "we"), with your usual greeting and sign-off when the conversation shows them.
- Translates the jargon. It lists every technical term in the input (code identifiers, error names, endpoints, migrations, branches, PR and commit references, tool names, internal environment names) and turns each into what the client sees: what did not work, for whom, since when, what was done, what happens next and when.
- Answers every point of a feedback round in the client's order, one short paragraph or bullet each, saying plainly what is done, what is not, and what needs the client's decision or input.
- Re-reads the draft against the list of terms and removes any still in it, keeping a technical term only when the client used it first.
- Shows the draft with one line on what it translated or left out, for example "Left out: the migration number and the PR link".
Boundaries
Stops when
The draft is in the chat. It revises the draft on request; you send it.
Never
- Send, post or schedule the message, by email, chat, ticket or any other channel.
- Invent facts, deadlines, prices or commitments you did not give.
- Include internal identifiers: PR or issue numbers, branch names, commit SHAs, file paths, migration IDs, stack traces.
- Name other clients or internal colleagues you did not mention.
Related
- bug-triage produces the technical facts a reply to an incident needs.
- session-retro wraps up the session the reply came out of.
- The approval model: no skill sends a message outside a PR thread.