OpenSEO Web Content

Every page is for a specific reader. A blog post should leave them better at SEO. A product page should help them decide whether OpenSEO solves their problem. Judge every edit by one question: is this better for that reader? We are not writing to pass a review.

Write for the reader

• Say up front what the reader will get, in their terms.
• Organize around their job, not the source material. Interviews become a plan, not a roundup of quotes.
• Carry one real example through, with real numbers.
• Use lists instead of dense paragraphs: bullet points for things the reader needs to do or check, and numbered lists for steps in order.
• Give practical advice, even when it's messier than the official rules.
• Answer straight. "No" and "it costs money" are complete answers.

Cut what isn't for them

• Notes for whoever checks the draft: method footers, "verbatim" assurances, tool or API names, "re-checked on" dates.
• Hedges that protect the writer, and links or asides that interrupt.
• Anything that reads like an ad. A company used as an example is there to teach.

Don't make things up

That's the whole accuracy bar. Product capabilities, prices, quotes, and data must be real, so check product claims against the code. Framing, figures of speech, and opinions are the writer's call. Don't ask for disclosures or a source for every number. Never call OpenSEO simply "free."

Voice

Use the deslop skill for AI tells. When editing someone else's post, keep their voice and examples. In the playbook library, an approach is a "strategy," never a "play."

Run prettier on the files you touch.