# Omnigraph Intel Bootstrap

> Bootstrap a new Omnigraph-based SPIKE industry intelligence graph from scratch. Use this skill whenever a user wants to set up a new SPIKE graph — either with the existing AI industry demo data or for a new domain (biotech, fintech, crypto, geopolitics, macroeconomics, SaaS, climate tech, etc.). The flow presents a demo-vs-custom decision, then for custom setups asks about domain scope, actors, cadence, and sources, adapts schema and enums for the target domain, runs initial web research to generate real seed content, and converges the cluster (apply creates the graph) + loads seed data. Apply aggressively when the user says any of: set up Omnigraph, bootstrap a new graph, create a new SPIKE cookbook, I want to track X industry, initialize intel for Y, new graph for Z domain, start a new context graph, or similar phrasing. This skill takes a user from zero to a populated, queryable graph.

- Skill: `modernrelay/omnigraph-intel-bootstrap` (Agent Skill, multi-file: 6 files)
- Install (CLI): `npx skillmds@latest add modernrelay/omnigraph-intel-bootstrap`
- Raw SKILL.md: https://api.skillmd.com/api/skills/modernrelay/omnigraph-intel-bootstrap/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Research & Search
- License: MIT (see LICENSE at repo root)
- Author: modernrelay (https://skillmd.com/u/modernrelay)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/modernrelay/omnigraph-intel-bootstrap

---


# SPIKE Cookbook Bootstrap

This skill takes a user from zero to a populated, queryable SPIKE graph. Two paths:

- **Demo** — use the existing `industry-intel` cookbook (AI/ML signals as of early 2026). Good for demos, exploration, and understanding what SPIKE looks like populated.
- **Custom** — set up a new domain (biotech, crypto, fintech, geopolitics, etc.). Takes ~30–60 minutes including initial research and user review.

**Prerequisites:**

1. OmniGraph CLI and server v0.10.0.

2. The `omnigraph-cookbooks` repo cloned somewhere on disk. Ask the user where (or default to the current directory):
   ```bash
   git clone https://github.com/ModernRelay/omnigraph-cookbooks.git
   ```
   Record the absolute path to the clone — the **Demo** path runs from `<clone>/industry-intel/`, the **Custom** path runs from `<clone>/` (repo root) so it can copy `industry-intel/` as a template.

## Step 0: Pre-flight checks

Before either path, run these checks (and act on the results):

```bash
# Ensure the exact supported CLI is on PATH
command -v omnigraph >/dev/null || { echo "omnigraph not found — install via homebrew or the install script"; exit 1; }

# Require v0.10.0; upgrade CLI and server together.
test "$(omnigraph --version)" = "omnigraph 0.10.0" || { echo "this skill requires omnigraph 0.10.0"; exit 1; }
omnigraph version
```

The default (cluster-first) path needs **no RustFS, no credentials, no
.env.omni** — graphs live at local derived roots created by `cluster apply`.
RustFS checks and `.env.omni` only matter for the optional S3 alternative (see
the cookbook READMEs). A 0.9 graph needs the engine's coordinated 0.9→0.10
upgrade procedure and full-text-index rebuild before this skill operates it.

**If `:8080` returns `200` from a server pointed at a different repo** (the bootstrap script auto-starts one), stop it before starting yours, or rebind to a free port via `omnigraph-server --bind 127.0.0.1:8090`.

For the optional local S3 path only, follow the engine deployment guide and
source all seven `AWS_*` variables from the gitignored `.env.omni`; the default
filesystem path ignores that file.

## Step 1: Ask the user which path

Ask the user (use whatever structured-question primitive your runtime offers, or a plain prompt):

> Do you want to:
> - **Demo** — set up the AI industry intel demo (5 patterns, 15 signals, ~110 nodes, ready to query in ~30 seconds)
> - **Custom** — set up a graph for a new domain (I'll ask about your domain + sources, adapt the schema, research real seed data, and wire it up)

Branch based on the answer.

## Path A: Demo Setup

Quick — clone, converge, load. The cookbook ships a `cluster.yaml` declaring
the graph, schema, and all stored queries; `cluster apply` creates the graph.

See [`references/demo-setup.md`](references/demo-setup.md) for the full command list. Summary:

```bash
cd <path-to-clone>/omnigraph-cookbooks/industry-intel
# First merge omnigraph-config.example.yaml's servers/defaults/aliases into
# ~/.omnigraph/config.yaml; login stores the token separately.
omnigraph cluster import --config .
omnigraph cluster apply  --config . --as <you>     # creates graphs/spike.omni + publishes queries
omnigraph load --data seed.jsonl --mode overwrite graphs/spike.omni
# Serve with the cookbook policy, then authenticate the CLI:
OMNIGRAPH_SERVER_BEARER_TOKENS_JSON='{"act-admin":"local-admin-token","act-writer":"local-writer-token","act-reader":"local-reader-token"}' \
  omnigraph-server --cluster . --bind 127.0.0.1:8080 &
printf '%s' 'local-reader-token' | omnigraph login local
omnigraph alias patterns disruption    # CLI alias sugar
```

After this, point the user at the `omnigraph` skill (`npx skills add ModernRelay/omnigraph@omnigraph`) for day-to-day operations.

## Path B: Custom Domain Setup

Six phases, in order. Don't skip ahead — each phase's output feeds the next.

### Phase 1 — Domain identification

Ask the user which domain they want to track. Present these as options:

- Biotech
- Fintech
- Manufacturing
- Crypto / web3
- Geopolitics
- Other (user specifies)

Then narrow:
- Scope: "all of X" or "only Y within X"?
- Global or regional?

Capture a **project slug** for the new cookbook: `bio-intel`, `crypto-intel`, `geo-intel`, etc. This becomes the folder name and the repo prefix (`s3://omnigraph-local/repos/<slug>`).

### Phase 2 — Key questions

Ask each in turn (multi-select where noted). See [`references/custom-domain.md`](references/custom-domain.md) for full phrasing and option lists.

- **Actors to track** (multi-select): companies, labs, regulators, individuals, protocols, investors
- **Time horizon**: recent only (3mo), medium (12mo), or full historical
- **Update cadence**: daily, weekly, monthly, ad-hoc
- **Primary consumer**: human analysts, internal dashboard, AI agents, mixed

### Phase 3 — Sources (most important)

Sources are the lifeblood of a SPIKE graph. The quality of the output is bounded by the quality of the sources. Spend time here.

Ask in order (see [`references/custom-domain.md`](references/custom-domain.md) for exact wording):

1. **Primary reading list** — newsletters, blogs, publications the user already reads (free-form, 5–15 entries)
2. **Priority analysts / experts** — 3–10 people whose takes should be first-class entities
3. **Regulatory / authoritative sources** — governmental, self-regulatory (FDA, SEC, IMF, etc.)
4. **Academic / primary sources** — journals, preprint servers, research aggregators
5. **Social / community** — X accounts, podcasts, forums

### Phase 4 — Confirm summary

Before making changes, echo what you captured back to the user:

- Domain + scope + project slug
- Actor types to track
- Horizon + cadence + consumer
- Source list (grouped by category)

Write this to `<slug>/setup-notes.md` in the new cookbook folder. Confirming now is cheap; rework later isn't.

### Phase 5 — Adapt the schema

From the **repo root** (`<clone>/`), copy `industry-intel/` as a template into `<slug>/`:

```bash
cd <clone>          # repo root, parent of industry-intel/
cp -r industry-intel <slug>
rm <slug>/seed.jsonl    # regenerated in Phase 6
```

Update in `<slug>/schema.pg`:

- `Element.kind` enum — replace with domain-appropriate kinds
- `Signal.domain` / `Element.domain` enum — replace with domain slices
- `Company.type` enum — match the ecosystem
- `SourceEntity.type` enum — match how sources publish
- `ArtifactType` enum — include domain-relevant formats
- Kind-specific Element properties (biotech wants `phase`, `moa`; crypto wants `chain`, `token_symbol`; etc.)

Update in `<slug>/cluster.yaml`:

- `metadata.name` → domain-appropriate name
- the `graphs:` entry id → `<slug>` (its derived root becomes `graphs/<slug>.omni`)

Update `<slug>/omnigraph-config.example.yaml` too: change `default_graph` and
every alias `graph:` from `spike` to `<slug>`, and adjust aliases if query names
changed. Before verification, merge its `servers`, `defaults`, and `aliases`
into `~/.omnigraph/config.yaml`.

**Pattern.kind** (`challenge`, `disruption`, `dynamic`) is usually domain-agnostic. Don't change it unless the user has strong reasons.

See [`references/schema-adaptation.md`](references/schema-adaptation.md) for the full keep-vs-change rules. See [`references/domain-examples.md`](references/domain-examples.md) for worked examples across biotech, crypto, fintech, geopolitics.

After editing:

```bash
cd <slug>
omnigraph lint --schema schema.pg --query queries/signals.gq
```

Fix any lint errors before moving on.

### Phase 6 — Research, seed, init, load

Use web research to build real seed content. **Do not fabricate signals or dates.** See [`references/research.md`](references/research.md) for the workflow. High-level:

1. For each source from Phase 3, pull recent items (WebFetch / WebSearch)
2. Extract candidate signals (dated, URL-backed, specific)
3. Cluster into 3–5 patterns (recurring themes)
4. For each pattern, identify the Elements, Companies, Experts mentioned
5. Write `<slug>/seed.md` (tabular, human-readable) — **present this to the user for review before generating JSONL**
6. Generate `<slug>/seed.jsonl` from the confirmed seed.md. **Every `slug`
   must appear exactly once in the file** — since omnigraph 0.8.0 a `@key`
   repeated within one load batch fails the whole load (nothing is
   partially applied); dedupe and re-run if it does. Duplicate edge rows
   on `@unique(src)` or `@unique(src,dst)` edges fail the same way.
7. From `<clone>/<slug>/`, converge the cluster, load, then start the server
   (the `cluster.yaml` — copied from industry-intel and re-slugged — declares
   the graph, schema, and queries):

```bash
cd <clone>/<slug>
omnigraph cluster import --config .
omnigraph cluster plan   --config .                # review what apply will do
omnigraph cluster apply  --config . --as <you>     # creates graphs/<slug>.omni
omnigraph load --data seed.jsonl --mode overwrite graphs/<slug>.omni
OMNIGRAPH_SERVER_BEARER_TOKENS_JSON='{"act-admin":"local-admin-token","act-writer":"local-writer-token","act-reader":"local-reader-token"}' \
  omnigraph-server --cluster . --bind 127.0.0.1:8080 &
printf '%s' 'local-reader-token' | omnigraph login local
```

8. Verify with a sample query (goes through the server):

```bash
omnigraph alias patterns <pattern-kind>
```

### Phase 7 — Hand-off

Tell the user:

- What got created: the cookbook folder (a **cluster directory** —
  `cluster.yaml` declares graph + schema + queries; the graph lives at
  `graphs/<slug>.omni`, created by apply), the seed counts
- How to query: CLI aliases (per-operator `~/.omnigraph/config.yaml`), or HTTP —
  every declared query is served at `POST /graphs/<slug>/queries/<name>`
- The day-2 loop: edit `.pg`/`.gq`/`cluster.yaml` → `cluster plan` →
  `cluster apply --as <you>` → restart the server
- To use the `omnigraph` skill for day-to-day ops (adding
  signals, schema evolution, branches; see its `references/cluster.md`)

## Deep Dives

Load these only when you reach the relevant phase.

| Reference | When to load |
|-----------|--------------|
| [`references/demo-setup.md`](references/demo-setup.md) | User picked Demo path |
| [`references/custom-domain.md`](references/custom-domain.md) | Phases 1–4: elicitation question bank and source patterns |
| [`references/schema-adaptation.md`](references/schema-adaptation.md) | Phase 5: what stays vs changes in the schema |
| [`references/domain-examples.md`](references/domain-examples.md) | Phase 5: ready-made enum sets for biotech, crypto, fintech, geopolitics |
| [`references/research.md`](references/research.md) | Phase 6: web research → seed.md → seed.jsonl workflow |