Enforce Sentry Blog Writing Standards

A blog-writing style enforcement skill modeled on Sentry's own standards, applicable whether the writer is an engineer's first post or a marketer's product announcement. Its bar: every post should be something a senior engineer would share in their team's Slack or reference in a technical decision. It defines the target voice - a senior developer at a conference afterparty explaining something they're genuinely excited about: smart, specific, a little irreverent, deeply knowledgeable, using "we" and "you" as a conversation rather than a corporate blog, press release, or AI-generated summary - and bans nine specific phrases or patterns outright: "we're excited or thrilled to announce," "best-in-class," "industry-leading," or "cutting-edge," "seamless" or "seamlessly," "empower, leverage, or unlock," "robust" without explanation, "at [Company], we believe," "streamline," filler transitions like "that being said" or "it's worth noting that," and "in this blog post, we will explore." The opening's first two to three sentences must state either the problem or the conclusion, never background or hype, illustrated with a real good-versus-bad pair contrasting a specific, concrete opener against a generic "always looking for ways to improve" one. Structure follows the reader's actual questions in order: what problem this solves, how it actually works technically as the bulk of the post, what trade-offs or alternatives existed since that separates good from great, and how to use or try it, with engineering deep-dives additionally covering what was tried that didn't work and known limitations. Section headings must convey information rather than being generic labels like "Background" or "Results" - a weak "Architecture" heading should become something specific about the actual technical approach. Technical quality standards require numbers over adjectives for any performance claim rather than vague language like "significantly reduced," code that's actually tested and includes imports, configuration, and context with comments explaining why not what, diagrams with real service names for any system with more than two interacting components, and honesty over hype: acknowledging limitations, labeling beta features as beta, and never overstating what a feature does, with an explicit example distinguishing a feature that "suggests" a root cause from one that "finds" it. Titles must make a specific claim, tell a story, or promise a specific payoff rather than being vague announcements. The closing should end with something useful, a docs link, a way to try it, a feedback channel, never generic hype or a recap. A post-types table maps five formats - Engineering Deep Dive, Product Launch, Postmortem, Data/Research, Tutorial/Guide - to their goal and required byline role, and a "would I share this?" test gates whether a draft needs more depth or belongs in the changelog instead, with five qualifying content types listed. Ten non-negotiables close the skill, including never publishing under an anonymous team byline, never shipping broken code, always including a diagram for multi-component systems, and always explaining what alternative wasn't chosen and why. A two-part review process, Technical Review for factual accuracy and Editorial Review for voice and structure, plus a final byline, links, and duplication check is specified for anyone editing a draft.

Use when drafting or editing a Sentry blog post - technical storytelling, product announcements, or engineering deep-dives - and the goal is opinionated, specific, technically credible content rather than generic marketing copy. Not for changelog entries, which the skill explicitly says belong in the changelog rather than the blog, or for content using an anonymous team byline - a real person's name is a non-negotiable requirement.

Input is a blog post draft or topic to write about. Output is either a finished draft meeting the voice, structure, and technical-quality bar, or, when reviewing an existing draft, specific feedback quoting the weak passage, explaining why it's weak, and rewriting it to the standard, checked against the Technical Review, Editorial Review, and Final Check checklists.

None - this is a self-contained editorial style guide with no external tool dependencies, built around Sentry's own house voice and post-type conventions.

Engineers and marketers writing or editing a Sentry blog post who need Sentry's specific voice, banned-phrase list, and structural rules enforced consistently, rather than writing generic tech-marketing copy.