feat: Update communication prompts and rules for clarity and professionalism in US English

.opencode/commands/manager-update.md

@@ -2,7 +2,7 @@
 description: Draft or polish a Mattermost update for the current manager or stakeholder
 ---
 
-Draft a concise Mattermost message for the current manager or stakeholder in natural professional English.
+Draft a concise Mattermost message for the current manager or stakeholder in natural, manager-ready US English.
 
 Read:
 
@@ -10,6 +10,7 @@ Read:
 @ai/AGENTS.md
 @ai/context/project.md
 @ai/context/people/manager.md
+@ai/context/people/jeff-dewitte.md
 @ai/context/people/index.md
 @ai/state/current.md
 @ai/state/work-items.md
@@ -33,6 +34,10 @@ Requirements:
 - Use Context, Observation, Action
 - Clarify scope
 - Preserve technical meaning
+- Rewrite fully when needed so the result sounds like a fluent senior engineer wrote it
+- Separate the current issue from unrelated bugs, workarounds, and follow-up work unless the user clearly wants them combined
+- Prefer evidence-backed wording over intuition when context includes concrete findings
+- Make ownership explicit when relevant: XFlow vs consumer app vs service/configuration vs another framework
 - Mention auth state when relevant
 - Mention Jira IDs and approved titles when they materially improve clarity
 - Do not label something a regression unless the context supports it

.opencode/commands/standup.md

@@ -13,6 +13,8 @@ Read:
 @prompts/standup.md
 @ai/AGENTS.md
 @ai/context/project.md
+@ai/context/people/manager.md
+@ai/context/people/jeff-dewitte.md
 @ai/state/current.md
 @ai/state/work-items.md
 @knowledge/communication-rules.md
@@ -42,3 +44,4 @@ Return a standup that is:
 - concise
 - grounded in the latest context
 - safe to send without overstating certainty
+- written in natural US English that Jeff could forward without rewriting

.opencode/commands/translate.md

@@ -1,8 +1,13 @@
 ---
-description: Translate rough engineering notes into Mattermost-ready English
+description: Rewrite rough engineering notes into natural Mattermost-ready US English
 ---
 
-Translate and tighten the following rough notes into concise Mattermost-ready English:
+Rewrite and tighten the following rough notes into concise, natural, Mattermost-ready US English.
+
+Do not translate literally.
+Rewrite fully when needed so the result sounds like a fluent senior engineer wrote it.
+
+If the notes mix multiple issues, separate the main issue from unrelated bugs or follow-up work unless the user clearly wants them combined.
 
 $ARGUMENTS
 

ai/context/people/jeff-dewitte.md

@@ -46,3 +46,17 @@ Good updates usually clarify:
 - Jeff approvals can change what belongs in current state or work-item memory
 - Jeff feedback is often a signal to tighten wording before communicating externally
 - Jeff often asks for evidence, reproduction detail, and exact next action before approving external communication
+
+---
+
+## Repeated Coaching / Expectations
+
+- Test in the closest real consumer environment first when the issue is consumer-specific; use sample app mainly to rule ownership in or out
+- Do not open or socialize a PR as "ready" until the issue is fully resolved and no obvious follow-up bug has been introduced
+- Separate current-ticket scope from unrelated preexisting bugs; do not blur them in standups or status updates
+- Be explicit about environment, branch/build/version, account, flow entry point, and repro steps before concluding where a bug belongs
+- When blocked, keep reducing uncertainty with other available evidence sources instead of waiting passively
+- Fast admin/process actions matter: update Jira/status/comments promptly when others are visibly waiting on them
+- Prefer evidence-heavy communication: screenshots, videos, exact error text, branch/version, and direct comparisons to main/web/UIKit/Fid4 when relevant
+- Use polished native-sounding English for external-facing comments; avoid sending rough wording when a cleaner version is easy to produce
+- When a consumer issue may actually belong to another team/framework, document the finding clearly and route ownership instead of carrying it indefinitely in XFlow

knowledge/communication-rules.md

@@ -13,6 +13,32 @@ These rules keep standups, Jira notes, and Mattermost messages aligned with the
 - Separate external report from regression
 - Say whether behavior was confirmed in main when that comparison exists
 - End with the next action when writing status updates
+- Distinguish clearly between the current issue, unrelated preexisting bugs, workarounds, and follow-up work
+- Prefer evidence-backed statements over intuition when communicating status
+- Include branch, build, environment, account, flow, or entry-point details when they materially affect reproduction or ownership
+- Route ownership explicitly when the issue belongs to a consumer app, service/configuration, or another framework instead of XFlow
+- Do not present a fix as ready if it introduces a new bug or unresolved regression
+- Administrative/project-tracking updates should be prompt when others are visibly waiting on them
+
+---
+
+## English Quality Rules
+
+- Write in natural, professional US English that sounds like a fluent engineer wrote it
+- Prefer direct phrasing over literal or translated-sounding wording
+- Avoid unnecessary softeners or filler such as "actually," "I think" or "for now" unless they add real scope or uncertainty
+- If the message was originally rough or written by a non-native speaker, rewrite it fully instead of preserving awkward phrasing
+- If a sentence can be misunderstood by a manager, stakeholder, or consumer team, rewrite it before sending
+
+---
+
+## Repeated Senior Communication Lessons
+
+- Test in the closest real consumer environment first when consumer-specific behavior is under investigation, but use the sample app to rule ownership in or out quickly
+- Before escalating or concluding root cause, reduce uncertainty with available evidence: screenshots, videos, logs, code comparison, version checks, and parity checks across web/UIKit/SwiftUI/Fid4
+- Keep one issue per update unless a second issue is explicitly called out as separate scope
+- If blocked, communicate what was tried, what was ruled out, and the exact remaining question
+- Use Context, Observation, Action framing when possible so status is easy to forward without rewriting
 
 ---
 
@@ -22,5 +48,8 @@ These rules keep standups, Jira notes, and Mattermost messages aligned with the
 - "looks good"
 - "seems fixed"
 - "working now"
+- "it should be fine"
+- "for some reason"
+- "I think it's fixed" when evidence exists or is needed
 
 Use concrete statements instead.

prompts/manager-update.md

@@ -1,8 +1,8 @@
 # Manager Update Prompt
 
-Use the current state, today's log, and `ai/context/people/manager.md`.
+Use the current state, today's log, `ai/context/people/manager.md`, and `ai/context/people/jeff-dewitte.md`.
 
-Draft a Mattermost update for the current manager or stakeholder in concise professional English.
+Draft a Mattermost update for the current manager or stakeholder in concise, natural, professional US English.
 
 Requirements:
 
@@ -11,4 +11,8 @@ Requirements:
 - Clarify whether the issue is external behavior or regression
 - Mention auth state when relevant
 - Preserve the original technical meaning
+- Rewrite awkward or literal wording completely when needed
+- Separate the current issue from unrelated bugs, workarounds, and follow-up work unless the user explicitly wants them combined
+- Prefer evidence-backed phrasing when the context includes screenshots, logs, comparisons, or repro details
+- Make ownership explicit when relevant
 - Keep the message direct and short

prompts/mattermost-translation.md

@@ -9,6 +9,12 @@ Requirements:
 - Prefer concise wording
 - Keep the tone professional and direct
 - If the draft lacks context, infer only from workspace files and do not invent facts
+- Rewrite into natural US English; do not preserve awkward ESL or literal-translation phrasing
+- Make the message sound like it was written by a fluent senior engineer
+- Separate the main issue from unrelated bugs, workarounds, and follow-up work unless the user explicitly wants them combined
+- If relevant, make ownership clear: XFlow vs consumer app vs service/configuration vs other framework
+- Prefer explicit statements over vague reassurance; use concrete evidence when the notes include it
+- If a sentence could confuse a manager or stakeholder, rewrite it for clarity before returning it
 
 Output:
 

prompts/standup.md

@@ -1,6 +1,6 @@
 # Standup Prompt
 
-Use `ai/state/current.md`, `ai/state/work-items.md`, `ai/context/project.md`, `ai/context/people/manager.md`, yesterday's log, today's log if present, and the latest available Mattermost context.
+Use `ai/state/current.md`, `ai/state/work-items.md`, `ai/context/project.md`, `ai/context/people/manager.md`, `ai/context/people/jeff-dewitte.md`, yesterday's log, today's log if present, and the latest available Mattermost context.
 
 Generate a standup update for an iOS engineer working on Fidelity.
 
@@ -13,6 +13,9 @@ Requirements:
 - Mention Jira IDs and approved titles when they are available and clearly tied to the reported work
 - Prefer story-based reporting when the work maps clearly to a Jira item
 - Avoid vague phrases and generic progress language
+- Separate the main issue from unrelated follow-up work unless both are explicitly relevant today
+- Prefer evidence-backed statements over assumptions
+- Write in natural US English that Jeff can forward without rewriting
 - Keep it concise and ready to send
 
 Format: