Group sessions into a project
Create a project to give a set of sessions a shared goal, repositories, instructions, and people.
A project groups sessions under a shared goal. Each session in it starts with the same context, so the agent doesn’t need to hear your conventions again each time. You can open Projects from the sidebar to see the ones you own, the ones you collaborate on, and the ones where you have a session. Your group and All show more of the projects you can see.
What a project holds
| It holds | What it does |
|---|---|
| Description | A line or two about what the project is for. |
| Shared context | Markdown that each session in the project reads before it starts. Use it for conventions, pitfalls, and what done looks like. |
| Files | Files that each session in the project gets. The agent reads them before it plans. |
| Repositories | The repositories new sessions start with. A session can still change its own. |
| People | The owner, plus collaborators and viewers. Collaborators can work in all of the project’s sessions, including future ones. |
| Sessions | Each session you start in the project, with the live ones first. |
| Memory | Notes the agent saves for later sessions in the project. Everyone on the project can read them, and each new session starts with them. |
| Automations | The automations that start sessions in this project. |
Create a project
-
Start a new project
Open Projects and choose New project. If you already have a session running, you can also pick Add to project on it and type a name to create one on the spot.
-
Name it
Give the project a Name. Evergreen fills in the Slug from the name. It’s lower-case words joined by hyphens, and it names the project in links.
-
Add what the agent should know
Fill in the Description and the Shared context. You can add Files by choosing Add files or dragging them onto the form.
-
Pick repositories and people
Under Repositories, choose the repositories new sessions should start with. Under People, choose Add people or groups to bring in collaborators. Adding a group adds the people in it now, not people who join the group later. You can also invite someone who doesn’t have an account yet.
-
Choose who can see it
Pick a Visibility, then choose Create project.
You can change all of this later from the project’s page.
Put a project under another
If your workspace has the Nested projects beta, a project can sit under a parent, up to three levels deep. Choose it with Parent project on New project, or on the Setup tab’s Settings card. A sub-project inherits its parent’s shared context, files, memory, and people, and the parent’s Overview lists its Sub-projects.
Who can see a project
You set this when you create the project, and you can change it from Share on the project’s page, under General access.
| Setting | Who finds and opens the project |
|---|---|
| Visible to the org | Everyone in your organization. |
| Visible to the team | Narrower than the whole organization. In practice, the owner, the people on the project, and admins. |
| Private | The owner, the people on the project, and admins. |
People on a project have one of two roles.
- Collaborator can change the project and who has access. Collaborators can work in all of its sessions, present and future.
- Viewer can see the project, but not change it.
The owner, collaborators, and viewers can open every private session in the project and in its sub-projects.
Note
On a project that’s visible to the whole organization, anyone who can see it can start a session in it. On a project that’s visible to the team, or private, only the owner, its collaborators, and admins can.
Sessions in a project that’s visible to the team, or private, start private, so only the people with access can open them. That’s the people added to a session and the project’s people. An admin who isn’t on the project steps in to open one, as Work together describes. Changing a project to one of those settings makes its public sessions private too, and General access says how many before you choose. Making a project visible to the org again leaves its sessions private.
The People card on the Setup tab lists who’s on the project and their roles. The owner, a collaborator, or an admin can change it there, and anyone on the project can remove themselves. The People card on the Overview tab links to it with Manage people.
Work in a project
A box above the tabs, with the prompt Start a session in and the project’s name, starts a new session in the project. A project’s page has these tabs:
| Tab | What you’ll find |
|---|---|
| Sessions | The project’s sessions. Switch between Everyone and Yours. The owner, a collaborator, or an admin can pin a session to the top for everyone. |
| Overview | Cards for In flight, Open pull requests, Recently merged, Recently completed, People, and Merged per week. |
| Pull requests | The pull requests the project’s sessions opened. |
| Memory | The notes the agent saved for later sessions, and the project’s files. |
| Automations | The automations that start sessions here. See Start sessions automatically. |
| Setup | Shared context, How it ships, people, settings, repositories, merging, and deleting. |
Settings on the Setup tab
The Settings card saves each change as you make it. Only the owner, a collaborator, or an admin can change them. Here’s what’s in it.
- Status is Active, Paused, or Done.
- Slack channel links the project to a channel. Mention @Evergreen there to start a session in this project, and the project’s sessions that post to Slack open a thread there, except private ones. Picking a channel needs Automations. See Slack.
- Permission mode is the mode new sessions in the project start in. Leave it on Use each person’s default, or pick a mode and then answer When it needs an answer. See Autonomy.
- Default merge policy, Minimum validation, and Default post-merge checks are what new sessions in the project start with for their pull requests. See Pull requests.
- Full-stack env picks the environment that runs the whole app for a session. Automatic lets each repository decide.
- Default model overrides each person’s own default, but a session can still pick a different model. You can also set a Planning model, an Executing model, and a Review model. See Choose a model and how hard it thinks.
Move, merge, and delete
- To move a session in or out of a project, use Add to project or Change or remove the project on the session. A public session moved into a project that’s visible to the team, or private, becomes private.
- Admins can choose Merge into another project. The sessions, notes, files, and automations move to the project you pick, the shared context is added after the target’s, and then the project is deleted. The project you pick keeps its own settings and gains this project’s repositories and collaborators. You can’t undo this.
- The owner or an admin can Delete project once it’s empty. Move its sessions out first, including archived ones, and remove its notes, files, and automations. Deleting a project removes its settings, repositories, collaborators, and shared context for everyone, and you can’t undo it.
- If the owner has left the organization, an admin, the former owner’s manager, or a collaborator sees Take over on it, and choosing it makes you the new owner. On a project that’s visible to the team, or private, a manager who isn’t on it can’t.
Last updated