Workspace and projects

A Code workspace is one or more folders you shared. Everything the assistant reads or changes lives inside them.

Adding a project

Before the first message, the workspace row in the middle of the window is where you pick a folder. Its menu has:

During a conversation, the Files tab has an Add folder row at the top. That is the way to bring in a folder halfway through, once it turns out the change reaches into a neighbouring package.

Why several folders instead of the parent

If two projects sit next to each other, share both of them rather than their common parent. Sharing the parent shares every unrelated project in it as well.

The panel surfaces (file tree, terminal, Git, preview) work across the whole active set. The editor and the preview stay anchored to the primary folder, so adding a second folder does not throw away the file you have open.

Starting a new project

If the shared folder holds no project yet, the preview tab offers to create a web app: it scaffolds a Next.js project with TypeScript and Tailwind, then starts the dev server so you see a running page rather than an empty folder.

Because the scaffolding tool refuses a non-empty target, the project is created one level down first and then promoted into the folder root and named after it.

For anything else, just say so: "set up a Python project here with a virtual environment and pytest" is a normal task, and it runs in the terminal like any other command.

Starting an existing project

Click Start in the preview tab and the app works out how to launch the project instead of asking you for a command:

• A Node project with a start script, using whichever package manager its lockfile indicates.
• Deno, Django, PHP and Rails each have their own fallback.
• A static site with an index.html is served directly, with no build step.
• If nothing recognisable is there, it says so rather than guessing.

The project brief

A dgpt.md (or CLAUDE.md) at the root of a shared folder is read as the project brief before every turn: conventions, the commands that matter, things not to touch, what the project actually is.

This is the single highest-leverage file in the workspace. Almost every "why does it keep doing that" has its answer here.

/init analyses the workspace and writes a first version for you. Edit it afterwards, since you know things the assistant cannot infer.

Instructions in subdirectories

An instruction file deeper in the tree is announced by path rather than pasted in. The assistant knows it exists and reads it when it works in that area, so a monorepo with twenty of them does not spend its whole budget on briefs.

A file too large for the budget is cut with an explicit marker instead of being silently truncated, so the assistant always knows there is more.

Your own rules, across every project

~/.deutschlandgpt/anweisungen.md in your home directory holds rules that apply in every workspace: how you like commits worded, that you run the tests yourself, which style you prefer.

These come before the project files, and the assistant is told the order explicitly: if a project instruction contradicts your personal rule, the project wins. That is the right way round, since the project is the more specific context.

The same folder can hold personal skills and commands, see Commands.

The .deutschlandgpt folder

Per shared project, this folder is where the assistant and you meet:

.deutschlandgpt/
├── README.md    explains the structure
├── skills/      your own skills
├── commands/    your own slash commands
├── plans/       written by the assistant in plan mode
└── reviews/     written by the assistant on /code-review

Commit it if the skills and commands should be shared with your team. Add it to .gitignore if the plans and reviews are only yours.