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

# Write a good ingest prompt

> How to write the prompt or focus prompt that guides what Sphinx learns when you add content to your knowledge base.

When you start an ingest, you can add a prompt. In **Deep Update** the box is labeled **Prompt**; for Git Repository, Notion, and Google Drive it is labeled **Focus prompt**. The prompt tells Sphinx what the content is, who will use it, and what to keep. A good prompt is short and specific. It describes the result you want, not the steps Sphinx should take.

## What the prompt changes

The prompt has a different job in each kind of ingest.

| Ingest | What the prompt does |
| - | - |
| **Deep Update** with files, **Use files for training** | Guides what Sphinx writes from each file and how it merges new knowledge with existing pages. |
| **Deep Update** with files, **Use files as context** | Is the task. The files are reference material for the changes you describe. |
| **Deep Update** with no files | Is the whole task. Sphinx edits the knowledge base based only on what you write. |
| **Notion** and **Google Drive** | Sets the scope. Pages or files clearly outside it are skipped. |
| **Git Repository** | Sets priorities. It decides which topics and files Sphinx groups together and focuses on. It does not hide files from Sphinx. |
| **Python SDK** (`fit`) | Same as a Deep Update with files used for training. |

## What to include

### What the files are, and which to trust

Say what kind of content this is and where it came from. If sources can disagree, say which one wins.

```text theme={null}
These are our monthly finance close reports for 2023–2025, plus the
accounting policy handbook. When a report and the handbook disagree,
the handbook is correct; note the disagreement on the page.
```

### Who will use the knowledge

Name the audience and give a few real questions they will ask. This helps Sphinx choose what matters.

```text theme={null}
Analysts on the finance team will use this to answer questions like:
- What was the revenue recognition policy for multi-year contracts in 2024?
- Why did the Q3 2024 numbers get restated?
```

### Whether to keep exact details

By default, Sphinx keeps knowledge that applies broadly, such as definitions, rules, and how things work, and leaves out one-off numbers. If you need exact figures, names, dates, or wording, say so and name them.

```text theme={null}
Keep exact figures, dates, account codes, and the names of the people
who approved each policy change. Do not round or summarize numbers.
```

If you want only general patterns, say that instead.

### What to ignore

List content you don't want in the knowledge base.

```text theme={null}
Ignore draft versions marked "WIP", meeting logistics, and the
appendix tables of raw transactions.
```

For Notion and Google Drive, this skips those pages entirely. For Git, it lowers their priority but does not exclude them.

## What to avoid

* **Step-by-step instructions for how to ingest.** Sphinx already has its own process. Describe the result you want instead, for example "one page per policy, with its effective date", not "first read every file, then make a list…"
* **Claims about your files that aren't true.** If you say "every report has a summary table" and some don't, Sphinx may look for something that isn't there. Only describe what you know.
* **Pasting content into the prompt.** Put content in files. Keep the prompt for instructions.
* **Asking every file to build an overview or index page.** Each file is processed separately, so this can produce several overlapping overviews. Build summary pages in a separate Deep Update after the content is in.
* **Asking for lists of what's missing.** Requests like "note any information that is not in these files" fill pages with statements about what Sphinx couldn't find.
* **Blanket warnings.** A rule like "always double-check revenue figures" gets applied everywhere, including where it's wrong. Ask instead for caveats tied to a specific table, report, or period, with the source cited.

> [!TIP]
>
> Longer is not better. Prompts that state the content, audience, what to keep, and what to ignore in a few short paragraphs work better than long lists of rules.

## Editing the knowledge base without files

You can run a **Deep Update** with only a prompt to fix or reorganize existing pages. Edits suggested from Claude or ChatGPT through Sphinx MCP work the same way and appear as **Targeted Update**.

* **Be exact.** Give the exact page titles and the exact text to add or change.
* **Make one kind of change per request.** For example, "rename this metric everywhere" or "add the 2025 rate to these pages", not both.
* **Keep it small.** Aim for about 25 pages or fewer per run, named by title. Broad requests like "clean up the whole knowledge base" are slow and often incomplete.
* **Put rules where people will find them.** If you add a rule or caveat, add it to the pages it applies to, or link to it from those pages. A rule page that nothing links to is rarely used.

If you use **Use files as context**, say how Sphinx should treat the files, for example "these files are illustrative only; don't copy their numbers into the knowledge base."

## Template

Copy this and fill in the blanks. Delete any line you don't need.

```text theme={null}
These files are [what they are and where they come from].
Help [who] answer questions like [two or three real questions].
Keep exactly: [figures, names, dates, or wording that must not change].
[Source A] is authoritative over [source B]. Flag a conflict only when [condition].
Ignore: [content to leave out].
```

## Example

> **Before: too vague**
>
> ```text theme={null}
> Ingest these documents and create a good knowledge base. Be thorough
> and make sure nothing important is missed. Create an overview page
> and an index of all topics.
> ```
>
> This doesn't say what the documents are, who will use them, or what counts as important. It also asks every file to build the same overview and index.

> **After: specific**
>
> ```text theme={null}
> These are our customer support playbooks and the 2025 pricing sheet.
> Help support agents answer questions like:
> - What discount can I offer a customer on an annual plan?
> - How do I handle a refund request after 30 days?
>
> Keep exact prices, discount limits, time windows, and who must approve
> each exception. The pricing sheet is authoritative for prices; if a
> playbook quotes a different price, keep the sheet's price and note the
> mismatch on the page.
>
> Ignore internal team rosters and the training quiz files.
> ```

## Before you start the ingest

* The prompt says what the content is and which source wins in a conflict.
* It names who will use the knowledge and what they'll ask.
* It says whether to keep exact details, and which ones.
* It says what to ignore.
* It describes the result you want, not how to process each file.


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