Encourage Agents to Proactively Offer Sent Feedback

claude-plugins/sent/skills/sent-feedback/SKILL.md

@@ -1,18 +1,27 @@
 ---
 name: sent-feedback
-description: Reports user-authorized feedback about Sent MCP tools to the Sent team. Use when the user asks to report a bug, request a missing feature, pass along confusing results or praise, or agrees to report a tool gap the agent noticed. Feedback is read by Sent staff; it does not open a support ticket or return an answer. Do not trigger for a delivery investigation alone.
+description: Reports user-authorized feedback about Sent MCP tools to the Sent team. Use when the user asks to report a bug, request a missing feature, pass along confusing results or praise, or agrees to report a tool gap the agent noticed. Also use proactively when a Sent workflow hits meaningful friction the agent or user experienced, such as missing functionality, an error still unresolved after diagnosis, confusing results, repeated workarounds, or user frustration with Sent, to offer an optional report after the original task. Feedback is read by Sent staff; it does not open a support ticket or return an answer. Do not trigger for routine or expected errors, issues unrelated to Sent, a delivery investigation alone, or friction already offered for reporting.
 ---
 
 # Sent Feedback
 
-Use `feedback.send` only when the user asks to pass feedback to Sent or agrees to report a gap you noticed. Never send unsolicited reports, conversation transcripts, or automatic feedback after a tool error.
+Use `feedback.send` only when the user asks to pass feedback to Sent or accepts your offer to report friction, and only after they explicitly authorize the exact sanitized report. Never send unsolicited reports, conversation transcripts, or automatic feedback after a tool error.
+
+## Offer feedback after meaningful friction
+
+Sent wants to hear about friction even when the user would not think to report it. During any Sent workflow, notice meaningful friction that you or the user hit: missing functionality, an error that persists after diagnosis, confusing or contradictory results, repeated workarounds, or user frustration with Sent.
+
+1. Diagnose the friction and try to resolve it first with the skill that owns the task.
+2. If it remains meaningful, keep the original task first. At a natural pause or after answering, offer once in one sentence, for example: "Sent has no tool to cancel a scheduled send; want me to draft a feedback report for the Sent team?" Never hold the task on the answer.
+3. Do not offer for routine errors you resolved, expected restrictions such as validation, permission, compliance, balance, or rate limits working as documented, problems unrelated to Sent, or an issue already offered in this conversation. If the user declines or ignores the offer, drop it.
+4. Accepting the offer permits a draft, not a send. Prepare the report below and send only after confirmation.
 
 ## Prepare an authorized report
 
 1. Use client-managed OAuth 2.1/PKCE; never request or expose credentials. Identify the authenticated organization and effective Sender Profile. An organization grant may use the schema's optional `profileId` for an owned profile; a profile grant cannot use that selector. Reauthorize for another organization or a profile outside the grant.
 2. Choose `category`: `bug`, `missing_feature`, `confusing`, `praise`, or `other`.
 3. Write a plain-text `message` of at most 2000 characters describing the attempted task and observed result. Remove phone numbers, email addresses, message bodies, credentials, and other personal or customer data yourself. Server redaction is pattern-based and is not a substitute for minimizing the report.
-4. Optionally set `toolName` to an actual registered tool name. Unknown names are stored as null. Set `source` to `user` when the user wrote or requested the feedback, or `agent` when you noticed the gap; omission defaults to `agent`.
+4. Optionally set `toolName` to an actual registered tool name. Unknown names are stored as null. Set `source` to `user` when the user wrote or requested the feedback, or `agent` when you noticed the gap or offered the report; omission defaults to `agent`.
 5. Preview the exact scope, category, message, tool name, and source. Explain that Sent staff read the report. Require explicit confirmation immediately before the call; the user's explicit instruction to send this exact preview satisfies that requirement. If the report changes, obtain new confirmation.
 
 ## Receipt and limits

evals/sent-feedback.yaml

@@ -6,12 +6,39 @@ cases:
 - query: Report the confusing output from dashboard.deliverability to Sent after I review it.
   expect: trigger
   rationale: Authorized report preparation for a confusing tool result.
+- query: Sent still has no tool to cancel a scheduled send, so I worked around it by hand again. That's the third time this week.
+  expect: trigger
+  rationale: Missing functionality, a repeated workaround, and user frustration warrant a proactive offer to report.
+- query: We checked the account, scopes, and inputs, but templates.list still fails with an internal error, so I'll find the template in the dashboard instead.
+  expect: trigger
+  rationale: An error still unresolved after diagnosis warrants an optional report offer that does not block the workaround.
+- query: After matching the date range and timezone, dashboard.messages_sent and dashboard.deliverability still disagree on totals with no explanation.
+  expect: trigger
+  rationale: A confusing result that survives diagnosis warrants an offer to report after answering.
 - query: This tool error is annoying; diagnose it without sending a report.
   expect: no_trigger
-  rationale: An error alone is not authorization for feedback.
+  rationale: The user asked for diagnosis and declined reporting.
+- query: contacts.create_many just returned a validation error. What went wrong?
+  expect: no_trigger
+  rationale: A fresh error needs diagnosis by the owning skill before any feedback offer.
+- query: The send failed because a template variable was missing; I added it and it went through.
+  expect: no_trigger
+  rationale: A routine error that was resolved is not meaningful friction.
+- query: Why won't Sent let me send US SMS before my 10DLC campaign is approved?
+  expect: no_trigger
+  rationale: An expected compliance restriction belongs to sms-10dlc-registration.
+- query: My Postgres migration keeps timing out and it's driving me crazy.
+  expect: no_trigger
+  rationale: Frustration unrelated to Sent does not warrant a Sent feedback offer.
+- query: The scheduled-send cancellation gap hit us again, but I already said not to report it.
+  expect: no_trigger
+  rationale: A repeated occurrence of friction the user already declined does not warrant another offer.
 - query: Why did our SMS delivery rate fall yesterday?
   expect: no_trigger
   rationale: Delivery diagnosis belongs to messaging-performance-analyzer.
 - query: Investigate this send failure and report a sanitized bug to Sent.
   expect: ambiguous
   rationale: Use sent-messaging for investigation and sent-feedback for the authorized report.
+- query: I need tomorrow's scheduled send stopped, but there's no cancel tool and my last two workarounds failed. What can I do?
+  expect: ambiguous
+  rationale: sent-messaging owns the task; offer a report on the missing tool only after addressing it.

packages/sent/skills/sent-feedback/SKILL.md

@@ -1,18 +1,27 @@
 ---
 name: sent-feedback
-description: Reports user-authorized feedback about Sent MCP tools to the Sent team. Use when the user asks to report a bug, request a missing feature, pass along confusing results or praise, or agrees to report a tool gap the agent noticed. Feedback is read by Sent staff; it does not open a support ticket or return an answer. Do not trigger for a delivery investigation alone.
+description: Reports user-authorized feedback about Sent MCP tools to the Sent team. Use when the user asks to report a bug, request a missing feature, pass along confusing results or praise, or agrees to report a tool gap the agent noticed. Also use proactively when a Sent workflow hits meaningful friction the agent or user experienced, such as missing functionality, an error still unresolved after diagnosis, confusing results, repeated workarounds, or user frustration with Sent, to offer an optional report after the original task. Feedback is read by Sent staff; it does not open a support ticket or return an answer. Do not trigger for routine or expected errors, issues unrelated to Sent, a delivery investigation alone, or friction already offered for reporting.
 ---
 
 # Sent Feedback
 
-Use `feedback.send` only when the user asks to pass feedback to Sent or agrees to report a gap you noticed. Never send unsolicited reports, conversation transcripts, or automatic feedback after a tool error.
+Use `feedback.send` only when the user asks to pass feedback to Sent or accepts your offer to report friction, and only after they explicitly authorize the exact sanitized report. Never send unsolicited reports, conversation transcripts, or automatic feedback after a tool error.
+
+## Offer feedback after meaningful friction
+
+Sent wants to hear about friction even when the user would not think to report it. During any Sent workflow, notice meaningful friction that you or the user hit: missing functionality, an error that persists after diagnosis, confusing or contradictory results, repeated workarounds, or user frustration with Sent.
+
+1. Diagnose the friction and try to resolve it first with the skill that owns the task.
+2. If it remains meaningful, keep the original task first. At a natural pause or after answering, offer once in one sentence, for example: "Sent has no tool to cancel a scheduled send; want me to draft a feedback report for the Sent team?" Never hold the task on the answer.
+3. Do not offer for routine errors you resolved, expected restrictions such as validation, permission, compliance, balance, or rate limits working as documented, problems unrelated to Sent, or an issue already offered in this conversation. If the user declines or ignores the offer, drop it.
+4. Accepting the offer permits a draft, not a send. Prepare the report below and send only after confirmation.
 
 ## Prepare an authorized report
 
 1. Use client-managed OAuth 2.1/PKCE; never request or expose credentials. Identify the authenticated organization and effective Sender Profile. An organization grant may use the schema's optional `profileId` for an owned profile; a profile grant cannot use that selector. Reauthorize for another organization or a profile outside the grant.
 2. Choose `category`: `bug`, `missing_feature`, `confusing`, `praise`, or `other`.
 3. Write a plain-text `message` of at most 2000 characters describing the attempted task and observed result. Remove phone numbers, email addresses, message bodies, credentials, and other personal or customer data yourself. Server redaction is pattern-based and is not a substitute for minimizing the report.
-4. Optionally set `toolName` to an actual registered tool name. Unknown names are stored as null. Set `source` to `user` when the user wrote or requested the feedback, or `agent` when you noticed the gap; omission defaults to `agent`.
+4. Optionally set `toolName` to an actual registered tool name. Unknown names are stored as null. Set `source` to `user` when the user wrote or requested the feedback, or `agent` when you noticed the gap or offered the report; omission defaults to `agent`.
 5. Preview the exact scope, category, message, tool name, and source. Explain that Sent staff read the report. Require explicit confirmation immediately before the call; the user's explicit instruction to send this exact preview satisfies that requirement. If the report changes, obtain new confirmation.
 
 ## Receipt and limits

plugins/sent/skills/sent-feedback/SKILL.md

@@ -1,18 +1,27 @@
 ---
 name: sent-feedback
-description: Reports user-authorized feedback about Sent MCP tools to the Sent team. Use when the user asks to report a bug, request a missing feature, pass along confusing results or praise, or agrees to report a tool gap the agent noticed. Feedback is read by Sent staff; it does not open a support ticket or return an answer. Do not trigger for a delivery investigation alone.
+description: Reports user-authorized feedback about Sent MCP tools to the Sent team. Use when the user asks to report a bug, request a missing feature, pass along confusing results or praise, or agrees to report a tool gap the agent noticed. Also use proactively when a Sent workflow hits meaningful friction the agent or user experienced, such as missing functionality, an error still unresolved after diagnosis, confusing results, repeated workarounds, or user frustration with Sent, to offer an optional report after the original task. Feedback is read by Sent staff; it does not open a support ticket or return an answer. Do not trigger for routine or expected errors, issues unrelated to Sent, a delivery investigation alone, or friction already offered for reporting.
 ---
 
 # Sent Feedback
 
-Use `feedback.send` only when the user asks to pass feedback to Sent or agrees to report a gap you noticed. Never send unsolicited reports, conversation transcripts, or automatic feedback after a tool error.
+Use `feedback.send` only when the user asks to pass feedback to Sent or accepts your offer to report friction, and only after they explicitly authorize the exact sanitized report. Never send unsolicited reports, conversation transcripts, or automatic feedback after a tool error.
+
+## Offer feedback after meaningful friction
+
+Sent wants to hear about friction even when the user would not think to report it. During any Sent workflow, notice meaningful friction that you or the user hit: missing functionality, an error that persists after diagnosis, confusing or contradictory results, repeated workarounds, or user frustration with Sent.
+
+1. Diagnose the friction and try to resolve it first with the skill that owns the task.
+2. If it remains meaningful, keep the original task first. At a natural pause or after answering, offer once in one sentence, for example: "Sent has no tool to cancel a scheduled send; want me to draft a feedback report for the Sent team?" Never hold the task on the answer.
+3. Do not offer for routine errors you resolved, expected restrictions such as validation, permission, compliance, balance, or rate limits working as documented, problems unrelated to Sent, or an issue already offered in this conversation. If the user declines or ignores the offer, drop it.
+4. Accepting the offer permits a draft, not a send. Prepare the report below and send only after confirmation.
 
 ## Prepare an authorized report
 
 1. Use client-managed OAuth 2.1/PKCE; never request or expose credentials. Identify the authenticated organization and effective Sender Profile. An organization grant may use the schema's optional `profileId` for an owned profile; a profile grant cannot use that selector. Reauthorize for another organization or a profile outside the grant.
 2. Choose `category`: `bug`, `missing_feature`, `confusing`, `praise`, or `other`.
 3. Write a plain-text `message` of at most 2000 characters describing the attempted task and observed result. Remove phone numbers, email addresses, message bodies, credentials, and other personal or customer data yourself. Server redaction is pattern-based and is not a substitute for minimizing the report.
-4. Optionally set `toolName` to an actual registered tool name. Unknown names are stored as null. Set `source` to `user` when the user wrote or requested the feedback, or `agent` when you noticed the gap; omission defaults to `agent`.
+4. Optionally set `toolName` to an actual registered tool name. Unknown names are stored as null. Set `source` to `user` when the user wrote or requested the feedback, or `agent` when you noticed the gap or offered the report; omission defaults to `agent`.
 5. Preview the exact scope, category, message, tool name, and source. Explain that Sent staff read the report. Require explicit confirmation immediately before the call; the user's explicit instruction to send this exact preview satisfies that requirement. If the report changes, obtain new confirmation.
 
 ## Receipt and limits