Skip to content

Commit b9cb6a1

Browse files
committed
feat(slack): forbid fabricating mention tokens
Tighten the Slack-origin system prompt rule on user mentions: require that the `<@U…|displayname>` token come from the thread context verbatim, and explicitly forbid substituting the display name (or any other string) for the `U…` ID. Falls back to plain text when no labeled token exists. Follow-up to #2676: the agent learned the token's shape but invented the user ID — observed in a Slack reply rendering `<@paul|Paul D'Ambra>`, which Slack doesn't ping.
1 parent 755e840 commit b9cb6a1

1 file changed

Lines changed: 1 addition & 1 deletion

File tree

packages/agent/src/server/agent-server.ts

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1731,7 +1731,7 @@ You are replying in a Slack thread. Slack readers want short, skimmable answers
17311731
- This is a default, not a hard rule. If the user (or their saved memory) asks for more depth or a specific format, follow that instead.
17321732
17331733
# Mentioning users
1734-
When you want to ping a Slack user in your reply, copy their \`<@U…|displayname>\` token verbatim from the message context — Slack renders that as a real mention. Writing \`@displayname\` as plain text does NOT ping them.
1734+
To ping a Slack user, reuse a \`<@U…|displayname>\` token that already appears in the message context — copy it verbatim, including the \`U…\` ID. Do NOT construct a mention token from a name, and do NOT substitute the display name (or any other string) for the \`U…\` ID — \`<@Paul|Paul D'Ambra>\` is not a valid mention; only the form with the real ID like \`<@U02DXFTVDNE|Paul D'Ambra>\` is. If the person you want to refer to has no \`<@U…|displayname>\` token anywhere in the thread context, write their name as plain text instead of inventing one.
17351735
17361736
# Suggesting code changes
17371737
You can also open pull requests directly from this Slack thread. When the user's question describes a problem with a plausible code-side fix — a bug visible in errors or logs, missing or broken instrumentation, a broken funnel step traceable to UI code, a stale config that lives in a repo — end your reply with a one-sentence offer to open a PR for the fix and ask if they want you to proceed. Skip the offer for pure data lookups with no actionable code change (e.g. "what was DAU yesterday?"), and skip it when the fix would clearly live outside any repo you can reach.

0 commit comments

Comments
 (0)