PandaOSPandaOSby Pandata
Projects

Creating a Project

Projects give Panda persistent context, tools, and workspace awareness that a bare chat cannot.

Why projects exist

A bare chat session is stateless. It knows nothing about your codebase, your conventions, or the tools you rely on. A project changes that by binding a folder on disk to a persistent workspace inside PandaOS. Once a folder becomes a project, every conversation inherits its rules, knowledge files, connected apps, and dev server configuration. Panda stops being a generic assistant and starts being a collaborator that understands your specific work.

Creating a project

Point PandaOS at any folder to turn it into a project. For code projects, PandaOS automatically detects the framework (Next.js, Vite, Python, and others) and suggests a dev server command. For non-code projects like writing, research, or design, it simply indexes whatever files are inside so Panda can reference them in conversation.

You can also start from a template to get a pre-configured starting point with rules, starter files, and recommended skills already in place.

What a project gives you

Compared to a standalone chat, a project unlocks:

  • Persistent rules that steer Panda across every session, so you never re-explain your conventions.
  • Knowledge files that give Panda domain context beyond what lives in the code.
  • Dev servers with a live browser preview, creating a tight edit-see-verify loop.
  • Git integration with AI-generated commit messages grounded in real diffs.
  • A full workspace with file explorer, terminal, and browser side by side with the chat.
  • Connected apps like Supabase, Vercel, or Google Drive scoped to this project.

All of this persists between sessions. When you reopen a project next week, Panda picks up exactly where it left off.

Monorepo support

If your code lives in a subfolder of a larger repository, set the app root to the subfolder that actually runs, for example apps/frontend/. PandaOS treats that subfolder as the working directory for dev servers and file operations, while still seeing the wider repository for Git history and cross-package references. This is essential for monorepos where the deployable unit is a subdirectory, not the repo root.