Report to the Owner

Transform a blocker — a bug, a missing capability, or a design that doesn't extend to a new use case — into a ready-to-send message that gives a zero-context owner the situation, what's in the way, and the proposed change. Enough for them to act, without making them rediscover what the user already worked out.

When to use

The user is blocked by code, a service, or a package owned by someone else — a bug, a missing feature, or a feature whose current design doesn't accommodate the user's use case. They are not asking for advice — they have a candidate change in mind. The intent is "FYI + please address," not "what do you think?" Recipient is a peer or owning team — chat/DM, not a public bug tracker or support channel.

Tone

• Casual, direct, peer-to-peer — assume they saw each other earlier today.
• No greetings, sign-offs, or email-style formality.
• Confident but not accusatory — "here's what I'm seeing and why I think it's X," not "your code is broken."
• Leave room for the owner to disagree with the diagnosis or the proposed direction without making it awkward to walk back.
• Natural openers are fine: "Heads up — I think there's a bug in…", "Running into something in package X…", "Trying to use [X] for [use case] and I think the API needs [change]…", "Hit a wall extending [feature] for [use case]…"

Structure (in this order)

1. What the user is working on — one or two sentences so the owner understands why the user hit this surface.