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

# How to research your company and build the Product Bible

> Run company-explorer and product-bible to turn ICP knowledge into your account's source of truth.

Run two Pi skills in sequence: ask Pi to "do a website research" (`company-explorer`) to gather what
your product is, who it's for, and how it's positioned, then "build a product bible" (`product-bible`)
to compile it into your account's canonical reference, filed to `/memory/`. Review and correct it. It's
a knowledge artifact, so accuracy beats speed. Then confirm it captures your product accurately and
flag any claims you must NOT make. Everything downstream (keywords, landing pages, blogs) grounds on
this bible, so [initialize Pi for the org](/platform/create-org-init-pi) first. Knowing your own ICP
better than anyone is the moat — see [Part 1 §1.1 The thesis](/theory/thesis).

## Steps

1. Make sure Pi is initialized for the org first, per [2.1.1 Create the org & initialize Pi](/platform/create-org-init-pi).
2. Run `company-explorer` on your website to gather what your product is, who it's for, and how it's positioned.
3. Run `product-bible` to compile that research into the Product Bible, filed to your account's memory.
4. Review and correct it. This is a knowledge artifact, so accuracy matters more than speed.
5. Confirm the bible captures your product accurately, and note any claims you must not make.

## Kick off the research

Both steps are agent-operated. The prompts are short because the skills carry the procedure:

```text theme={null}
do a website research
```

Pi runs `company-explorer`: crawls the site and public sources, and builds a picture of the
product, ICP, and positioning.

```text theme={null}
build a product bible
```

Pi runs `product-bible`: compiles the research into the Product Bible and files it to your account's
memory (e.g. `/memory/product-bible.md`), with an index line in `MEMORY.md`. See
[2.0.4 Filing work in Pi's VFS](/platform/filing-in-the-vfs) for how filing works.

## The Hyperbound pattern: confirm before you scale

The Product Bible is not an internal draft you skim once. In the Hyperbound engagement it was
built from research, the website, call transcripts, and public sources, then confirmed and corrected,
with a list of claims to NOT make, before any page was scaled (see
[Part 1 §1.1](/theory/thesis)). Do the same: validate the knowledge first, and the pages come
after. Getting the "do not claim" list up front is what keeps the whole downstream content pipeline
compliant. It's cheaper to bound the claims here than to run compliance sweeps on a backlog later.

## Keep it correct over time

The Product Bible is maintainable source data, not a document you write once and abandon. When facts
or links drift, fix the bible and its memory, not just the content that came from it:

```text theme={null}
Fix all the links in the product bible and memory.
```

> 🎬 **Video planned:** run `company-explorer`, produce the Product Bible, review + correct. See the
> shot-list.

**Serves:** [Part 1 §1.1 The thesis](/theory/thesis) · [Part 1 §1.11 Definition of done](/theory/definition-of-done) · **Next:** [2.1.3 Connect Google Search Console](/platform/connect-gsc)