Content Guidelines

Overview

Content guidelines let you steer every piece Shipstar writes — changelogs, release notes emails, blog posts, social posts, KB articles — without editing prompts. There are two levers:

Voice (audience) — how technical the writing reads. One of technical, business, or mixed. This is separate from your Ideal Customer Profile: the ICP describes who your customers are and what they struggle with; the voice sets the register of a given piece — the same ICP often gets a business-level release email and a technical changelog.
Focus & exclusions (instructions) — free-text guidance (up to 2000 characters) on scope, tone, and terminology. Typical uses: excluding parts of a monorepo (“don’t mention changes to the marketing website or docs site”), house style (“British spelling, no exclamation marks”), or naming (“call users members, never customers”).

Set them once per project as defaults, and override either field for a single run whenever you need to.

Voice presets

Preset	Written for	What changes
`technical`	Developers, platform/DevOps engineers, technical founders	Names APIs, endpoints, CLI flags, config keys, and versions when the commits mention them; calls out breaking changes, migrations, deprecations, performance and reliability work; no marketing superlatives.
`business`	Product managers, operations, executives, buyers, end users	Plain-language outcomes — what people can now do, what got faster or safer, and why it matters. No code identifiers, endpoint names, config keys, file paths, or commit hashes.
`mixed`	A blend of both	Leads with the plain-language outcome, then adds at most one short technical detail where it helps a developer act.

Leave the preset unset and each content type keeps its built-in tone (release notes emails stay non-technical, LinkedIn posts stay professional, and so on).

Project defaults

In the dashboard, open Settings → Content guidelines, choose a voice, write your focus & exclusions, and save. The defaults apply to every new generation for that project — manual, scheduled, or kicked off by an agent through MCP. Agents can read the current defaults with get_project_context, which returns:

"content_guidelines": {
  "audience": "business",
  "instructions": "Don't mention changes to the marketing website or docs site."
}

Overriding for one run

Each field falls back to the project default independently — pass only what you want to change.

Dashboard
MCP tools
REST

Regenerate… on any draft opens a dialog prefilled with the effective guidelines (voice + focus & exclusions); adjust them and re-run. The override applies to that run only and is remembered on the draft, so a later regenerate starts from it.
Schedules carry their own voice and focus & exclusions (set them in the schedule dialog); every occurrence uses them.

Every generate_* tool accepts audience and instructions:

{
  "tool": "generate_changelog",
  "arguments": {
    "audience": "technical",
    "instructions": "Include API endpoint names. Skip anything under marketing/."
  }
}

Every generation endpoint accepts a guidelines object:

curl -X POST "https://api.shipstar.ai/api/internal/sources/github/changelog" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "guidelines": { "audience": "business", "instructions": "No docs-site changes." } }'

How guidelines are applied

Guidelines are appended to the content-type prompt as an explicit block. They take precedence over the type’s built-in tone and its default list of what to skip — so “do mention docs changes” works as well as “don’t” — but they never change the required output format. Changelogs and release notes emails still come back as structured JSON, blog posts as Markdown, and so on. The resolved guidelines for any run are visible in the stored prompt of the generated content record, which makes it easy to confirm what the writer was told.

Limits and validation

audience must be one of technical, business, mixed — anything else is rejected with a validation error.
instructions are trimmed and capped at 2000 characters.
Blank or omitted fields inherit the project default; there is currently no way to suppress a project default for a single run other than overriding it with different text.

get_project_context — read the current defaults
generate_changelog and the other generation tools — per-call overrides
How it works — the full generation pipeline

Get Started

Guides

Content Guidelines

Overview

Voice presets

Project defaults

Overriding for one run

How guidelines are applied

Limits and validation

​Overview

​Voice presets

​Project defaults

​Overriding for one run

​How guidelines are applied

​Limits and validation

​Related

Overview

Voice presets

Project defaults

Overriding for one run

How guidelines are applied

Limits and validation

Related