Skip to content

BERD TASK · 0005 · SHAPE THE WORKSPACE

Create a project around your folders

A project gives an engagement a home: the folders the work lives in, a standing description every chat inherits, and a rule for how new chats treat those folders. Get the rule right at creation, because it touches real repositories.

Steps at a glance

  1. Name it and write what the agent should know
  2. Add the folders the work lives in
  3. Set the new-chat behaviour for each Git folder
  4. Name the worktree or branch when a chat asks
  5. Archive rather than delete

1. Name it and write what the agent should know

New project opens a dialog with two questions. What are you working on? is the name. What should the agent know about this project? is the standing context — the placeholder suggests goals, context, instructions, links to docs. Every chat started in the project gets it. Write it the way you would brief a new colleague on day one: the client, the deliverable, the constraints, the words you do and do not use.

One thing is not settled from source. The strings also carry a separate Instructions field described as a system prompt or context for agents working in the project. Whether that is the same control under another name or a second field is not verified; if you see both, put the brief in the one the dialog shows you first and check what the other does.

Colour and icon are yours to choose; there is a set of presets and you can upload your own. On Home, a project becomes a coloured cube, so pick colours you can tell apart.

[SCREENSHOT: T05-01 — new project dialog, empty]

2. Add the folders the work lives in

Under Project folders, add one or more: a plain directory, a Git repository, or an existing worktree. Add another whenever the engagement spans more than one place. A folder that later disappears or becomes inaccessible is flagged in the dialog rather than silently dropped.

The folders are what the agent can see and change from any chat in the project. Add what the work needs and nothing more; a project pointed at your whole home directory is a project with no boundary.

3. Set the new-chat behaviour for each Git folder

This is the step that matters. For every folder that is a Git repository, the dialog asks New chat behavior for {folder}. The choices:

  • Auto-create worktrees — each new chat gets its own working copy of the repo, on its own branch, so chats cannot tread on each other's files.
  • Manually create worktrees — the chat asks you each time.
  • Don't create worktrees — chats work in the folder as it is.

Alongside, a chat can Create worktree, Create branch, or Use as-is. A folder that is not a Git repository shows No Git repository — worktrees unavailable and skips all of this.

Choosing a folder that is itself a worktree gets a confirmation: new chats will create a separate worktree from the same repository rather than reuse that one.

[SCREENSHOT: T05-02 — folder policy per Git folder]

4. Name the worktree or branch when a chat asks

If the project creates worktrees or branches, a new chat opens with Add worktrees and branches to new chat and asks for one name that applies to all of them. Folder-name rules apply: not . or .., no slashes. Skip and use as-is bypasses it for this chat only. Name by the piece of work, not the date; you will be reading these names in the right rail for weeks.

[SCREENSHOT: T05-03 — startup name prompt]

5. Archive rather than delete

Deleting a project shows a warning worth quoting: it cannot be undone and you will lose all context and memory associated with the project. Archive instead. An archived project leaves the Projects view and reappears under Archived projects in the archive section of Settings — not in Projects, which is where people look first and conclude it is gone. Berd's help makes the same point: active and archived are two different surfaces.

[SCREENSHOT: T05-04 — archived projects in Settings]

Watch out

Yes, delete on a project is permanent and takes the project's context and memory with it. Nothing on this page except that button destroys anything.

Practitioner decision

Two documented policies for an engagement repository, and the house has to pick one. Auto-create worktrees: every chat is isolated, parallel chats are safe, and the cost is disk space plus a rule the consultant must learn — a Goose-created worktree is deleted from disk, uncommitted changes included, when its workspace is removed or its chat is archived. Use as-is: chats share one working copy, nothing is ever created or deleted behind the consultant's back, and the cost is that two chats editing the same files will collide. Recommendation: Use as-is as the house default for consultants who do not already work with Git branches, and Auto-create worktrees only on repositories where the consultant commits routinely and has read Attach workspaces and use the right rail. Practitioner writes the standard here.

Last checked: Berd v0.6.4, 2026-09-11 — read from source and release notes, not yet tested in the app.

Learn more

Reference

Moment
apply
Takes
10 min
Steps
5
Verified
Berd v0.6.4 · 2026-09-11 · source-read
NEVER BESTUCK AGAINCLICK ME

Guide built with Berd, Claude and Codex · verified against Berd v0.6.4, 2026-09-11 · read from source, not yet tested in the app · Buzz Guide · About · not affiliated with Block