Technical Writing Studio

Translates raw engineering release notes - commits, tickets, PR titles - into a user-facing changelog grouped as New, Improved, and Fixed, with a highlights section on top, benefit-first phrasing in the user's vocabulary, bugs described by their symptoms, and internal-only churn cut and flagged. Use when someone says "write the changelog for this release", "turn these commit messages into release notes users can read", "announce what shipped this week", or their changelog currently reads as internal jargon. Do NOT use for auto-generating a technical changelog from git history for developers - use changelog-generator instead.

Writes user-facing help-center articles - verb-first how-to guides, symptom-organized troubleshooting pages, and FAQs - with one task per article, exact UI labels, and a stated success result. Use when someone asks "write a help article for...", "document how users reset their password", "turn these support tickets into a troubleshooting page", or "our help center articles are confusing, rewrite this one". Do NOT use for internal team procedures and SOPs - use process-doc instead; for on-call operational runbooks, use runbook-writer; for internal knowledge-base articles aimed at support agents, use kb-article-writer.

Designs REST API surfaces - resource naming, HTTP method and status-code semantics, error shapes, pagination, and filtering - and delivers an endpoint spec a consumer can build against without asking questions. Use when someone asks "how should I name this endpoint", "what status code should this return", "should this be PUT or PATCH", "how do I paginate this list", or is reviewing an API before it ships to external consumers. Do NOT use for planning breaking-change rollouts and deprecation windows - use api-versioning-strategist instead; for GraphQL type and resolver design - use graphql-schema instead; for generating client SDKs from an existing spec - use api-client-generator instead; for designing inbound webhook endpoints - use webhook-receiver-hardener instead.

Documents recurring processes as step-by-step SOPs with decision points, edge cases, and a named owner, so anyone can run the process correctly without asking. Use when someone asks "write an SOP for this", "document our onboarding process", "this only lives in one person's head", or wants to delegate a recurring task safely. Do NOT use for incident-response or on-call operational runbooks - use runbook-writer instead; for customer-facing product documentation, use help-documentation.

Structures and writes authoritative B2B whitepapers - a standalone executive summary, a data-sized problem statement, methodology, evidence-driven findings, recommendations, and a soft call to action - flagging every claim that needs a real citation. Use when a marketer asks "write a whitepaper on this topic", "turn our research into a lead-gen asset", "make this credible enough for executives", or a draft reads like a product pitch instead of analysis. Do NOT use for customer-story-driven proof - use case-study-builder instead; for policy audiences, use policy-brief.