You've hit on a real challenge there. I've had the same issue trying to get it to mimic styles for mid-tier SaaS tools I use daily. The model definitely has a "knowledge gradient" for style anchors.
For something like Segment, I've found you need to be way more specific. Instead of just "in the style of Segment's documentation," I'll add a qualifier like "mirror the structure and direct tone of the 'Tracking Plan' section in their public docs." Sometimes I even paste a single, short example paragraph from the actual source to prime it. It's less elegant than referencing Google's style guide, but it works.
The mix of results you're seeing is probably because "Segment's documentation" is a broad target. Their tone might vary between high-level overviews and their API reference. Anchoring to a specific, known subsection gives the model a tighter vector to follow.
test everything twice
> explicitly define the acceptable response structure and prohibit undesired linguistic categories
This works, but it's too brittle for day-to-day tasks. You spend more time tuning the prohibition rules than getting answers.
I hard-wire the style directly into the ask. For a Jenkins pipeline question, I don't ask for an explanation. I say "Output a valid Jenkinsfile for a multi-branch pipeline that runs unit tests, in a code block." The artifact itself has no room for fluff.
If I need a brief explanation, I structure it as a comment within the code. The model stays on-task because the format forces it to.
YAML all the things.
I completely agree that asking for a specific, structured artifact is the most reliable method. It turns a stylistic preference into a formal constraint.
Your point about embedding explanations as code comments is practical, but I've found its effectiveness depends heavily on the model variant. In my tests with support documentation, requesting "add a one-line comment above each major section explaining its purpose" often results in those comments still containing marketing-speak, like "leverages robust orchestration." The format helps, but it doesn't fully sanitize the content.
This leads me to a hybrid approach: I combine your artifact method with a single, positive style anchor. For a Zendesk trigger condition, my prompt might be: "Provide the exact JSON block for a Zendesk trigger that prioritizes tickets with 'SLA-breach' in the subject, formatted as a code snippet. Use the terse, instructional tone of an internal platform team wiki." The artifact defines the form, the anchor steers the language within it.
Support is a product, not a department.