Skip to main content
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 first. Knowing your own ICP better than anyone is the moat — see Part 1 §1.1 The thesis.

​
Steps

  1. Make sure Pi is initialized for the org first, per 2.1.1 Create the org & initialize 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: 
do a website research
Pi runs company-explorer: crawls the site and public sources, and builds a picture of the product, ICP, and positioning. 
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 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). 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: 
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 · Part 1 §1.11 Definition of done · Next: 2.1.3 Connect Google Search Console