Direct answer
A customer knowledge-pack ZIP should use one clear top-level folder and separate buyer-facing files into Knowledge Pack, Concept Learning Assets, AI Companion Setup, Start Here Readme and Playbook, and Usage Boundaries. It should exclude raw sources, internal logs, process prompts and operating artefacts.
The ZIP should feel like a product, not a production folder.
The real problem
A knowledge pack can be well written but poorly packaged.
If the customer opens a ZIP and sees a messy folder of drafts, exports, old filenames, duplicate versions, internal instructions and unclear setup files, the product feels less trustworthy. The buyer has to work out what is final, what is optional, what to upload, what to read first and what to ignore.
A customer ZIP solves that by turning the finished material into a clear delivery experience.
The goal is not to include every file created during production. The goal is to include the files a buyer can safely use.
Production workspace vs customer package
A production workspace contains everything used to build the pack.
A customer package contains only the final buyer-facing assets.
The production workspace may contain NotebookLM prompts, derivative reports, QA notes, source inventories, route gates, internal decisions and raw working files. Those may be necessary for the maker, but they can confuse or expose too much for the buyer.
A customer ZIP should be curated.
Recommended folder structure
A strong default structure looks like this:
Product_Name_Knowledge_Pack/
├── 00_Start_Here_Readme_and_Playbook/
├── 01_Knowledge_Pack/
├── 02_Concept_Learning_Assets/
├── 03_AI_Companion_Setup/
└── 04_Usage_Boundaries/The exact names can vary, but the logic should stay clear: start, learn, use, set up AI and understand limits.
Start Here Readme and Playbook
The Start Here section should orient the buyer. It should explain what the pack is, who it is for, what to open first, how to use the files, how to use the pack with AI, what is included, what is excluded, and what to recheck before public or client use.
If the buyer has to guess where to begin, the package is not finished.
Knowledge Pack folder
This folder holds the main knowledge assets: the Complete Knowledge Pack, concepts framework, research reference where appropriate, public-safe knowledge files, workflow references or glossary.
These should be final buyer-facing files, not raw source exports.
Concept Learning Assets
Concept learning assets help the buyer understand the ideas before using them. This folder may include short explainers, infographics, slides, mind maps, teaching notes, examples or quick-reference files.
These files are useful when the product has complex concepts or when the buyer may not want to start with a long Markdown file.
AI Companion Setup
This folder contains files that help the buyer use the pack with AI tools. It may include Starter Prompts, Custom GPT Instructions, Custom GPT Knowledge, SKILL.md, Skill Knowledge Reference, upload map, setup notes and example first prompts.
This folder should make file roles explicit. The buyer should know which file goes into instructions, which file goes into knowledge, which file is read by a human and which file is optional.
Do not imply a live AI system is included unless it actually is.
Usage Boundaries
Usage boundaries protect both the buyer and the seller. They should explain what the pack can be used for, what it should not be used for, what claims need rechecking, whether resale or redistribution is allowed, whether public GPT or public bot use is allowed, whether support or updates are included, and what source material is excluded.
Usage boundaries should be easy to find, not buried in small print.
What the ZIP should exclude
A customer ZIP should usually exclude raw source archives, NotebookLM prompt instructions used for production, derivative report folders not intended for customers, private chat logs, internal QA notes, route gate reports, pricing notes, draft versions, temporary files, local system files, nested duplicate folders and unrelated assets.
If an internal file is included deliberately, it should be described in the manifest.
What the manifest should confirm
The package manifest should confirm the exact product name, version, included folders, included files, file roles, expected upload map, excluded source categories, licence and usage notes, support/update terms where supplied, and any Custom GPT access route or setup condition.
A manifest keeps the product honest. It prevents the sales page, Start Here file and ZIP contents from drifting apart.
Common mistake
The common mistake is using the ZIP as a dump of everything produced. More files can make the pack look bigger, but they do not automatically make it better. Extra files can create confusion, expose internal material and make the buyer less confident.
A second mistake is putting final files inside nested duplicate folders. A customer should not have to click through several repeated folder names to find the product.
Soft next step
Before shipping a customer ZIP, open it like a buyer. If you cannot tell what to open first, what each file is for and what should not be used, the package needs cleanup before release.