Generate a knowledge pack

Copy everything below into your own AI (Claude Code, Cursor, ChatGPT — any of them) and run it at the root of your own repository. It reads your code and docs on your machine and produces one kefu-knowledge-pack/ folder. KefuAgents only ever receives that folder — your code is never uploaded.

Role

You are a support-knowledge engineer. Goal: assemble, from this repository, a knowledge pack that can answer real customer questions, to be used by an AI support agent. This is not product documentation and not marketing copy — it is the binder a support rep keeps within arm's reach.

Read these first

In order; skip what does not exist, and never invent:

1. README*, CONTRIBUTING* — what the product is and who it is for;
2. user-facing docs under docs/, documentation/, website/, site/, content/;
3. the source of truth for pricing and plans (pricing.*, plans.*, the Stripe/Paddle product config, the pricing component on the landing page) — copy only numbers that actually exist in config;
4. CHANGELOG* and release notes — what shipped recently, what has not;
5. legal text: ToS, privacy policy, SLA, DPA (often under legal/, public/, or on the website);
6. existing support material: FAQ pages, help centre, a support/ directory, canned reply templates;
7. failure modes: issue templates, error-code tables, troubleshooting*, and the user-visible parts of ops runbooks.

Output

Create kefu-knowledge-pack/ at the repository root with this structure:

kefu-knowledge-pack/
  pack.yaml
  01-product-overview.md
  02-features/<feature>.md      # one file per feature: what, how, limits, misconceptions
  03-pricing-and-billing.md     # plans, quotas, trials, refund stance
  04-account-and-security.md    # sign-in, recovery, permissions, data security
  05-integrations.md            # what connects, how to configure, common traps
  06-troubleshooting.md         # symptom -> cause -> fix
  07-faq.md                     # Q/A pairs
  08-policies.md                # ToS / privacy / SLA digest + links to the originals
  09-boundaries.md              # what support may never promise

pack.yaml:

name: <pack name, hyphenated, e.g. acme-support-pack>
product: <product name>
version: <bump on every regeneration: 1, 2, 3>
generatedAt: <YYYY-MM-DD>
generator: <the AI you used, e.g. claude-code>
languages:
  - en
  - zh

Every markdown file starts with front matter:

---
title: Billing and plans
category: 03-pricing-and-billing
audience: customer
source_paths:
  - src/config/pricing.ts
  - docs/billing.md
last_verified: 2026-08-21
confidence: high
---

## What is included in the free plan

…

## How long is the trial

…

Field notes:

• title — what this file covers.
• category — default to the file name without .md.
• audience — customer means it may be used to answer a customer directly; internal means support-team background only (internal process, known but unannounced limits, wording boundaries). When in doubt, use internal.
• source_paths — the repository-relative files this entry was derived from.
• last_verified — the date you actually verified it. If you are unsure, delete the line entirely; do not fill in today.
• confidence — high / medium / low.

Entries are split by heading level: one ## heading = one entry. Write the heading as the sentence a customer would say ("How long is the trial" beats "Trial policy").

Hard rules

1. Never invent. No number, deadline, or promise that is not in the code or the docs. If the information is missing, delete that section rather than guessing one.
2. Unsure means confidence: low, plus a line in the body saying the website or contract is authoritative.
3. Every entry carries source_paths. Anything you cannot attribute does not belong in the pack.
4. Separate customer from internal. Internal-only limits, bugs being fixed, pricing legacy — all internal.
5. No roadmap promises. "Next release will support X", "planned for Q3" — never in a customer entry. If it matters, write it into 09-boundaries.md as "support may not promise ship dates".
6. 09-boundaries.md is about what may NOT be said, not what may: how far refunds go, the compensation cap, what the SLA can commit to, whether support may act on an account for the customer, whether data can be deleted — state today's stance for each and mark it as needing a human decision.

Delivery (pick one)

A. Drag it in (simplest): drop the whole kefu-knowledge-pack/ folder onto "Knowledge → Import a knowledge pack" in the KefuAgents console.

B. Upload via API: create a Gateway Key at Settings -> Agent gateway in the console (tick the gateway:submit_draft scope; the key is shown once), store it in KEFUAGENT_GATEWAY_KEY, then:

# Your workspace: shown on Settings -> Agent gateway
# Never write the key into a file that gets committed.
cd kefu-knowledge-pack
curl -X POST "https://kefuagents.com/api/support/knowledge-pack/import" \
  -H "Authorization: Bearer $KEFUAGENT_GATEWAY_KEY" \
  -F "pack.yaml=@pack.yaml" \
  -F "01-product-overview.md=@01-product-overview.md" \
  -F "03-pricing-and-billing.md=@03-pricing-and-billing.md" \
  -F "07-faq.md=@07-faq.md" \
  -F "09-boundaries.md=@09-boundaries.md"
# The form field name IS the pack-relative path; add one -F per file.

What happens after the import

• How-to, feature explanations and troubleshooting are published on import and usable immediately;
• pricing, policy and boundaries (03 / 08 / 09) enter the confirmation queue; they take effect only after you confirm them in the console. Money and deadlines are not left to the AI;
• audience: internal entries are never sent to a customer verbatim; they only inform the AI's judgement;
• re-importing the same version creates no duplicates. Change the content, bump version, upload again.