Projects
Group related issues and track them as one unit — with priority, status, progress, and an owner.
A project in Multica is a container for related issues. Use it when a body of work is bigger than one issue but smaller than a full workspace — a launch, a migration, a feature with multiple parts, an investigation that branches into several threads.
Each project has a name, an icon, a description, a lead (a member or an agent), a status (planned / in_progress / paused / completed / cancelled), a priority (urgent / high / medium / low / none), and a progress percentage that's auto-derived from the status of its linked issues.
How projects relate to issues
Projects and issues are independent objects with a many-to-one relationship: an issue can belong to at most one project; a project holds any number of issues. Linking and unlinking is reversible at any time — drag in the board view, or use the project picker on the issue's right-side properties panel.
The progress bar on a project is computed from its linked issues — the more issues hit done, the further it fills. Issues that are cancelled are excluded from the count; issues in backlog count toward the denominator but not the numerator.
Pinning to the sidebar
Click the pin icon in a project's top-right corner to add it to your sidebar's pinned list. Pinned projects stay one click away no matter where you are in the workspace; everyone on the team can pin independently — pins are personal.
The sidebar Workspace → Projects link always shows every project in the workspace; pinning is a personal shortcut on top of that.
Attaching resources
Each project has a Resources section where you attach typed context pointers. Today that usually means GitHub repositories, and it can also mean a local directory bound to a specific daemon. Once attached, any agent assigned to issues in this project receives the project resource list as scoped context for its task.
GitHub repos can be added from the New Project flow or later from the project Resources section. Local directories are attached from the CLI because the web app cannot open a native folder picker.
Resources are per-project; if multiple projects share a repo or local checkout, attach it to each project that should expose it to agents. See Project Resources for the exact resource types, CLI commands, and daemon behavior.
Deleting a project
Deleting a project does not delete its issues. The linked issues are simply unlinked and revert to the workspace's flat issue list. This is intentional — work that was scoped to a project is rarely throwaway, even when the framing of the project changes.
If you want to delete the work too, archive or delete the issues first, then delete the project.
Project lead
The lead is the person — or agent — accountable for the project. It's a soft signal, not an access control: any workspace member can edit a project regardless of who's lead. A project's lead can be:
- A workspace member (human teammate)
- An agent — useful when the project's work is mostly delegated to an agent (e.g., "Weekly bug triage" led by a triage agent)
Next
- Issues — the unit of work that lives inside projects
- Agents as project lead — when an agent is the right owner
- How Multica works — the broader picture