Skip to main content
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.

​
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.

​
Who will use the knowledge

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

​
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.
If you want only general patterns, say that instead.

​
What to ignore

List content you don’t want in the knowledge base.
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.
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.

​
Example

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.

​
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.