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

```json theme={null}
"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.

<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": "No docs-site changes." } }'
    ```
  </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 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