Inspect the saved file tree
Run this inside the folder where you saved the HTML, CSS, JavaScript, and assets.
cd <project-folder>
find . -maxdepth 2 -type f | sort
Website handoff
Save website work made with Kimi or Kimi Code as local files, then test HTML, CSS, JavaScript, assets, and deployment boundaries.
Yes, but the exact method depends on where the website was created. If Kimi generated source files in a coding workspace, save the HTML, CSS, JavaScript, assets, and package files as a local project. If you are in Kimi Code, the kimi export command packages a session; that is useful evidence, but it is not the same as a production-ready website folder.
Ask Kimi for a clean file tree and a run command, then test the site locally before publishing it anywhere.
Copy the website files into a real folder first. A Kimi Code session ZIP is useful backup, not the website itself.
Run this inside the folder where you saved the HTML, CSS, JavaScript, and assets.
cd <project-folder>
find . -maxdepth 2 -type f | sort
Use this for plain HTML/CSS/JavaScript output.
cd <project-folder>
python3 -m http.server 4178
Use this when the export includes package.json and a documented dev script.
cd <project-folder>
npm install
npm run dev
Keep this ZIP as context, not as the production website folder.
mkdir -p "$HOME/kimi-site-archives"
kimi export -y -o "$HOME/kimi-site-archives/kimi-site-session.zip"
Use this section to keep the next step practical before you touch accounts, files, infrastructure, or hardware.
| Check | Look for | Why it matters |
|---|---|---|
| Start narrow | Run the smallest read-only check before commands that install, move, write, or call a provider. | A small pass condition keeps the workflow reviewable. |
| Keep commands copyable | Use exact commands without shell prompts and run one step at a time. | This avoids accidental pasted characters or bundled side effects. |
| Protect accounts | Do not paste raw API keys, billing data, OAuth codes, or private files into a guide page. | Account-bound work belongs in the official product surface. |
| Record the result | Write down the model ID, path, version, output, or error message that changed the decision. | The next attempt should not have to rediscover the same state. |
Request separate index.html, style files, scripts, assets, and any package.json needed to run the site.
Images, fonts, and videos must stay in the same relative folders used by the HTML and CSS.
For static pages, open index.html or serve the folder with a simple local server. For frameworks, install dependencies and run the documented dev command.
Use Kimi Code export to archive the conversation and context, then keep the actual site files in a project folder or Git repository.
| Situation | Best action | Check before handoff |
|---|---|---|
| Kimi wrote plain files | Save the file tree locally | Open the page and confirm every asset loads |
| Kimi Code changed a repo | Commit or archive the changed files | Run the local dev command and targeted checks |
| You only have a chat answer | Ask for complete files and folder names | Do not publish until files exist locally |
| You need a record of the session | Use kimi export | Remember that a session archive is not the site itself |
Ask for a complete project with file names, folder structure, setup command, local test command, and deployment notes.
Check responsive layout, broken asset paths, form behavior, console errors, metadata, favicon, sitemap needs, and whether any placeholder copy remains.
A screenshot or chat answer is not a website export. You need the actual files or a repository change.
It can produce a single-file static page when you ask for that format, but larger sites are easier to maintain as a folder.
No. It packages a Kimi Code session for sharing or archiving. Keep the actual website files separately.
Serve the folder locally, open the homepage, resize the browser, and check console errors and missing assets.