← Back to PRs

#19056: feat(inbound-meta): expose sticker metadata in system prompt

by xuandung38 open 2026-02-17 08:58 View on GitHub →
size: XS
## Summary When a user sends a sticker on Telegram, include `file_id`, `emoji`, and `set_name` in the `inbound_meta` JSON payload within the system prompt. ## Motivation Currently, when a Telegram user sends a sticker, the agent has no way to identify which sticker set it belongs to or what emoji it maps to. This makes it impossible for agents to: - Send a sticker back from the same set - Log sticker usage patterns - React contextually to sticker messages The `Sticker` field already exists on `TemplateContext` (populated by the Telegram provider via `StickerMetadata`), but it is not surfaced in the inbound metadata block that agents see. ## Changes - **`src/auto-reply/reply/inbound-meta.ts`**: Added `sticker` object (with `file_id`, `emoji`, `set_name`) to the `inbound_meta.v1` payload, positioned after `message_id`. - Only included when `ctx.Sticker` is truthy (no impact on non-sticker messages). - No new dependencies or types needed — uses existing `StickerMetadata` interface. ## Example output ```json { "schema": "openclaw.inbound_meta.v1", "message_id": "1234", "sticker": { "file_id": "CAACAgIAAxkBAAI...", "emoji": "😂", "set_name": "Panpahehuoc" }, ... } ``` ## Testing - Tested in production with Telegram sticker messages - Non-sticker messages unaffected (`sticker` field is `undefined` and omitted from JSON) - 7 lines added, 0 removed <!-- greptile_comment --> <h3>Greptile Summary</h3> This PR adds Telegram sticker metadata (`file_id`, `emoji`, `set_name`) to the trusted `inbound_meta` system prompt payload. The implementation correctly accesses the existing `ctx.Sticker` field (already populated by the Telegram provider) and conditionally includes it in the JSON output when present. The change follows established patterns in the file: optional field with undefined when not applicable, proper positioning after `message_id`, and maintains the security boundary between trusted metadata and untrusted user content. - Exposes sticker metadata to enable agents to send stickers back from the same set - Uses existing `StickerMetadata` interface with correct property names (`fileId`, `emoji`, `setName`) - Follows the conditional inclusion pattern used throughout the file - No impact on non-sticker messages (field is undefined and omitted from JSON) <h3>Confidence Score: 5/5</h3> - This PR is safe to merge with no concerns - The change is minimal (7 lines), uses existing types and patterns, maintains backward compatibility, and correctly implements the feature. The sticker metadata is already validated and populated by the Telegram provider, and the conditional inclusion ensures no impact on non-sticker messages. The implementation follows the established code style and security model of keeping trusted metadata separate from user-controlled content. - No files require special attention <sub>Last reviewed commit: ad73db0</sub> <!-- greptile_other_comments_section --> <sub>(2/5) Greptile learns from your feedback when you react with thumbs up/down!</sub> <!-- /greptile_comment -->

Most Similar PRs