diff --git a/.opencode/commands/manager-update.md b/.opencode/commands/manager-update.md index ccc4cb4..8d64239 100644 --- a/.opencode/commands/manager-update.md +++ b/.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 diff --git a/.opencode/commands/standup.md b/.opencode/commands/standup.md index 35c32c2..f2b66f0 100644 --- a/.opencode/commands/standup.md +++ b/.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 diff --git a/.opencode/commands/translate.md b/.opencode/commands/translate.md index 7ba13e4..12b5fd7 100644 --- a/.opencode/commands/translate.md +++ b/.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 diff --git a/ai/context/people/jeff-dewitte.md b/ai/context/people/jeff-dewitte.md index e91cb51..837bbba 100644 --- a/ai/context/people/jeff-dewitte.md +++ b/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 diff --git a/knowledge/communication-rules.md b/knowledge/communication-rules.md index a599c20..c1ad591 100644 --- a/knowledge/communication-rules.md +++ b/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. diff --git a/prompts/manager-update.md b/prompts/manager-update.md index 10b4897..93c4fdf 100644 --- a/prompts/manager-update.md +++ b/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 diff --git a/prompts/mattermost-translation.md b/prompts/mattermost-translation.md index c824d80..94eaae3 100644 --- a/prompts/mattermost-translation.md +++ b/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: diff --git a/prompts/standup.md b/prompts/standup.md index bff7283..7740a23 100644 --- a/prompts/standup.md +++ b/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: