kenobi-pages（克诺比页面）

STOP — Read This Before Doing Anything

When this skill applies, your very first action is to check whether npx kenobi-pages init has been run. Look for KENOBI_PAGES_KEY in the project's env files (.env.local, .env, etc.). You may read these files — but do nothing else (no installs, no code, no exploring the codebase).

Then your first response to the user must cover exactly two things — and nothing else:

1. Init status. If KENOBI_PAGES_KEY is missing, tell the user they need to run npx kenobi-pages init first, and briefly explain why: Before we begin — you'll need to connect this project to your Kenobi account. Grab your API key from kenobi.ai/setup (this is also where you can connect your data sources like Notion, HubSpot, Google Sheets, etc.) Run this in your terminal: npx kenobi-pages init This saves your API key so the CLI and SDK can talk to Kenobi. Let me know once that's done. If the key is already present, skip this and move straight to the discovery question.
2. Discovery question. Ask: Do you already have a Kenobi workflow set up, or are we starting from scratch?

Send that message. Stop. Wait for the user's reply. Only after they answer (and init is confirmed done) do you proceed to Phase 2.

1. Source check. Before routing to a sub-skill, run npx kenobi-pages sources to check whether the user has any data sources connected. If they answer "starting from scratch" or "I need to create a workflow" and no sources are returned, pause and tell them: Before building a workflow, you'll want to connect at least one data source — it's very unlikely you'd want to set up a workflow with nothing to pull from. Head to kenobi.ai/setup to connect Notion, HubSpot, Google Sheets, or other integrations, then come back and we'll pick up where we left off. Do not proceed to the workflows sub-skill until they've confirmed sources are connected (re-run npx kenobi-pages sources to verify). If the user explicitly insists on a params-only workflow with no external sources, respect that and continue.

If you are tempted to "just get started" or "explore the project while asking" — don't. That is the single most common failure mode with this skill.

Kenobi Pages

Kenobi Pages lets users create a single page template in their Next.js app that renders unique, AI-generated content for every lead. Each lead gets a URL like /for/acme-corp — the content is generated by a Kenobi workflow that pulls from CRM data, call transcripts, or other sources and uses AI to produce personalized copy and images.

The system has three parts: a page (Next.js dynamic route), a workflow (configured in Kenobi — wires data sources to AI generation to produce content), and runs (executing a workflow for a specific lead).

Phase 2 — Route to the Right Sub-Skill

Based on the user's answer to the discovery question:

Full Pipeline — Starting From Scratch

When the user says "starting from scratch" or wants the whole thing end-to-end, replace the generic discovery question with:

Do you want to start by designing how the page looks, or by setting up the data pipeline?

Then follow one of these paths straight through — do not re-ask discovery or re-check prerequisites between sub-skills.

Path A — Page-first (default, recommended for most users):

1. Design the page collaboratively — layout, copy structure, visual feel (skills/pages/SKILL.md, reverse mode)
2. Infer the output schema from the page design and push it
3. Build the workflow around that schema (skills/workflows/SKILL.md)
4. Run a test lead and verify (skills/run/SKILL.md)

Path B — Workflow-first:

1. Define sources, output schema, and generation config (skills/workflows/SKILL.md)
2. Build the page around the schema (skills/pages/SKILL.md, forward mode)
3. Run a test lead and verify (skills/run/SKILL.md)

Path A is the better default — most users think visually and want to iterate on the page design before worrying about data plumbing.

Phase 3 — Setup

Before writing any code, ensure the environment is ready:

1. Install kenobi-pages using the project's package manager (check for pnpm-lock.yaml, package-lock.json, yarn.lock, or bun.lockb to determine which one).
2. KENOBI_PAGES_KEY should already be in an env file from init. If not, ask the user to run npx kenobi-pages init.
3. Create the Kenobi client file (if it doesn't already exist). The file contains:

import { createKenobiPagesClient } from "kenobi-pages";

export const kenobi = createKenobiPagesClient({
  apiKey: process.env.KENOBI_PAGES_KEY!,
});

Where to put this file: Check if the project already has a shared utilities directory (lib/, src/lib/, utils/, src/utils/, app/_lib/, etc.). If one exists, put the client there (e.g. src/lib/kenobi.ts). If no shared directory exists, co-locate it inside the route directory you'll create in the pages sub-skill (e.g. app/for/[slug]/kenobi.ts). Never create a new top-level lib/ or utils/ directory just for this file.

If this project uses an env validation library (e.g. @t3-oss/env-nextjs), add KENOBI_PAGES_KEY to its schema and import from there instead of reading process.env directly.

If the package is already installed and the client file exists, skip this phase.

File organization principles

These apply to all sub-skills:

• Co-locate page code with the route. Types, content parsing, placeholder data, and view components all belong inside the route directory (e.g. app/for/[slug]/types.ts, app/for/[slug]/content.ts, app/for/[slug]/view.tsx). Deleting the route should clean up everything page-related.
• Workflow configs go in .kenobi/workflows/. Like .github/workflows/ — hidden, clearly infrastructure, not app code. Create this directory if it doesn't exist.
• Never persist intermediate artifacts. Schema JSON is a one-shot push — use inline JSON, don't save a file. The schema is already embedded in the workflow config's output.schema.
• Never create a top-level directory without checking what exists. Before creating any directory, read the project's existing structure and adapt to it.

Phase 4 — Implementation

Now read the sub-skill identified in Phase 2 and follow its instructions.

Important Context

• The SDK (kenobi-pages npm package) does one thing: getPage(workflowId, slug) fetches content for a specific lead at runtime. That's it. Everything else — schema management, workflow CRUD, triggering runs — is done via the npx kenobi-pages CLI.
• A workflow is a pipeline configured in Kenobi that takes data from sources (Notion, HubSpot, etc.), runs AI generation, and stores personalized content keyed by a slug.
• A slug is the URL-friendly identifier for a lead (e.g., acme-corp). Every workflow run produces content for one slug.
• The CLI reads KENOBI_PAGES_KEY and KENOBI_BASE_URL from shell environment variables or the project's env files (.env.local, .env, etc.) in the working directory. All commands output JSON to stdout and status messages to stderr.