Projects & tasks

Projects and tasks: the core of Elliptic

Projects are how you group a stream of work, and work items (tasks) are the individual pieces of it. Together they are the spine that everything else in Elliptic hangs off: meetings turn into tasks, notes spin off tasks, the activity log records every status change, and your inbox is driven by tasks you are assigned to or watching. If you have used Linear, the model will feel familiar. Every work item gets a short, human identifier like WEB-42, moves through a small set of statuses, and lives on a board you can drag work across.

Projects as containers

A project is a named container for related work, scoped to your organization. It holds tasks, meetings, and notes, plus a living brief (the Overview) where you write the vision and pin links. Each project has a permanent key, an optional icon, a lead, a default assignee, a target date, an estimate scale, a set of project labels, and the members who can see and work in it. A project can also belong to a team.

The project key

The key is the most important decision you make when creating a project, because it becomes permanent shorthand for every task inside it. A project keyed WEB produces tasks WEB-1, WEB-2, WEB-3, and so on. The key must be 2 to 6 uppercase letters (WEB, OPS, GROWTH) and must be unique within your organization, so two projects cannot share a key. Pick something short and obvious. It is what people will type and say out loud.

Creating a project

1. 1
   Open Projects and click New project

   From the Projects page, click New project. If you have no projects yet, the empty state offers the same button.
2. 2
   Enter a name

   Type a clear name like "Website redesign". The name must be 1 to 255 characters.
3. 3
   Set the key

   Enter 2 to 6 uppercase letters, for example WEB. If a project in your org already uses that key, creation is rejected and you will need a different one.
4. 4
   Add a description (optional)

   Describe what the project is about. You can flesh this out later in the Overview brief with rich formatting, mentions, and links.
5. 5
   Create

   Click Create project. You become its first member with the admin project role automatically, and you land in its workspace ready to add tasks.

When you create a project, the org also records a "project created" entry in the activity log, so the team can see it appear.

Fields you set on a project

Per-feature tab toggles

Not every project needs every surface. A project's features are a set of per-tab toggles you flip in Settings, and each one shows or hides a tab. Timeline, Cycles, Milestones, Modules, Meetings, and Notes are all toggleable. They are on by default. Turn off the ones a given project does not use to keep its workspace focused. The core tabs (Overview, Updates, Board, Tasks, Epics, Calendar, Register, Insights, Members, Settings) are always present.

The living brief and linked artifacts

The Overview tab is a living brief, not a static description. It is a rich-text editor where you write the project's vision and context. It autosaves as you edit. Alongside it, a Linked artifacts list holds external URLs, each with a label, so the Figma file, the spec doc, the PR, and the dashboard all sit one click away from the work.

Project lifecycle

A project's status is Active or Archived. Archiving keeps the project and its full history intact but takes it out of active flow. Archived projects show an "Archived" badge, and you cannot create or change tasks inside an archived project until you set it active again.

Deleting and restoring

Deleting a project is an admin action and is a soft delete. The project disappears from the active list but is recoverable for 30 days. Within that window an admin can open the deleted-projects list and restore one back to active. After 30 days it falls out of the recovery window and can no longer be restored.

Auto-archive and auto-close

A project can be set to manage its own end-of-life. Auto-archive archives the project after a chosen number of idle days. Auto-close transitions stale open work items to a chosen status after a chosen number of days. Both are optional timers configured per project (1 to 3650 days), and either can be cleared back off. They keep finished work from lingering without anyone tending it.

Portfolio project states

Active and Archived are the operational status. On top of that, an org can define its own portfolio states, the customizable lifecycle labels a project sits in (for example "Discovery", "In build", "Shipped"). Each org state rolls up into one of six fixed groups: Draft, Planning, Execution, Monitoring, Completed, and Cancelled. Admins create, recolor, reorder, and delete states. On the Projects page you can group by state to see the whole portfolio organized by where each project is in its lifecycle, with the fixed groups giving a stable spine regardless of how you name your states.

Project visibility and membership

A project is either private or public. A private project is visible only to its members. A public project is discoverable by anyone in the org and can be joined without an invitation.

Browse and join

The Browse page is the directory of public, active projects. Each row shows the project, its lead, and its member count, and lets you join in one click. Joining adds you as a member straight away. This is how someone finds the project they should be contributing to without waiting for an admin to add them. (A guest who joins lands as a commenter rather than a full member.)

Project members and project roles

Members are the people who can work in a project. Assignees must be members, so you cannot assign a task to someone who is not on the project. On top of the org-wide role, every project member also carries a project role, a second axis that controls what they can do inside that one project:

A few rules keep projects sane: a person must already belong to your org before you can add them to a project, you cannot remove yourself, and a project must always keep at least one member, so the last member cannot be removed. Org guests are capped at the lower two project roles (viewer or commenter), so an outside collaborator can never be made a project admin. When you are added to a project, you get a notification.

Subscriptions

Independently of membership, you can subscribe to a project to opt into its notification stream. Subscribing and unsubscribing is a personal toggle and does not affect your access or anyone else's. Membership is about who can work in the project. Subscription is about what lands in your inbox.

Project updates and templates

State of Project updates (RAG)

On the Updates tab you post a State of Project update: a short written summary paired with a RAG health signal, On track, At risk, or Off track. Updates are stamped with who posted them and when, and they stack into a running history so anyone can scroll the project's health over time. This is the lightweight status report that replaces the weekly "how's it going" thread.

Project templates

When you have a project shape you repeat (a launch, a client onboarding, a sprint scaffold), save it as a project template. The template captures a snapshot of the project's config, its visibility, feature toggles, estimate scale, and labels, plus its current top-level work items as seed items (each seed remembers its title, status, priority, and kind). Instantiating the template creates a brand-new project from that snapshot: you give it a name and a fresh key, and it arrives pre-populated with the seed work items, ready to run.

1. 1
   Shape one project the way you like it

   Set the features, estimate scale, labels, and a starter set of work items on a project that represents your repeatable process.
2. 2
   Save it as a template

   Save the project as a template with a name and optional description. The config and seed items are snapshotted at that moment.
3. 3
   Instantiate when you need it

   Create a new project from the template, supplying a new name and a new 2-to-6-letter key. The seed work items are created in the new project automatically.

Work items: the anatomy

Every work item gets a stable identifier of the form KEY-number, for example WEB-42. The number is assigned per project and counts up from 1: the first task in WEB is WEB-1, the next is WEB-2. Numbering is allocated under a per-project row lock, so even if several people (or agents) create tasks at the same moment, no two ever collide on a number. The identifier is what you reference in conversation, search, and links.

Title and description

A work item has a title (1 to 500 characters, required) and an optional rich description where the real context lives: the problem, the links, the plan. The description supports the same block editing as notes and the project brief.

Kinds and conversion

Every work item has a kind: Task, Bug, Story, or Epic. A task is the ordinary unit of work. A bug is a defect. A story is a user-facing slice. An epic is a top-level container for a larger body of work. You can convert a work item from one kind to another at any time, and conversion is smart about staying valid: promoting to an epic detaches it from any parent (epics are top-level), converting to a plain task clears bug severity, and converting to a bug with no severity yet defaults it to Medium so the item stays valid.

Bugs: severity, release-blocker, and SLA

A bug must always carry a severity: Low, Medium, High, or Critical. You cannot save a bug without one, and converting a bug to a plain task clears it. Severity does real work. If a bug has no explicit due date, Elliptic derives one automatically as an SLA from the severity:

Any work item can also be flagged a release blocker, an explicit marker that it must be resolved before the next release ships. Together these support a zero-bug practice where every bug carries an explicit severity, a deadline, and a clear answer to "does this hold the release?"

Type hierarchy levels

Kinds also carry an org-scoped hierarchy level that governs nesting. By default an Epic is level 3, a Story is level 2, and a Task and a Bug are level 1. The rule is that a child may not nest under a parent of a strictly lower level, so you cannot file an epic under a task, but same-level nesting (a task under a task) stays allowed. Admins can adjust the levels per kind to match how their org thinks about its work breakdown.

Core fields

Statuses and immutable categories

A work item moves through a fixed set of statuses. Six appear as columns on the board, in this order:

There is also a Duplicate status, used when a work item is folded into another. It is treated like Cancelled for progress and is not shown as its own board column. Each status maps to an immutable category, Backlog, Unstarted, Started, Completed, or Cancelled. Categories are fixed in code and never editable. They are the stable spine that progress math, focus ordering, and AI summaries read, so the system understands "this is started work" no matter how a team renames its statuses.

Priorities

Priority orders attention. The levels, highest to lowest, are Urgent, High, Medium, Low, and No priority (the default). Priority drives the ordering in Your Work and in priority swimlanes on the board. Marking a task Urgent when it has an assignee (and was not already urgent) sends that person an urgent notification, so it is a real signal, not just a color.

Assignees and bot assignees

A work item can have a human assignee and, independently, a bot assignee, an AI user in the org. The human assignee must be a project member, and assigning someone other than yourself notifies them and auto-subscribes them so they follow the task. The bot assignee is how you hand work to an agent: it must be an AI user that exists in the org, and the agent then operates the task over MCP on the org's key. The two are cleared independently, so a task can be owned by a person, by an agent, by both, or by neither. The assignee picker only lists people who are on the project.

Labels

Labels are org-scoped tags with a name and a color, shared across all projects. You create them once for the organization (each name is unique) and then attach any number to a work item. Labels are useful for cross-cutting themes like "design", "infra", or "customer-request". You can filter by them and delete a label org-wide when it is no longer needed. (Projects can also keep their own project-level label values for slicing within one project.)

Estimates

A work item can carry an estimate drawn from the project's estimate scale, so a points project estimates in points and a t-shirt project estimates in sizes. The scale is whatever ordered list the project defines, which keeps estimation consistent within a project without forcing one scheme on the whole org.

Dates

A work item can carry an optional start date and due date. For bugs, the due date is auto-derived from severity as an SLA when you do not set one (see above).

Components

A work item can be tagged with a component, a short free-text label for the part of the system it touches (for example "checkout" or "auth"). It is a lightweight way to slice a project by area.

Custom fields and properties

Beyond the built-in fields, a project can define custom properties that attach extra structured data to its work items, stored per item. This lets a team capture the fields specific to their process (a customer name, a risk score, an environment) without bending the standard fields out of shape.

Structure and relationships

Sub-tasks and the progress pill

A work item can have sub-tasks, managed from its detail panel. Sub-tasks live in the same project as their parent and are limited to one level, so a sub-task cannot itself have sub-tasks. Nesting also respects the type-level rule, so you cannot file a higher-level kind under a lower-level one. The parent shows a progress pill (for example 2/5) computed from its sub-tasks with category math, so cancelled and duplicate sub-tasks do not count against it.

Typed relations

From a work item's detail you can link it to another with a typed relation: blocks / blocked by, related, duplicate / duplicate of, or implements / implemented by. Only canonical directions are stored. "Related" is symmetric, and the inverse forms (blocked by, duplicate of, implemented by) are derived by reading the stored relation from the other task's point of view, so each side always shows the right label. You can relate to many targets at once in bulk, and the relations panel groups them by type. An org can also define its own custom relation types, each with an outward and inward label, for relationships the built-in set does not cover.

The Blocked badge

A work item that is blocked by an open (not Done or Cancelled) item shows a Blocked badge on its card, so you can see at a glance what is stuck and why. The badge clears automatically once the blocker is resolved.

Duplicate detection and not-duplicate suppression

When you create or look at a work item, Elliptic can surface likely duplicate candidates in the same project by token overlap against other open items, each with a similarity score, so you catch a re-filed issue before it becomes a second copy. If a suggestion is wrong, mark the pair not a duplicate and that pairing is suppressed from future suggestions, so the same false match does not keep resurfacing. When something genuinely is a duplicate, fold it into the original and its status becomes Duplicate.

Quality gates on the item

Definition of Done and acceptance criteria

A work item can carry a Definition of Done, a checklist of conditions that must be true before it counts as finished, and a free-text acceptance criteria field describing what "correct" looks like. Together they make "done" explicit on the item itself, so reviewers and agents are checking against the same bar the author intended.

Description version history

Every change to a work item's description snapshots the previous text into a version history, attributed to whoever made the edit. You can review the prior versions and restore one non-destructively (the restore itself becomes a new version), so a description can never be silently overwritten and lost.

Per-item progress updates

Just like a project, an individual work item can carry its own progress updates, a short summary plus a RAG health (On track / At risk / Off track). Use them on long-running epics or stories to keep a running narrative of where the item stands without burying it in comments.

External links and note links

A work item can hold external links, labeled URLs (a PR, a dashboard, a design), and structured note links that tie it to notes or pages in the workspace. Note links are bidirectional, so the connection shows from both the task and the note. Both keep the surrounding context one click from the work.

Creating work in bulk and at speed

There are several ways to add work, from fastest to most detailed.

Inline composer (fastest)

1. 1
   Open a project's Board tab

   Each status column has an Add task affordance at the bottom, and a + button in the column header that opens the same inline composer.
2. 2
   Type a title and press Enter

   The task is created instantly in that column's status. The composer stays focused so you can keep adding one after another.
3. 3
   Pick a kind if needed

   A small Task / Bug / Story / Epic toggle lets you set the kind for the row (a Bug defaults its severity to Medium). For more fields, open the full dialog with the Add details button, which carries nothing over but lets you set everything.

The full dialog

Press the c shortcut anywhere on a project's Board or Tasks tab (any text you have selected is carried into the title), or use the board's Add details button or the Tasks tab's New task button. Here you set the title (required), a description, the kind (with severity when it is a bug), and the starting status, priority, and assignee, along with labels, dates, component, and estimate. The assignee list is limited to project members. The dialog can surface duplicate candidates as you type the title.

From meetings and notes, with provenance

Tasks can be created with provenance, a link back to the meeting or note they came from. You can batch-create several at once from a list of text lines (for example, action items extracted from a meeting), all sharing the same source. When a meeting-derived task is later marked Done, Elliptic records that back on the meeting and notifies the attendees, closing the loop.

Beyond meeting batches, you can paste a CSV to bulk-create work items in one click, a one-shot migration path from a spreadsheet or another tracker. The importer reads common column names (title, summary, status, priority, description, and their synonyms), maps foreign status and priority words onto Elliptic values, treats a type of "bug" or "defect" as a Bug (defaulting its severity to Medium), and reports how many items it created, how many it skipped, and any per-row errors.

Work-item templates

For recurring shapes of work (a release checklist item, a standard bug report), a project can keep work-item templates that pre-fill the title, description, priority, and kind. Picking a template scaffolds a new item from it so you are not retyping the same boilerplate.

The /new quick-create deep link

/app/<org>/new is a deep link that opens the create dialog directly, pre-filled from query parameters. It accepts project (id or key), title, description, priority, and assignee (use me for yourself). It is the link you wire into a button, a bookmark, or an automation to drop someone straight into creating a task with the fields already set.

Git branch suggestion

Each work item can suggest a git branch name built from the project key, the task number, and the title, so the branch you cut matches the identifier you track. It keeps the code and the task linked by name without anyone inventing a convention.

Viewing work

The board (Kanban)

The Board tab lays work items out as Kanban columns, one per status, in workflow order (Duplicate is excluded). A progress bar at the top shows the project's completion percentage and completed/total count. Across the top you get a filter box (matches title or identifier), status and assignee filters, a Group by control, and display options. Drag a card across columns to change its status.

You can group the board into swimlanes by Assignee or Priority (or None for a flat board). With swimlanes on, each person or priority gets its own row of columns, with counts, and you can collapse and expand lanes (press t to collapse or expand all). Dragging a card between an assignee or priority lane reassigns or repriorities it as well as moving its status.

List / table view

The Tasks tab is a dense table of the same items, with columns for Task, Status, Priority, Assignee, Labels, Due, Progress, and Updated (each toggleable via display options). A density toggle switches between comfortable and compact rows. The same filters apply, and a counter shows the filtered count. Double-click a row to open the item; click and Shift/Cmd-click to select rows for bulk actions. Press Cmd/Ctrl+B to flip between the board and the list.

Calendar

The Calendar tab lays work items out on a date grid by their due dates, so deadline pressure is visible at a glance and a crowded week is obvious before it arrives.

Filtering

Project task lists filter on status, assignee, label, bug severity, release-blocker, module, and cycle, plus a free-text search over title and description. Combine them to carve out exactly the slice you care about (for example, all release-blocker bugs of High severity assigned to you).

Status transition history and dwell time

Every status change is recorded. A work item's transition history lists each move with who made it and how long the item sat in the previous status, plus how long it has been in its current one. That dwell time turns "this has been in review forever" from a feeling into a number, and feeds throughput analytics on the project.

Archive and restore

You can archive a work item to take it out of the active board and list without deleting it, and restore it later. Archived items are hidden by default and surfaced with an include-archived toggle. (This is distinct from the Cancelled status, which keeps the item on the board as explicitly dropped.)

Export

A project's tasks export to CSV or JSON, optionally filtered by status. The CSV export is hardened against spreadsheet formula injection, so cells that begin with =, +, -, or @ are neutralized before download and cannot execute when the file is opened.

Deleting a work item

Deleting a work item removes it permanently (it is recorded in the activity log by identifier). Unlike projects, task deletion is not a recoverable soft-delete, so delete only when you are sure. To drop an item without losing the record, set it to Cancelled or archive it instead.

Your Work

Your Work in the sidebar gathers your plate into one place so you do not have to hop between projects. The web page leads with two tabs over your active projects, Assigned (everything assigned to you) and Created by me (everything you filed). Over MCP, list_my_tasks exposes the same plus two more slices: Subscribed (everything you are watching) and Recent (your latest task activity).

Focus ordering

Instead of grouping by raw status, Your Work groups by focus, in this order:

• Urgent, anything you have marked urgent, surfaced first.
• Blocking, work that is holding up other tasks.
• In progress, what you are actively working on.
• Up next, committed but not started.
• Backlog, captured, not yet committed.
• Done, completed and cancelled, at the bottom.

Within each group, started work floats to the top, then higher priority, then most recently updated. Each row shows the status dot, priority, the KEY-number identifier, the title, a context line, the project key badge, and when it was last updated.

Workload summary and watching

A workload summary sits above the list, counting your Open, In progress, and Done items so you can read your load at a glance. Watching is the Subscribed slice: subscribe to any task with the bell to follow it without owning it, and it feeds your inbox. Assigning someone auto-subscribes them, so owners follow their work by default.