Projects

A project is a working context: one initiative, with its own conversation, its own memory, and its own view of everything that conversation touches.

Why projects rather than folders

A folder holds files you put in it. A project accumulates context you didn't have to file.

Ask the assistant about a ticket inside a project and that ticket becomes part of the project's picture. Mention a spec, and the spec is there next week when someone asks what the scope was. Nothing is filed manually, because in practice nobody files things manually.

The tabs

Tab	What it holds
Chat	The project's conversation, with the assistant scoped to this project
Overview	Name, description, and the project's basic settings
Code	Repositories linked to the project
Content	Knowledge bases, pinned documents, and everything discovered
Memory	Governed, long-lived facts the assistant should carry between conversations
Settings	Custom instructions and the default agent

Project 360

The Project 360 panel — the icon in the chat header, and the Discovered section on the Content tab — is everything attached to this project, grouped by kind: epics, tickets, specs, docs, designs, pull requests.

Two things fill it:

Conversations. Anything referenced while working in the project is picked up automatically.
Your connected systems. When a tracker is connected, references are resolved against it — so a ticket gets its real title, its status and its parent epic, rather than just the key someone typed.

Pointers, never copies

Nothing in Project 360 is created or edited by work.studio. Each entry links to the real record in the system that owns it. That is deliberate: the moment we copied a ticket, we'd own a synchronisation problem and your project would start showing you stale information with confidence.

Curating it

The only action is dismiss, and it's durable — a dismissed item does not return, even if it keeps being mentioned.

There is deliberately no "approve" step. A confirmation queue is a chore almost nobody works through, so an accept-first model would leave the panel permanently empty and make the feature look broken rather than merely noisy.

Pinned documents

On the Content tab you can pin a PRD, spec, wiki page or deck.

Pinned documents are read on demand — the source stays where it lives, and the assistant fetches it when a question needs it. Pin the spec and you can ask "does the implementation match what we agreed?" without pasting anything.

Custom instructions

Under Settings, custom instructions apply to every conversation in the project.

They're for durable context, not task detail: the conventions of this codebase, who the audience is, which environment is production. Anything you find yourself re-explaining belongs here.

Memory

Project memory is governed and long-lived — facts that should survive between conversations.

It's distinct from custom instructions: instructions are what you told the assistant to do, memory is what it learned along the way. Both are visible and editable, because neither should be a black box.

Connect your tools Quick start