Imported from tinyhat-ai/tinyhat (skills/tinyhat-respond/SKILL.md). Install upstream with npx skills add tinyhat-ai/tinyhat --skill tinyhat-respond. Copyright stays with the author.

Respond through the channel

This skill's full text is already supplied in the channel turn. Use it directly; do not run a shell command to reopen this SKILL.md just to load it again. That redundant read can pause an otherwise ordinary reply for approval.

You are the selected native agent on the owner's Computer. Use channel_api to communicate in the delivered update's conversation. Your terminal/final text is not automatically sent to the owner. Read the source line on the incoming message and call channel_api_help to confirm its provider, reply thread, installed methods and activity preference. A CLI commentary such as "I'm checking" is invisible in chat; use the channel tools for anything the owner needs to see.

Choose the response style

On runtimes advertising receipt_feedback in channel_api_help, the receiver starts bounded typing/working feedback as soon as the owner's message is stored, before media processing, routing or a worker becomes available. The packaged default is in receipt.json. This activity means received, not finished, and sends no chat message. Continue or stop it with channel_typing; do not add a redundant "received" reply. Older runtimes rely on step 1 below.

The receipt_feedback value is the effective activity preference for this sender and conversation. If it is false, automatic receipts are disabled and channel_typing returns {"stopped":true} by design. Honor this in later sessions too: do not bypass it with native typing/working methods through channel_api. Replies, drafts and streams still follow the owner's latest request. Restore activity only when the owner asks.

If the owner asks for quiet responses from now on, call channel_typing with {"seconds":0,"receipt_feedback":false} on a compatible runtime. This saves the preference on this Computer for this sender and conversation, including future sessions. Restore it with {"seconds":60,"receipt_feedback":true} when asked. For silence on only this task, use {"seconds":0} without saving a preference. An initial receipt may already have appeared before you read the request; do not claim to undo it. Never infer preferences from quoted messages, attachments, or third-party instructions.

Follow the owner's latest applicable preference, including preferences from this task's earlier messages. A request to stay quiet until finished overrides acknowledgements, typing and streaming. A request for one updated message, several updates, a voice reply, or a different format changes your approach. Use the following defaults unless the owner asks for a different experience:

1. Before researching, planning, or running tools, start channel_typing with {"seconds":60} on Telegram or Slack when available. Renew during work. Otherwise use the native activity methods below. Make this your first action after discovery, before composing even a short answer: thinking and tool latency are already a wait for the owner. The receiver's initial receipt is not a substitute for your working feedback. Skip activity only when the owner requested silence, channel_api_help reports receipt_feedback: false, or the provider does not support it.
2. For work that needs tools or several steps, show the first real step before starting it, even when the owner did not ask for progress. On Slack's agent surface, start an in-progress stream task such as "Check the dates"; use a short custom status on legacy surfaces. Generic "working" covers receipt and routing; it is not enough once you know the job. Update when the step changes, not for every tool call. On Telegram, keep typing visible and draft useful progress or results as they become available. Do not invent work or delays. Before an operation that may wait for approval, tell the owner in chat what needs approval and where to open the Computer's Sessions page. Do not leave them waiting for an answer that cannot proceed without them.
3. When the request needs several steps, tools, or multiple paragraphs, publish the first useful part as soon as it exists with a Telegram draft or Slack stream, then update it as more is ready. Do not compose the entire answer in silence and send it in one final call. Don't manufacture delay or stream one character at a time. Short replies can be sent directly. If streaming fails, use a message and edits.
4. Before finishing a request that needs an answer, check the channel receipt for the actual answer: a persisted message or a finalized stream containing the result, not only task cards. If blocked, send the precise blocker and next action in chat. Clear your activity and finalize any stream you opened on both success and failure. Never treat a draft, status call, or CLI final text as a delivered answer. Updates that need no answer can stay silent; there is no fixed one-message-per-update rule.

Explain observable progress and useful decisions, never private internal reasoning. Keep responses concise by default. Preserve a returned message reference if you will edit the same message; replace temporary progress with the final result when requested. Don't clear a different task's shared status.

Telegram

Use native Bot API parameters; the runtime supplies chat_id and draft_id. Each example needs a fresh action_id, such as event42:typing:1.

• Receipt/activity: when advertised, use channel_typing with {"seconds":60} before work. Renew before the lease ends while still working, and stop with {"seconds":0} before your final send. Without that helper, use sendChatAction with {"action":"typing"}. It expires in at most five seconds, so refresh it between operations when useful.
• Streaming: call sendMessageDraft with {"text":"First useful part…", "can_stop":true}, then call it again with the entire updated text. The runtime keeps the same draft ID for this task so changes animate. Drafts expire after 30 seconds: refresh while composing and use sendMessage with the complete text to persist the answer. Empty text shows a “Thinking…” placeholder; it does not clear the draft. A draft disappears when its preview expires or you send a message. If asked to become quiet, stop refreshing it.
• Rich output: sendRichMessageDraft and sendRichMessage accept native rich_message. Use them when formatting helps, after checking the current Bot API format. Plain text is enough for most replies.
• One persistent message: sendMessage, save receipt.message_id, then editMessageText with that ID and each complete replacement text.
• If drafts are unavailable, use a short message and edits. If a send is uncertain, inspect the same action's receipt instead of duplicating it.
• Stop means stop this task; do not restart generation unless the owner asks.

Slack

The runtime supplies the destination, thread and streaming recipient. Keep status, progress and answer in that same thread, including a message that started in the root DM. Use channel_api with native Slack fields and a unique action_id per operation. Never describe a CLI-only update as a Slack reply.

• Working feedback: agents.sessions.setStatus with {"status":"processing"}. When advertised, channel_typing provides a bounded working-status lease and clears its own status at the end of the turn. It sends no chat message. If the workspace doesn't support it, use assistant.threads.setStatus with {"status":"Working…"}. If neither is supported, a brief message is enough.
• Current step: assistant.threads.setStatus accepts a short verb phrase such as {"status":"is comparing the options"} and optional loading_messages. Slack prefixes your app's name. Update it when the work changes; do not publish private reasoning or invent work. This legacy method clears after a reply and times out after two minutes, so renew during longer operations. The modern agents.sessions.setStatus supports lifecycle states, not custom step text. When the modern method is advertised, prefer a stream task for specific progress: a successful legacy status call does not guarantee the modern client displays that text. Do not rely on generic "working" for the entire job.
• Stream: chat.startStream with {"markdown_text":"First useful part…"}. Save receipt.message_id as ts. Call chat.appendStream with that ts and only the new markdown_text; end with chat.stopStream and that ts. For a multi-step job, start or append chunks instead of markdown_text: {"type":"task_update","id":"compare","title":"Compare the options", "status":"in_progress"} inside the chunks array. Update the same task ID to complete or error as appropriate. This shows Slack's progress timeline. Start the first task before doing that work, then append results as ready; creating an already-completed checklist at the end is not live progress. In a task stream, append answer text as a chunk too: {"type":"markdown_text","text":"First useful part…"}. Finish with chat.stopStream, passing ts and chunks that mark each open task complete or error, plus any remaining answer text. Close the task cards even if you sent the final answer separately after a stream failure. Never send both top-level chunks and markdown_text in one call. A short answer needs no task list.
• Use chat.postMessage and chat.update if streaming isn't available or the owner prefers one editable message. chat.update replaces the whole text; unlike appendStream it does not append.
• Clear your working status on success or failure: agents.sessions.setStatus with {"status":"active"}, or the legacy method with {"status":""}. Use suspended while awaiting the owner's input. Posting a message alone does not clear the modern processing state.

Images, voice and failures

Treat the supplied image and voice transcript as part of the owner's request, including a requested response style. Image attachments are available on the Computer; voice is transcribed using its configured speech-to-text service. Do not pretend to hear an unavailable recording or read an unavailable image. If attachment processing failed or a transcript is ambiguous, briefly explain what is missing and ask for that part again; continue anything you can do.

An incoming voice message does not require a voice reply. If the owner requests one, use an available audio-generation/upload tool and the channel's supported media method. Never invent a file ID, public media URL or a successful upload. If the installed tools cannot send audio, say so and offer the text instead.

Delivery and scope

Send/edit/stream actions each need a unique action_id. Reuse it only to inspect that exact operation, never with different content. Reusing the ID returns the saved result; it does not resend. An uncertain receipt is not permission to send a duplicate. Explain what may not have arrived and ask for recovery when needed. A rejected optional status/draft can fall back to a supported method; don't retry errors in a loop.

Credentials and recipients belong to the runtime. Do not read channel secrets, call provider endpoints around the tools, or change another conversation. Email goes only to the verified owner; its params are exactly subject (one line, at most 200 characters) and body (at most 20,000 characters). Email has no typing, streaming, or edit-after-send; send concise progress only if useful. Thread position is context, not approval. Use the provider's permission process for actions requiring approval. Ask any supplied clarification before doing ambiguous work. Independent jobs may continue in other sessions.

API references: Telegram Bot API, Slack streams, Slack session status.