build-context-model

---
name: build-context-model
description: Build and maintain a Company Context Model - the root-level document that lets any AI assistant (ChatGPT, Claude, n8n agents) produce specific, on-brand, delegation-ready output instead of generic slop. /build writes a usable context-model.md immediately, then enriches it from sources or an interview; unresolved gaps stay visible but never block later skills. /refresh runs the weekly update ritual. Triggers - "build context model", "build my context model", "/build-context-model", "/build", "/refresh", "set up company context", "my AI answers are generic".
license: MIT
---

# Context Model - the company's operating context for AI

Every AI assistant is a brilliant employee on their first day: smart, fast, and knowing nothing about your company. The Context Model fixes the "first day" problem once - one document that travels to every AI surface you use.

**What it feeds:**

| Surface | How |
|---|---|
| ChatGPT Projects | upload `context-model.md` as project file |
| Claude Projects / Claude Code | project knowledge / `CLAUDE.md` reference |
| n8n / API agents | inject as CONTEXT block in the system prompt |
| Any chat | paste as CONTEXT before your question |

Two commands:

| Command | Duration | What it does |
|---|---|---|
| `/build` (default) | 20-40 min | Creates `context-model.md` - harvest mode or interview mode |
| `/refresh` | 10 min | Weekly update ritual: new wins, changed facts, changelog |

---

# /build - create the model

## Step 0 - confirm before starting

Confirm with the user in one message:

1. **Wiki root** - the exact folder to populate. Default: the current working directory. This folder is both the project root and the wiki root.
2. **Company name** - the name written into the schema and context model.
3. **Existing materials** - most companies have two: a **website URL** and a **local folder with documents** (presentations, price lists, proposals, service descriptions). Also welcome: pitch deck, testimonials, prior briefs; for technical users - repo paths. This decides the mode:
   - Anything provided → **harvest mode** (default)
   - Nothing → **interview mode** ("nothing" is fine - the interview covers it)

**Path invariant:** the confirmed wiki root is exact. If the user confirms `/work/HighCraft`, write `/work/HighCraft/context-model.md`. Never create a second company-named folder inside it.

## Populate the wiki root

Create the FULL structure immediately, before harvesting or interviewing - the user must see the whole machine after step 0, not just its first piece:

```
./
├── AGENTS.md             ← the schema: how this wiki operates (Codex reads this name)
├── CLAUDE.md             ← same content (Claude Code reads this name)
├── llm-wiki.md           ← the original pattern doc (Karpathy)
├── context-model.md      ← usable cornerstone page: who we are, gaps allowed
├── index.md              ← catalog: one line per wiki page
├── log.md                ← append-only record of what happened when
├── raw/                  ← immutable source material (site dumps, docs, notes)
├── wiki/                 ← linked pages the agent maintains
└── output/               ← work products (drafts a human reviews)
```

Then, in order:

1. Get `llm-wiki.md` into the folder: copy from this skill's own directory (the folder containing this SKILL.md); if you cannot locate it, download `https://raw.githubusercontent.com/alex-on-ai/company-llm-wiki/main/llm-wiki.md`.
2. **Read `llm-wiki.md`.** You are instantiating that pattern for a company; the file explains why each piece exists.
3. Write `AGENTS.md` from the schema template below, and write the identical content to `CLAUDE.md`. With the schema in place, ANY agent opened in this folder knows how to operate the wiki - even without these skills installed. That is the point of the pattern.
4. Create `index.md` (header only for now) and `log.md` with its first entry: `## [YYYY-MM-DD] build | folder scaffolded`.
5. Create `context-model.md` now from `templates/context-model-template.md`. Fill everything already known from step 0 and mark every unknown as `[GAP]`. This is the real cornerstone page, not a draft file.

From this point onward, `/process-meeting` and `/ingest` may run. `[GAP]` and `⚠ UNVERIFIED` markers reduce precision but never block those operations. Keep one master file deliberately: update root-level `context-model.md` in place and never create `output/context-model-draft.md`, `context-model-draft.md`, or a second model elsewhere.

## The schema (write as AGENTS.md, copy to CLAUDE.md)

```markdown
# [Company] LLM wiki

An LLM-maintained wiki about [Company], in the pattern of `llm-wiki.md` (read it once).
The agent maintains everything except `raw/`; the human curates sources and reviews outputs.

## Layers

- `context-model.md` - the cornerstone: who we are, distilled from the wiki into one portable file (uploadable to any AI surface). Read before any task. Update only via the refresh ritual, never silently; detail belongs in wiki pages, linked with `[[Page Name]]`.
- `raw/` - immutable sources. Read, never modify. New material always lands here first.
- `wiki/` - pages the agent creates and maintains: `clients/`, `meetings/`, `projects/`, `cases/`, `topics/`. Cross-link with `[[Page Name]]`.
- `output/` - work products (task lists, specs, letters). Drafts only; a human sends. Frozen once shipped.
- `index.md` - one line per wiki page. Update on every page change.
- `log.md` - append-only: `## [YYYY-MM-DD] <op> | <subject>` where op is build / ingest / process / refresh / query.

## Operations

- **Ingest** (any material): file the knowledge into `wiki/` pages, cross-link, update `index.md`, append to `log.md`.
- **Process a meeting**: ingest the transcript, then write to `output/`: team tasks with owners (from the Team section of the context model), owner action items, decisions waiting with recommendations, a spec when a deliverable is implied, a client-facing draft in the company Voice, risks.
- **Refresh** (weekly): update changed sections of `context-model.md`, resolve markers, append changelog + log entry.

## Rules

1. Never invent facts. Unknowns stay visible as `(to clarify)`.
2. Newer fact wins, and the page notes the change.
3. Claims marked `⚠ UNVERIFIED` never enter client-facing output.
4. Wiki pages and outputs in English; respond in the user's language.
5. Anything client-facing is a draft. Never send or execute anything.
6. `[GAP]` markers never block ingest or meeting processing. Use verified context and keep unknowns visible as `(to clarify)`.
7. This current folder is the wiki root. Never create a nested company folder or a second context model.
```

## Harvest mode (materials exist)

1. Read every provided source. Start from the website: fetch the key pages (home, services, about, cases). Then the local folder's documents, decks, and any repo files. If a supplied URL can't be fetched (login-walled or blocked), try a connected browser tool when one exists; otherwise ask the user to paste the page text. A source the user supplied is never parked without asking once - the non-blocking-gaps rule applies to missing facts, not to supplied sources. Only if the user declines or cannot provide it, record it as unresolved and continue. Save extracts worth keeping into `raw/`.
2. Update ALL sections of root-level `context-model.md` directly from sources. Mark every fact you could not source as `[GAP]`. Do not write a separate draft.
3. **File durable entities as wiki pages.** A website harvest typically yields 3-8 pages: one page per named case study or flagship product (`wiki/cases/`), plus topics worth their own page - named competitors, the market segment, a signature method (`wiki/topics/`). Link them from the relevant context-model sections with `[[Page Name]]`, add each to `index.md`. This is what makes the folder a wiki and not one file with empty directories.
4. Run the Verification pass (below) on the current model.
5. Close the build as usable, then ask the user ONLY the highest-value `[GAP]` questions in batches of 3-4. These questions refine the model; they do not gate completion or later commands. If the user does not answer, keep the markers and continue to treat the model as valid.

**Never pad.** A short, true section beats a full, invented one.

## Interview mode (blank start)

`context-model.md` already exists from the scaffold. Ask in **6 batches of 3-4 questions** and write answers into that file after each batch. Max 18 questions total; skip anything already answered. If the interview pauses, leave the remaining `[GAP]` markers in place; the model and downstream skills remain usable. Never create a draft variant.

### Batch 1 - Identity
1. Company name + one plain-language sentence: what do you do?
2. The category you compete in. Specific ("B2B freight forwarding", "fractional CTO"), not generic ("logistics company").
3. The enemy: what common practice / noisy trend in your industry are you against? One sentence.

### Batch 2 - Offer
4. What do you sell? Top-3 services/products/packages.
5. Price points. Ranges are fine; if custom - minimum contract.
6. Model: project / retainer / hourly / subscription / hybrid?

### Batch 3 - Ideal client (ICP)
7. Who is the ideal client? Role, company size, region, industry.
8. Their 3 sharpest pains right now - concrete ("quotes take 2 days, deals die waiting"), not "they want to grow".
9. Buying triggers: what signals a client is ready?
10. Who are you compared against? 2-3 named competitors or company types.

### Batch 4 - Differentiation & proof
11. Your unique mechanism, one sentence - the concrete "how".
12. Most impressive case with numbers: client + before/after + timeframe + what you did.
13. What do you do that competitors don't? 1-3 points.

### Batch 5 - Voice
14. How do you talk about your work? Direct / casual / consultative / provocative?
15. Phrases you repeat constantly (brand stickers) - and words you'd never use.

### Batch 6 - Team & operations
16. Who is on the team? First names + roles + what each person owns.
17. What tools run the company: task tracker, CRM, docs, messengers?
18. Operating rhythm: which meetings exist, what response times do you promise clients, what can be decided without the owner?

## Verification pass (always, both modes)

Before finishing, list every factual claim in Proof and Differentiation with its status:

```
✓ confirmed by user
✓ from source: [file/URL]
⚠ UNVERIFIED - do not use in client-facing output until confirmed
```

Unverified claims stay in the document but keep the `⚠ UNVERIFIED` marker. AI assistants consuming the model must treat marked claims as unusable in client-facing text. Never invent metrics, clients, or testimonials to fill a template.

## Synthesis

Refine the existing root-level `context-model.md` into the 10 sections + changelog from `templates/context-model-template.md`. The relationship to the wiki: **the wiki is the source of truth, the context model is the compiled artifact** - the wiki's synthesis page, kept short and portable because it gets uploaded to ChatGPT Projects, pasted into system prompts, and read first by every agent. Detail belongs in wiki pages; the model links to them with `[[Page Name]]` instead of absorbing them. `/refresh` recompiles it as the wiki learns.

The model is a proper page throughout the build, even when incomplete. Never put it under `output/`, never rename it to a draft, and never withhold it until all gaps are answered.

Concreteness rule: if a section reads like it could describe any company in the industry, it is not done; push for the specific detail.

Then close the books: update `index.md` (one line per page, context-model.md first), and append to `log.md`: `## [YYYY-MM-DD] build | context model built from <sources>, N wiki pages filed`.

## Closing message

```
✅ LLM wiki set up for [Company].

Cornerstone: ./context-model.md
Wiki pages:  [N] filed (see index.md)
Schema:      AGENTS.md + CLAUDE.md - any agent opened here knows how this wiki works
Gaps:        [N] (marked [GAP] / ⚠ UNVERIFIED inside)
Status:      usable now - gaps do not block /process-meeting or /ingest

USE IT NOW:
→ ChatGPT: create a Project, upload context-model.md, ask anything
→ Claude Code: reference it from CLAUDE.md
→ n8n agent: paste into the system prompt as CONTEXT block

NEXT:
→ /process-meeting - transcript in raw/ → wiki pages + tasks + spec + drafts
→ /ingest - file any other material into the wiki
→ /file-tasks - create the team tasks in your connected tracker (Linear, Jira, ...)
→ /refresh weekly (10 min) - new wins, changed facts

ONE QUESTION BEFORE YOU GO: version this wiki as a PRIVATE git repo
and push it? (yes / local only / no) - recommended: it backs the wiki
up and lets autonomous agents use it as task context.
```

## Version the wiki (the closing message ends with this question)

The question above is part of the closing message template, not an optional extra: print it and end the turn waiting for the answer. Omit those template lines only when git is unavailable or the wiki root is already inside a git repository (then the turn ends after NEXT).

Why: the wiki is most useful as a **private git repository** - versioned, recoverable, and reachable by autonomous agents that pick up tasks with this wiki as their context (`/file-tasks` adds a repo pointer to every task once a remote exists).

Handling the answer:
- **yes** → `git init`, commit everything, then create a PRIVATE repo named after the folder and push (`gh repo create <folder-name> --private --source . --push` when the GitHub CLI is authenticated; if it is not, init + commit locally and print the exact manual commands for the user to create the private repo and push). Never create a public repo, and never push without this consent.
- **local only** → init + commit, no remote.
- **no** → skip; the wiki works fine as plain files.

Record the choice in `log.md`.

---

# /refresh - weekly update ritual

Precondition: `context-model.md` exists (else suggest `/build`).

1. Ask one batch: "What changed since [last changelog date]? New clients/cases, pricing changes, new team members, new tools, positioning shifts, anything you keep re-typing into AI chats?"
2. Also accept pasted raw material (call notes, wins) - extract, don't interrogate.
3. Update the affected sections. Resolve `[GAP]` / `⚠ UNVERIFIED` markers the user can now confirm.
4. Append a one-line changelog entry with date.
5. Show a 3-line diff summary of what changed.

---

# Hard rules

1. **Parse before asking.** Whatever sources exist, read them first; ask only gaps.
2. **Batches of 3-4 questions.** Never one-by-one interrogation.
3. **Concreteness is mandatory.** "We're better than competitors" → re-ask for the mechanism.
4. **Never invent facts.** No made-up metrics, cases, clients, or quotes. Gaps stay visible as `[GAP]`.
5. **Verification pass is not optional.** Every Proof claim carries a status marker.
6. **Markdown, one master file.** No JSON, no sprawling folder trees.
7. **Respond in the user's language; write the model in English** unless the user asks otherwise (English travels best across AI tools).
8. **Don't re-ask what the model already contains** - read it first.
9. **Short beats padded.** Empty template lines are deleted, not filled with fluff.
10. **Scope: company context for AI assistants.** Not a resume, not a marketing site, not a brand book.
11. **The wiki root is exact.** Never create a nested company folder.
12. **The cornerstone always exists.** Create `context-model.md` during scaffolding and refine it in place; gaps never turn it into a draft or block downstream skills.

# Dependencies

Agent built-ins only (web fetch for harvest mode) - works the same in Claude Code and Codex. No MCP servers or API keys required. If a supplied URL is login-walled, use a connected browser tool when one exists or ask the user to paste the page text.

# Attribution

The wiki pattern this instantiates is Andrej Karpathy's "LLM Wiki" - included verbatim as `llm-wiki.md` (the file itself says it "is designed to be copy pasted to your own LLM Agent").