Technical Writing

<default_to_action> When writing technical content:

1. LEAD with value (what will reader learn/gain?)
2. SHOW, don't tell (specific examples, code, and numbers you measured or can source)
3. STRUCTURE for scanning (headers, bold, short paragraphs)
4. CUT ruthlessly (every sentence must earn its place)
5. BE honest about trade-offs
6. NEVER invent figures: every number, duration, and date traces to a source (tracker, benchmark, PR, release note). Missing a number? Write [number?] and ask, or describe what changed without one.

Blog Post Structure:

# Title (specific promise)

## Opening (2-3 paragraphs)
- Hook: The problem or insight
- Context: Why this matters
- Promise: What they'll learn

## Body (3-5 sections)
- One clear idea per section
- Support with examples/code/data

## Closing
- Key takeaway (1-2 sentences)
- Action reader can take

Before/After: ❌ "We implemented a comprehensive testing strategy..." ✅ "We moved exploratory testing into sprint planning. QE now pairs with devs during story refinement." </default_to_action>

Quick Reference Card

Core Principles

Principle	Bad	Good
Lead with value	"In today's landscape..."	"Here's what changed when we moved testing into refinement"
Show, don't tell	"We improved testing"	"Bugs found per sprint, before and after, from our tracker: [before]→[after]"
Be specific	"Performance improved"	"p95 response time before and after, with how and where it was measured"
Honest trade-offs	"This approach is best"	"TDD slowed our first features; here is what we got back, with the numbers we measured"
Source every figure	"Coverage jumped 40%" (from memory)	The figure plus where it came from, or no figure at all

Bracketed values are placeholders for your own measured data. Never fill them with plausible-sounding numbers.

Words to Cut