> ## Documentation Index
> Fetch the complete documentation index at: https://docs.shipstar.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Content Guidelines

> Tune how technical generated content reads and what it should focus on or leave out

## 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: house style ("British spelling, no exclamation marks"), naming ("call users *members*, never *customers*"), or widening the default scope ("do announce docs-site changes"). You don't need to exclude your own marketing site, docs hosting, CI or internal tooling — every prompt already skips those and writes only about changes your customers can use.

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`](/mcp/project/get-project-context), which returns:

```json theme={null}
"content_guidelines": {
  "audience": "business",
  "instructions": "Call users \"members\", never \"customers\". British spelling."
}
```

## Overriding for one run

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

<Tabs>
  <Tab title="Dashboard">
    * **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.
  </Tab>

  <Tab title="MCP tools">
    Every `generate_*` tool accepts `audience` and `instructions`:

    ```json theme={null}
    {
      "tool": "generate_changelog",
      "arguments": {
        "audience": "technical",
        "instructions": "Include API endpoint names. Skip anything under marketing/."
      }
    }
    ```
  </Tab>

  <Tab title="REST">
    Every generation endpoint accepts a `guidelines` object:

    ```bash theme={null}
    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": "British spelling." } }'
    ```
  </Tab>
</Tabs>

## 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 single-feature types (X threads, LinkedIn posts, feature pages, and banners) also decline to post when no commit in the period is a customer-facing product change: the run ends with "nothing to post", nothing is published, and the credits are refunded. Because guidelines win on scope, an instruction such as "do announce docs-site changes" makes those changes count and prevents that outcome.

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.

## Related

* [`get_project_context`](/mcp/project/get-project-context) — read the current defaults
* [`generate_changelog`](/mcp/generation/generate-changelog) and the other generation tools — per-call overrides
* [How it works](/how-it-works) — the full generation pipeline


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.