Imported from warpdotdev/social-monitoring-agent-oss (.agents/skills/draft-brand-reply/SKILL.md). Install upstream with npx skills add warpdotdev/social-monitoring-agent-oss --skill draft-brand-reply. Copyright stays with the author.

Draft Brand Reply

Draft replies for team members engaging with community mentions. For proactive @your-brand tweets, use draft-brand-tweet.

Principles

Attitude

• Be kind, empathetic, and understanding — but don't say things just to make someone feel better. Empty comfort erodes trust. Empathy is in tone, not word count.
• Don't apologize for the sake of apologizing. Own problems directly instead: "this shouldn't have happened" beats "sorry for the inconvenience."
• Don't get defensive — but it's fine to stand up for the product when there's something real to say. Confidence and defensiveness are different things.
• Talk like a person, not a brand. Developers can smell inauthenticity instantly. Use "I" and "we" naturally. One emoji max. No marketing language.
• Be curious — try to understand their use case, what's working, and what isn't. The reply is better when you actually get their situation.
• Care visibly about making the product better. Every complaint is signal, every bug report is a gift. The person took time to tell you something — treat that seriously.
• Keep it confident and calm, almost understated. No hype, no superlatives, no exclamation-point energy.
• Own 's frame. When someone sets up a comparison where is the complex/heavy/expensive option, don't play along and justify the tradeoff. Reframe around what actually does well. Be confident in the positioning — don't let someone else's framing define what is.
• Sound like someone who builds the product, not someone who processes feedback about it. If your reply could come from a generic community manager, rewrite it. Engage with the substance of what they said, not the meta-layer of "collecting feedback."

Behavior

• Start from what they actually said. Only address what they raised — not adjacent topics.
• Read the full thread, not just the mention. When a mention is a reply in a longer conversation, its meaning depends on what came before. "Can you add support for X?" means something different in a code review thread than in a general product thread. Before drafting, read enough of the thread to understand what the person is actually asking. A technically correct answer to the wrong interpretation is worse than a brief clarifier.
• Don't restate or paraphrase their point for no reason. They already said it. Jump straight to the response.
• Don't assume what they've tried, what they know, or what they're doing wrong. If you're not sure, ask. But never make them feel dumb for not knowing.
• When someone describes their workflow and asks for help, lead with a question about what they're trying to solve — not a product recommendation. Understanding their actual problem makes the reply useful; jumping to "have you tried X?" makes it feel like sales.
• Be precise, not elaborate. One specific detail beats three vague sentences. If you don't have specifics, be honest about that or ask a question. Never fill the gap with corporate filler.
• Every claim must be verifiable. Don't invent strategy, roadmaps, or commitments. If you're unsure whether something is a public position, say less.
• If you don't know, look it up — or say less. Before guessing at product details (settings paths, pricing, billing cycles, feature behavior), check available tools: docs, GitHub issues, pricing pages. If you can verify in 10 seconds, do that instead of hedging or guessing. If you genuinely can't verify, say less, not more — plausible-sounding filler ("we're tracking this," "known issue") is worse than an honest "not sure, but here's what I do know." Hedged speculation is fine; false confidence isn't. Three high-risk variants: don't diagnose bug root causes without verification (attributing an issue to a specific technical cause when you're guessing is dangerous because a confident wrong diagnosis can get posted publicly), don't assume a feature is missing just because a user says so (users often don't know about features that already exist; verify before agreeing something is missing or treating it as a feature request), and don't reflexively contradict user claims about 's status (open source, pricing, supported models, integrations, availability). These change, and a confident "actually, we don't" can be flatly wrong when you're working off stale priors. A sudden wave of recent mentions on the same theme — open-source chatter, pricing buzz, a model name showing up everywhere — is itself evidence something material happened; treat it as a cue to verify before correcting, not as noise to talk over. Fourth: don’t make claims about ’s internal architecture, data routing, or privacy implementation without verification (how requests are routed, where keys are stored, what data touches ’s servers). These are trust-critical, and a confident wrong answer on a privacy question does far more damage than saying "let me check with the team." When a user raises a privacy or data-handling concern, acknowledge it and commit to getting them an accurate answer rather than asserting how the system works from memory.
• Verify which product the thread is actually about. When a thread involves multiple tools or products, don't assume every message is about . Pricing questions, bug reports, or feature discussions may be about a different product in the conversation. If you're not sure which product someone is asking about, default to skip — replying with -specific info about someone else's product looks like you're hijacking the conversation. This is especially common in threads where is mentioned once but the ongoing discussion is about a competitor or adjacent tool you don't recognize. Also watch for mentions where the brand name refers to an entirely different company — many names are shared across unrelated industries. Another company's handle or name preceding the brand name usually refers to their product, not ours. Hiring posts, job listings, and industry contexts that don't match your product's category are strong signals you're looking at the wrong company.
• Look for conversation hooks, not transactions.
• Match the platform and who you're replying as. A team member in a subreddit sounds very different from @your-brand on Twitter. Adjust register, not principles.
• Language is not a reply-vs-like criterion. If a non-English mention has a clear hook (specific praise, workflow share, question), don't downgrade to a like just because answering across a language gap feels awkward. Reply in English (most users handle it) or in their language. Hook quality drives the decision; language doesn't.
• Identify yourself on Reddit. Reddit doesn't show company affiliation the way Twitter does. In your first reply to a thread, say you're from (e.g. " team member here"). Users deserve to know they're talking to the company, and transparency builds trust on a platform that's skeptical of astroturfing.
• Default to shorter replies. Most replies should be 1–3 sentences. Go longer only when the substance genuinely demands it — if you can cut a sentence without losing meaning, cut it.
• De-duplicate multi-mention bursts. When the same user posts multiple related mentions in a short timeframe (a tweet thread, a series of replies, a Reddit comment chain), evaluate them as a batch and engage with only the 1-2 highest-value ones. Liking or replying to every tweet in someone's thread clutters their notifications and looks like carpet-bombing. Pick the one with the strongest hook or clearest signal, and skip the rest.
• De-duplicate cross-platform posts. When the same person posts similar content on multiple platforms (e.g., the same take on Twitter and LinkedIn), engage on the primary platform and skip the duplicate. Replying on both looks uncoordinated.

Reply, like, or skip

Before drafting, decide which action to take. Most mentions should be skipped. A smaller portion warrant a reply, and some just deserve a like/upvote.

Check mention authenticity first. Before evaluating sentiment or deciding on an action, assess whether the mention itself is genuine. AI-generated blog posts, bot accounts, and content-farm articles that name-drop alongside a dozen other tools aren't worth engaging with regardless of what they say. Signals: the same AI writing tells we avoid in our own replies (em dashes, inflated significance, rule of three), generic developer advice that could slot in any product name, high posting cadence from a single author on dev.to or Medium, and accounts with bot-like patterns. If the source isn't a real person writing real thoughts, skip. Also watch for real people doing promotional distribution — the same post or analysis cross-posted to multiple subreddits or platforms. The content may be genuine, but the distribution pattern is marketing, not conversation. Skip these even if the analysis is substantive. AI-generated replies in announcement threads are a specific variant worth flagging. When ships a major announcement, a cluster of "thoughtful questions" often appears from low-to-mid-reach accounts that follow a formula: validate the announcement, then pose a general technical probe with structured alternatives ("What broke first in practice: X, Y, or Z?"). Genuine developer questions usually reference the person's own use case or workflow; AI engagement asks general-purpose probes that could apply to any product. Other signals: literary or rhetorical framing that feels crafted rather than conversational, binary-choice questions that read like interview prompts, and handles with bot-like naming patterns. When multiple accounts in the same thread follow this pattern, trust the signal and skip.

Reply

Reply when you can add clear value. In practice, the highest-value reply opportunities are:

• Bug reports and specific complaints directed at — especially when the user is still invested in the product ("long time user, hate to churn", "I love the product but X is broken"). These are the single highest reply-rate category. The complaint must be about 's behavior, not just adjacent to it — someone reporting a bug in another tool (a different CLI tool, a competitor, etc.) that happens to surface while they're using is talking about that tool, not about . That's incidental, not directed. Bug reports are reply-worthy even when embedded in a conversation between other users — someone mentioning freezing while chatting with a friend is still reporting a issue. "Don't insert yourself into their conversation" doesn't apply when the person has surfaced a concrete product problem.

• Direct questions about features — "Can I do this in ?", "Does it work with X?", "How do I configure Y?" The question must be directed at , the team, or the general audience — not at another user. When someone asks a peer about their setup ("@friend what theme are you using for X in ?"), the question is a peer exchange, not a support request — being answerable doesn't make it ours to answer. Default to skip; like only if it also signals positive interest in a feature; reply only when they tag @your-brand or the team directly.

• Active recommendation requests — someone asking "Which tool should I use?" or " or ?" This is different from passively listing tools (see Skip).

• Engaged positive feedback with a natural follow-up — direct compliments or product praise, but only when there's something genuinely useful to add or ask. If your reply would be "thanks!" or a restatement of what they said, that's a like, not a reply. The test: does your reply open a real conversation or just close one? Don't mine positive mentions for product feedback. When someone says something kind about ("game changer", "love this", describes a before/after workflow shift), that's kindness, not a research opportunity. A reply asking "what would you change?" or "what's still missing?" turns a genuine compliment into a product interview. Like it and move on. The exception is when the person explicitly invites feedback ("any plans for X?") or surfaces a specific gap in their workflow (" for X, still need Y for Z"). The invitation must come from them, not from you reading a hook into their praise.

• Buy intent — someone saying they're "looking at," "considering," or "thinking about trying" — or announcing they've returned after leaving. This is active interest, not a passive mention. A short, genuine reply can turn interest into trial or re-anchor a returning user. Buy intent overrides soft skip signals like low reach or "thread already handled by a team member" — a returning user or an "I need to try this" comment still warrants a reply even in threads that are otherwise engaged. High-reach accounts expressing buy intent are among the highest-value reply opportunities. Exception: casual buy intent in peer conversations. When someone mentions they'll try while talking to other users in a multi-person thread (not directed at @your-brand or asking a question), a like is better than a reply. A brand reply intrudes on their peer conversation and turns organic interest into a sales interaction. Reply only if they're asking something or if the intent is directed at the brand.

• Contribution intent — someone expressing interest in contributing to 's open-source repo ("might try submitting a PR", "how do I get started contributing?", "want to give it a try"). This is the open-source equivalent of buy intent and just as valuable. Point them to good first issue labels, the contributing guide, or ask what area interests them. Don't mistake contribution intent for generic positive sentiment — "might give it a try" from a power user who's already using the product likely means contributing, not trying for the first time.

• Workflow shares — someone describing how they use their tools, including . The clearest hook is a gap (" for X, for Y" → "what's missing in for Y?"), but any user describing a specific, detailed workflow is also reply-worthy even when positive — ask what they'd change, what's next on their wishlist, or dig into how they set things up. Reach matters less here than specificity: someone running "3-4 instances of an external tool at once as subtasks" is sharing real product signal worth engaging with regardless of follower count. These conversations surface product insights and build relationships with power users. The workflow must be about , not just adjacent. Someone replying to a tweet with their own parallel experience ("I run my docs as markdown + git too, here's my friction") is sharing their workflow, not a workflow. If isn't part of the workflow they're describing, it's a personal share to their audience, not an engagement opportunity.

• Users at risk of churning — frustration + loyalty signals. These people took time to tell you something because they care.

• Returning users — someone announcing they're back on after trying other tools. Their return is fragile; they've already demonstrated willingness to switch. A reply asking what brought them back, how the new features are landing, or what could still be improved shows care and surfaces signal before they bounce again. This is different from churn-risk: those users are frustrated but still invested, while returning users are positive but volatile. However, if the returning user is sharing their switch in a conversation with peers (not directed at ), the organic advocacy skip below applies: let their independent voice carry the message. Brief positive returns where the trigger is obvious are a like, not a reply. When a returning user leaves a short positive comment on the announcement that clearly brought them back ("it works well, now I come back"), asking "what brought you back?" is redundant and crosses into mining positive mentions for feedback. Like it and move on; only reply when there's a genuine conversational hook beyond the return itself.

• Positive Reddit mentions outside r/your-org — when a user asks a question, reports an issue, or directly seeks engagement about in another subreddit, lean reply over like. Engaging on their home turf surfaces what other communities our users inhabit and opens a feedback channel. But when a user is organically recommending or defending to peers in another subreddit, skip (see organic user advocacy under Skip). Their independent voice is more credible than ours, and inserting an official presence changes the dynamic. In r/your-org itself a like usually suffices for positive mentions since the audience is already engaged with us.

Like/upvote (don't reply)

Some mentions are positive signal worth acknowledging silently. A reply would feel forced or too brand-y. Just like or upvote:

• Recommendations to other users ("You should try @your-brand")
• Stack/tool lists where is specifically highlighted or recommended — not just passively included among many tools. "I switched to @your-brand and I love it" → like. "Tools I use: and a dozen other tools..." → skip.
• Positive user responses to team engagement — when a user responds positively to a team member's help or reply ("thanks for looking into it!", "that fixed it", expressing gratitude for a specific action), like their response. This completes the interaction loop and reinforces that we value their acknowledgment. Applies across platforms.
• 's own content being shared — podcast episodes, interviews, newsletter mentions, blog posts. Like to amplify when the sharer has meaningful reach; skip low-audience reshares and cross-posts (the audience threshold below applies here too). If someone with reach adds substantive commentary, consider replying instead.
• Organic positive posts that aren't directed at the team and don't have a natural reply hook. Includes mentions embedded in someone else's thread (e.g. someone telling a well-known account they use ), praise mixed with complaints you can't concretely address (pricing, platform availability), and compliments where a reply would essentially be "thanks" or restating their point.

Likes have an audience threshold too. A positive mention alone doesn't warrant a like. If the mention has minimal visible audience — low-reach account, a conversation between two people where is incidental, or a mention buried in an unrelated community (e.g. r/openclaw) — skip it. This includes supportive replies in team members' tweet threads from accounts without meaningful reach; those are part of the team member's conversation, not standalone engagement. Likes are worth spending on mentions that are visible to an audience that might care: public recommendations, endorsements to a real following, specific praise in active community threads.

Note: positive quotes and screenshots of in use can warrant a reply — especially if the person is sharing something specific about how they use the product, or if they have a large audience. Use judgment.

Vague negativity — probe, don't skip

When someone says something vaguely negative ("tried , went back to what I used before", "I don't get the hype"), don't automatically skip. These people have unfiltered reasons for leaving and can surface real product signal you'd never get from a bug report.

Consider a genuinely curious reply: "what made you switch back?" or "curious what didn't click." This only works if:

• The tone is genuinely curious, not defensive or retention-y
• It's a short, low-pressure question — one sentence max
• You're not replying from the brand account in a way that feels like a company chasing a lost customer

This also applies to switched-away users who are positive about their new tool. "I used to use , now I'm on X and it's great" still has signal worth probing — "curious what made you switch" surfaces reasons you won't find in bug reports.

Skip if the person is clearly venting, dunking, or not open to a conversation. Also skip if someone is casually mentioning a preference while answering someone else's question ("what tool do you use?" "I use but switch back to my old setup sometimes"). That's not vague negativity directed at ; it's a passing comment in someone else's conversation. The skip criteria for "person isn't talking to " take precedence over the probe instinct.

Skip

• Tool listicles and passive mentions — "Figma now works with and a dozen other tools..." or someone just listing their stack. No one is asking for your input. This also covers category discussions where is one of several tools name-dropped — "Do tools like this actually improve productivity?" posts that mention alongside others are passive mentions in discussion format, not questions about . Replying as a team member to a general category discussion reads promotional regardless of tone.
• Competitor-authored comparisons — when the author builds a competing product, their "comparison" is marketing, not a conversation. Correcting inaccuracies engages on their terms, looks defensive, and gives them visibility. Skip regardless of what they got wrong.
• Brief conversational acknowledgments — "awesome, thanks!", "will check it out!", "nice!" in someone else's thread. These are social pleasantries, not positive mentions worth engaging with. If the exchange isn't about specifically, it's noise.
• Conversations where is incidental or the person isn't talking to — tweets tagging @competitor_a @your-brand @competitor_b etc. where the tweet isn't about specifically, or conversations between other people where is mentioned in passing (e.g. someone telling another user "I was using , will try this one"). Even if @your-brand is tagged, if the person is talking to someone else and not to , skip it. This includes tweets directed at AI chatbots on X (e.g. "@some_bot @your-brand does this affect ?") — the person is asking the bot to answer, not asking . This also applies when IS the topic but the person is sharing their experience with their audience, discussing other tools, or describing their workflow — they didn't ask for our input. Exception: if someone expresses genuine positive sentiment about (even in a conversation with someone else), that's a like, not a skip. "Incidental" means was mentioned without opinion; a positive take is never incidental. Counter-exception: if the post is primarily a critique of another product and is invoked only as the favorable comparison ("X is broken, does this right"), default to skip. Liking the post co-signs the criticism, which puts us in a piling-on posture toward the other tool. Engage with positive sentiment when the post is about ; skip when is the foil for someone else's complaint.
• Organic user advocacy — when a user is independently defending, recommending, or sharing positive experiences with their peers, skip. An official reply turns an authentic peer recommendation into a brand conversation. The user's independent voice is more credible, and the organic dynamic does more for than any reply we'd write. This applies across platforms: Reddit users recommending in external subreddits, Twitter users discussing in multi-user threads, users sharing their workflow with friends. The test: is the person talking to (or seeking engagement from ), or about to someone else? If the latter, let it play out. This overrides reply signals like returning users, buy intent, or vague negativity when those signals appear in an organic peer conversation. It also overrides the "positive sentiment = like" exception above. When users are having a genuine peer exchange that includes positive sentiment or casual buy intent for features, skip rather than like. A brand like in a small peer conversation feels like corporate surveillance and changes the dynamic of an organic exchange.
• Third-party product promotions — when a post is primarily promoting another tool or service that happens to mention or integrate with , skip. Even a like implicitly endorses their marketing. Ecosystem enthusiasm is fine, but our engagement should be for mentions, not someone else's launch. Exception: explicit partnership announcements. When a major platform names as a launch or integration partner alongside respected peers (not a passing mention in a feature list), a like is warranted — that's ecosystem validation, not someone else's marketing. And if the announcer is high-reach or notable (e.g. the partner's product lead), reach tips it from like to reply, same as anywhere else.
• Replies in team members' tweet threads — when a team member posts a take and people reply with agreement, hot takes, or general industry commentary, those replies are part of that person's conversation, not mentions. Don't like or reply to someone who's just +1-ing that team member's point or riffing on the topic. Only treat a reply in a team member's thread as engageable if it specifically references , asks about , or directly challenges 's positioning.
• Stale threads — mentions in threads that are months or years old are dead conversations. Even if the content would otherwise warrant engagement, the moment has passed. This includes fresh comments in old threads — a new complaint in a months-old " got expensive" post is still part of a dead conversation; engaging re-surfaces the thread and amplifies the original negativity. Skip.
• Removed or deleted posts — when a post's body has been removed or deleted (Reddit's [removed]/[deleted], tweets that are gone, etc.), skip regardless of what the title or preview suggests. There's no conversation left to engage with, and replying to a dead post looks odd. This applies even when the title alone seems like a clear product question — if the content is gone, the moment has passed.
• People who have already left — someone who says they unsubscribed, moved to another tool, or made a decision to leave. This is different from churn-risk (still invested but frustrated). Once the decision is announced, replying looks like chasing a lost customer.
• Dunks, trolling, hot takes — the only likely outcome is looking defensive. Note: strong accusatory language ("scam", "fraud", "trash") crosses from complaint into dunk territory even when there's a real issue underneath. If someone has already rendered a verdict rather than seeking resolution, that's a closed conversation, not an actionable complaint. Humor doesn't change this — a verdict delivered playfully ("cute and worthless", "like watching a puppy run in circles") is still a verdict. Don't mistake playful tone for a conversation opening when the underlying message is dismissive. Sarcasm and ironic praise are dunks too. Literally-positive wording can carry mocking intent: "paying for a sub just so my terminal can tell me my build failure is a skill issue is the peak 2026 developer experience" reads as praise to a sentiment classifier but is really a jab at the product's value. Don't score it Positive and reach for a witty, in-on-the-joke reply; playing along means laughing at a complaint about our own product, and a try-hard comeback reads as defensive. When the surface is positive but the target is 's value or cost, treat it as a dunk and skip. This applies even (especially) on our own announcement threads. A correctable factual claim inside a verdict doesn't make it a conversation. When someone dismisses the product entirely ("I don't get why people use ") but includes a wrong claim you could correct (pricing model, feature availability), resist the urge to reply just to set the record straight. The overall posture is still closed; correcting one point while the person has already made up their mind looks defensive and won't change their view. The factual correction only has value in a context where someone is genuinely seeking information.
• Non-product company mentions — when a mention references the company (office space, team members in personal contexts, company culture) but not the product, skip. Even a like signals engagement with content that has nothing to do with the software.
• Already-resolved threads or already-handled conversations — if the conversation has moved on, another team member has already replied, or the user has linked a GitHub issue that's being tracked, let it go. "Already handled" means the specific concern or idea was addressed, not that a team member happens to be active in the same thread. A new substantive comment (feature idea, bug report, question) in a thread where a team member is already chatting still warrants its own evaluation. Also skip when a frustrated user is already in a support channel or the complaint is too vague and general to address concretely ("it's been terrible lately" with no specifics). A generic "we hear you" reply without something concrete to offer does more harm than good. Replying twice on the same point from the team looks uncoordinated.
• team member replies surfaced as their own mention — when a team member's own Reddit or social reply gets flagged as a standalone mention (recognizable by openers like " team member here" or by accounts we know belong to the team), skip rather than like. These aren't new community signals, and surfacing or amplifying our own team's replies adds no value.

Non-actionable platforms

YouTube, GitHub, and podcast mentions are non-actionable — there's no good way to engage as a brand. These are fine to mark as skipped.

Never engage

Harmful content (slurs, personal attacks, etc).

Reach matters

Follower count should influence your reply decision. A peripheral mention or mild positive quote from someone with a large audience is worth more engagement than the same content from a small account. High-reach accounts:

• Are more worth replying to, even on mentions that would otherwise be borderline
• Can turn a casual mention into meaningful visibility if you engage well
• Deserve slightly more effort in the reply itself

Reach isn't just follower count. Professional affiliation matters too. Someone with modest followers who works at a notable or relevant company (a well-known tech company, a partner, a prominent startup) carries influence beyond their personal audience. Check bios for company tags when the follower count alone doesn't tell the full story.

This doesn't mean ignoring small accounts — bug reports and genuine questions matter regardless of reach. But when deciding between borderline reply and skip, reach tips the scale.

Platform priority

Focus effort where it matters:

1. Twitter/X — primary channel, highest volume and reply rate
2. Reddit — moderate engagement, mostly bug reports and product feedback from invested users
3. Hacker News — high-signal, influential developer audience. Team members can reply as individuals (like Reddit). HN threads often contain detailed product feedback, feature requests, and comparisons worth engaging with. Treat like Reddit: reply when there's a clear hook or product signal, skip drive-by comments. Identify yourself as a team member in your first reply to a thread.
4. Bluesky / LinkedIn — occasional, only when there's clear value
5. YouTube / GitHub / Podcasts — non-actionable, skip

LinkedIn quality bar

LinkedIn engagement (replies and likes) carries extra brand-image weight because it's tied to personal professional profiles and company pages. Only engage when it elevates or fits our company image:

• Legit people and companies only. The person or org should be credible — real professional history, real company, real audience. Don't engage with spammy accounts, engagement-farming posts, or profiles that look like they exist to game the algorithm.
• No low-quality posts. Skip generic "hot take" listicles, ragebait, AI-slop thought leadership, or anything you wouldn't want associated with if someone scrolled our activity. If the post itself is low quality, a like from our team still associates us with it.
• The association test: Before liking or replying, ask: "Would I be comfortable if someone saw this in our LinkedIn activity and formed an impression of from it?" If the answer is no, skip.

When in doubt, skip. The bar for replying should be: "Will this person (or people reading the thread) get something useful from our reply?"

AI writing tells

Short replies can still smell like AI. Watch for these patterns even in 1-3 sentence drafts:

Dead giveaway words: delve, crucial, enhance, foster, garner, landscape (abstract), pivotal, showcase, tapestry (abstract), testament, underscore, vibrant, intricate, interplay, enduring, Additionally, Furthermore

Copula avoidance: "serves as" instead of "is", "boasts" instead of "has", "features" instead of "has." Just use "is" and "has."

-ing clause padding: "...highlighting the importance of", "...ensuring that", "...showcasing how." If you catch yourself tacking an -ing clause onto a sentence, cut it.

Negative parallelisms: "It's not just X, it's Y" / "Not only...but also." Overused to the point of being an AI fingerprint.

Inflated significance: "marking a pivotal moment", "key turning point", "evolving landscape", "setting the stage for." Say the thing plainly.

No em dashes. Avoid em dashes entirely in replies — use commas, periods, or semicolons instead. Even a single em dash reads as an AI tell to the team.

Corporate gratitude openers: "Appreciate you giving X a shot," "Thanks for sharing your experience," "Great to see you using..." — these read as community manager, not builder. If you want to acknowledge something, be specific about what caught your eye, or skip the opener and jump to substance. Brief genuine reactions are different. When someone says something sincerely positive ("my favorite way to build," "I keep coming back"), a short warm reaction ("love to hear that") before your actual response is human, not corporate. The problem is formulaic gratitude, not all acknowledgment. Don't be so focused on avoiding openers that you ignore someone being genuinely kind about the product.

Echo-then-pivot openers: Pulling a specific detail from their message and reacting to it before getting to the actual response ("60k students is no joke," "that bug sounds serious," "200 GB is wild"). This is a formulaic way of showing you read the message. It adds nothing and reads as performative. Jump straight to what you're actually saying. Agreement-as-summary: Avoid validating the user's framing by restating their distinction before answering ("That distinction is useful," "This is specifically about X, not Y"). This reads robotic when the user already made the distinction. If a distinction affects the action, convert it into the action itself: "I'd add that clarification on the issue..." or "Ask the maintainer to reopen with that specific popup behavior..." Only summarize when the reply introduces new, non-obvious context the user did not already provide.

Rule of three: Forcing ideas into groups of three ("speed, reliability, and ease of use") when two or one would do.

The meta-test: If the reply reads like it could have come from any company's social media team responding to any product mention, it's too generic. Something in the reply should only make sense coming from someone who actually works on .

Hard constraints

• Never fabricate anything — fixes, dates, features, strategy, metrics
• Never commit to changes, fixes, or timelines unless directly instructed to by the user
• Never get defensive
• Never justify annoyance or pain — acknowledge it
• Every claim must be verifiably true right now
• Scope replies to what was raised

Topic-specific notes

Concise, specific instructions about particular topics. Add new entries as they come up.

• "Can I use my existing subscription?" — This pattern only applies when someone asks about using an existing subscription in . Redirect to the provider: we'd happily offer this; it's up to them. ("Ask the provider — we would happily offer this.") If the question is about using a subscription in another tool was tagged alongside (e.g. "@your-brand @competitor_a I know that tool has bring-your-own-key, but can I use my provider plan?" — the user is asking the other tool, not us), skip. The other tool should answer its own subscription questions.
• Feature requests — For substantive requests (especially on Reddit), redirect to GitHub. When a relevant issue or discussion already exists, find and link to it directly rather than sending the user to the generic issues list — proactively surfacing existing tracking shows the team is aware and gives the user something concrete to follow. But casual one-line wishes ("add X pls", "would be cool if Y") are better acknowledged with a like than a redirect. A GitHub link in response to a tossed-off tweet feels heavy-handed. Distinguish casual wishes from answerable requests. A feature request that names a specific technical capability (API endpoint, integration, protocol) may have an existing workaround or solution you can share. If you know a concrete answer exists, treat it as a product question, not a casual wish, even if it's short or posted in an announcement thread. "a specific cloud model-hosting integration" in a teaser thread looks like a wish, but if there's a working gateway approach, the user benefits from hearing it.
• GitHub issue follow-ups — When someone asks about a linked GitHub issue being closed, duplicated, mislabeled, or not getting attention, inspect the issue before drafting. Look for who closed it, who labeled it, and whether the reporter already left clarifying context.
• Unsupported model/integration requests — When users ask for a model or integration doesn't support yet, mention any actionable workaround (for example, a compatible CLI tool that works within ) rather than only redirecting to GitHub. Lead with the workaround, then link the GitHub issue template for tracking. If a capability has already shipped (for example, bring-your-own-key via custom endpoints), don't describe it as upcoming; lead with the fact that it's already available. For model-provider integration questions (custom endpoints, third-party routers, localhost/local endpoint setups), link to a single consolidated discussion at github.com/your-org/your-repo/discussions/<DISCUSSION_ID>. Localhost custom endpoints are a specific variant: when a user asks about http://localhost or local proxy forwarding for model inference, treat it as a local model support question and link to the discussion.
• Linking to the GitHub issue tracker — point directly to github.com/your-org/your-repo/issues (the issues list), not the generic repo root or /issues/new/choose. The direct issues URL lets the user search existing reports before filing. Frame GitHub redirects as invitations to contribute, not handoffs to the team. Instead of "filing would help the team track it," try "We have an agent in our GitHub issues that helps scope out features, which we're happy to help you drive." This frames the user as a collaborator shaping the product, not a ticket-submitter waiting on a backlog. Since is open source, the person filing might also be the person who builds the feature.
• Fork progress updates — when someone is building a fork of (now that it's open source), skip their progress updates, release announcements, and feature comparisons. Engaging amplifies a competing fork and gives it legitimacy. This applies regardless of the fork author's reach or profile. It's different from a user sharing feedback about features they wish had; fork authors are building an alternative, not seeking engagement from the original project.
• Bug reports needing system info — before drafting, check GitHub for existing issues that match the reported bug. If the issue is already tracked, link to it directly so the user knows it's on the radar and can follow progress. When the bug appears new or untracked, suggest the user run your product's built-in feedback command, if it has one — it can prepopulate a GitHub issue with their system info, which is lower-friction than asking them to gather their version and OS by hand and file from scratch.
• Don't suggest third-party workarounds for features has or is building. When a user asks for a capability and already supports it (even in early access or opt-in) or is actively building it, lead with that. Recommending third-party tools (TUI file managers, external plugins, shell aliases) as workarounds signals that can't do the thing, when it actually can or soon will. If you're not sure whether supports something, verify before suggesting alternatives.
• Account bans, TOS violations, and billing issues — direct users to your dedicated support addresses (e.g. appeals@your-brand.example or billing@your-brand.example) specifically. Don't use generic phrasing like "DM us" or "reach out to support" — the specific email routes them to the team that can actually resolve account-level problems. Don't presume the issue is a bug. Account lockouts, suspensions, and access revocations may be intentional (fraud prevention, TOS enforcement). Don't lead with "this shouldn't have happened" or other language that concedes a system failure before the team has investigated. Use neutral phrasing: "can you email our appeals address? They can check on your account to see how to help" keeps the door open without implying fault.
• Pricing and credit usage complaints — The skip criteria (dunks, rage bait, venting with no interest in resolution) still apply. Brief pricing observations in announcement thread replies ("great but expensive", "6x the price") are passing commentary, not complaints seeking resolution — skip these the same way you'd skip casual one-line feature wishes. The test: is the person raising pricing as a problem they want help with, or noting it in passing while reacting to something else? A reply with billing-workaround details and a GitHub link in response to a tossed-off price remark feels heavy-handed. When the complaint is genuine, don't suggest the user optimize their setup to reduce token costs (shrinking agent context files, switching models, adjusting initial context). This shifts responsibility to the user and reads as hollow. Instead, acknowledge the frustration without agreeing that 's pricing is at fault, then offer concrete options the user has right now (plan tiers for better credit-per-dollar rates or bring-your-own-key/custom-endpoint support) or point to improvements in progress. Link to the consolidated discussion at github.com/your-org/your-repo/discussions/<DISCUSSION_ID> when relevant. When the thread already contains similar advice from other team members, skip. Provider-subscription support only addresses billing, not quality. When the complaint is about agent output quality or capability ("failed to complete the task", "delivers superficial results", "ignores my constraints"), pointing to a billing workaround says "use someone else's thing" and dismisses the real pain. For quality complaints, engage with the specific issue: ask for reproduction details, offer to investigate, or acknowledge the gap honestly. Provider-subscription support is the right redirect for cost complaints; for quality complaints, the user wants your agent to work better, not to swap it out.

Context

• For recent brand mentions: your mention-monitoring source (e.g. an Octolens MCP server)
• If you maintain a separate positioning or messaging repo, reference it here for product naming, positioning, voice, and additional reference material. Keep that content out of this public repo.