Features

Features are the atomic units of work that get built. Everything between "we should solve X" and "we shipped Y" lives here.

What you'll see

• List view: table with type, title, status, priority, effort, estimate / hours spent, start and target dates, sprint, code (PR count), progress, assignees, lead, product / module, and link counts
• Sprint board view: Kanban grouped by sprint, status, or assignee
• Filter bar: status, type, priority, effort, assignee, start / target date, product, module, persona. The Assignee filter lists people under their team, with people who have no team under No team; tick a team to select everyone on it, and a filter holding a whole team shows the team's name

Row drawer

Three rails:

1. Spec: description, specifications, acceptance criteria
2. Strategic context: linked themes, linked initiatives, linked feedback, linked outcomes (the outcomes this feature is meant to move, linked directly; add one with + Add under Outcomes)
3. Build context: lead, type, estimate / hours spent, sprint, assignees with allocation %, dependencies (features this one depends on), product / module

Common actions

• Entity-context shortcuts (active when a row has focus): ⌘O open details, ⌘I ask Copilot, N F create a feature linked to this entity, N I create an initiative linked, L link to existing, A assign team member
• ProductSense button in the toolbar (on this page m toggles My Work, not ProductSense)
• Send to Claude Code button on the feature drawer, dispatches a GitHub Action with this feature's full context (needs a saved spec and the GitHub App connection)
• Open in Claude Code beside it hands the same context to Claude Code on your own machine and opens a local session on the Code page

G E jumps to Features from anywhere (G R goes to Releases, G P to the Roadmap).

Merging duplicates

When the same work was filed twice, fold one into the other: Merge into… in a row's right-click menu, or in the More actions menu of an open feature. Pick the feature that survives, and the review shows what would move before anything is written: themes, initiatives, feedback, personas, releases, outcomes, deal blockers, assignees, dependencies, pull requests and other links, Claude Code sessions, comments and files. Keep the other one swaps which survives. Ctrl/Cmd+Enter merges.

The survivor keeps its own title, status, priority and progress. It takes the duplicate's description and specifications under a Merged from line, any field it had empty, the sum of both estimates and hours spent, and acceptance criteria it did not have. The duplicate goes to the trash, and its ID and old links now open the survivor. Restoring the duplicate from the trash brings it back without its links, which stay on the survivor.

While a new feature is still a draft, a Possibly already filed panel under its title lists existing features with a similar title, each with Open (in a new tab, so the draft stays) and Merge into it, which folds the draft into the existing feature instead of keeping both. It matches on shared words, so it can be wrong; hover a title to see why it matched, or dismiss the panel.

Themes and feedback merge the same way. Over the MCP server the action is merge_entities, run through execute_destructive_action with a dry run first.

Status semantics

Linear flow discovery → planned → in-progress → in-review → testing → shipped (or wont-do as the terminal escape), plus two side states, blocked and parking-lot, that can be entered and left freely without counting as a regression. Automated moves (a PR merge, the MCP update_feature_status tool, an AI action) never move a feature backwards past a status a person set. For a Claude Code session's pull request, opening it for review moves in-progress → in-review (a draft stays in progress until it is marked ready), going back to draft or closing it unmerged moves it back, and the merge advances it to testing; shipping stays a human decision after QA. In review counts as active work in My Work and on the dashboard, but not toward the assignee's capacity. Setting shipped through those automated paths also settles Progress to 100, the only status where that number is unambiguous. The MCP update_feature_status tool is the standard way Claude Code sessions advance status, see MCP server.

Work-item fields

Features double as dev work items. Each carries a Type from the workspace's catalog (from Settings → Work-Item Types; Feature, Bug and Tech-Debt by default, add your own there; only roadmap-flagged types appear on the Roadmap page and the public roadmap), numeric Effort Estimate (hours) and Hours Spent for sprint capacity/velocity (alongside the XS–XL t-shirt effort), and an optional Lead (the single accountable owner, distinct from the assigned-members working set).

Data flow

Created from a theme promotion (carrying linked feedback) or manually. Tasks live in feature_tasks. Junction tables: theme_features, feedback_features, feature_initiatives, feature_personas, release_features, outcome_features, team_member_features, feature_dependencies.

Dev-shaping surface

The Features page doubles as the dev planning board:

• My Work chip: filters to features you're assigned to via team_member_features (being the Lead alone doesn't count). m toggles it.
• Sprint chips: All, Earlier, the previous sprint, the current one and the next one, and Backlog, labelled with the sprint names from the workspace's Sprint Cadence (e.g. Sprint 12). Sprints are computed from the cadence; nothing is stored per sprint. Chips are multi-select: click several to see their work together, click one again to drop it, and All clears the selection. Earlier brings back the sprint before the earliest chip each time you click it, and its count is how many items sit in sprints further back; the chip beside it hides the earlier sprints again. S N / S P step a single chip along the row.
• Code column: a PR-count badge per row (open, merged, closed), populated once a repo is connected through the GitHub App.
• Sprint board view: Kanban whose columns are sprints (or statuses, or assignees); dragging a card to a sprint writes target_date to that sprint's midpoint, dragging to Backlog clears it. Grouped by sprint, the columns follow the sprint chips: one per chip under All, or only the selected ones. Each column header shows the sprint, its item count and dates, with the column's estimated and spent hours on the line below. Right-click a column's header to hide it: a sprint column unselects its chip (pick the chip, or All, to bring it back), and a status or assignee column stays hidden in your browser until you press the hidden tab at the start of the board.
• Sprint setter: pick the sprint from the row drawer, or edit the target date inline in the data table. The table's Sprint column is derived from target_date and is read-only.

Tasks

Every Work item carries a Tasks checklist below its specifications: the steps it takes to get the work done. Each change saves as you make it, with no Save needed.

• Type in Add a task and press Enter; focus stays in the field so you can type a whole list. Pasting several lines adds one task per line, with list markers (-, 1., [ ]) taken off. Assign and Due beside the field go on the next task you add (or on each line you paste), then clear.
• Tick the box to mark a task done. The header shows how many are done (3/5), and Set progress to 60% copies that share into the Progress field (save the Work item to keep it).
• Click a task's title to rename it (Enter saves, Esc cancels). Alt+↑ / Alt+↓ move the focused task; the … menu moves or deletes it.
• Assign gives a task to a team member and Due sets a date; a date that has passed on an open task shows in red.

Members and above can change tasks; viewers and commenters see them read-only. Adding, renaming, ticking and removing a task is recorded in the Work item's Activity. Tasks are also available over the REST API at /api/v1/features/{id}/tasks, and to Claude through the MCP connector (get_feature, add_feature_tasks, update_feature_task, delete_feature_tasks).

Documents on the row drawer

Below the spec, a Documents block lists every linked external resource, grouped into five sub-sections with icons and count bubbles:

• Documentation: Notion pages (notion_page)
• Design: Figma files (figma_file)
• Code: GitHub PRs, commits, issues, branches, Claude Code sessions, and repo paths (github_pr, github_commit, github_issue, github_branch, claude_session, repo_path). A commit shows as owner/repo@abc1234, with its short SHA.
• Artifacts: Claude artifacts (claude_artifact), from a claude.ai or claude.site artifact link
• Other links: any other web page (other_link)

An artifact or other link takes an optional title when you add it; without one the row shows the link's address.

Cached Notion snippets attached here are also pulled into the AI context bundle for spec generation.

Comments

Every feature has a threaded comments section directly above the activity log. Inline @ autocomplete tags workspace members (which sends them a Mentioned in a comment notification). A comment posted from Claude through the MCP connector tags people the same way: write @ and their full name, or pass them in add_comment's mentions. Ctrl/Cmd+Enter sends; deletes are soft and undoable via toast; replies are one level deep.

To show a screenshot, paste it into the comment or reply box with Ctrl/Cmd+V, or drop an image file on the box. It uploads straight away and waits as a thumbnail under the box (hover it and click × to take it out) until you send. The posted comment shows the image below its text, and clicking it opens the file viewer. Pasting cells from Excel or text from Word still pastes the text. Comment images are listed on the Attachments tab marked In a comment. Adding images needs the same access as adding attachments; anyone who can read the comment sees them.

Followers

Anyone who needs to hear about a feature without working on it can follow it: Follow under Followers in the panel's People section (or Who, in the older layout). Followers get the feature's status changes, target date changes and comments, as its Lead and assignees do. Members and up can add or remove other people with + Add, and someone added that way is told. Each change saves at once; there is nothing to Save. Followers are being rolled out: if the panel shows no Followers row, they aren't turned on for your workspace yet.

Advanced spec editor

Description and specifications are rich-text fields:

• Slash menu for blocks (headings, lists, to-dos, quotes, code, dividers). Type / at the start of a line or after a space and keep typing to filter; picking a heading, list, to-do, quote or code block turns that line into it. A / straight after a letter, as in and/or or a path, stays plain text.
• Code blocks with a language picker and syntax highlighting.
• Every save also writes the plain description / specifications text, so the API, exports and AI prompts read the same words.
• AI generators show a preview first; applying it inserts the finished draft into the editor in one step. @ mentions are a comments feature; the spec editors don't autocomplete people.

Expanding a field

Hover or click into Description or Specifications and an expand control appears at the end of the field's label row (on a touch screen it is always there). It grows the field to fill the modal, dock or page it sits in; the header and Save stay where they are. Ctrl/Cmd+Shift+Enter does the same from inside the field, and Esc or the same control brings it back. The editor isn't reloaded, so the cursor, undo history and live collaboration carry on.

Every long-form field in an entity panel has the same control: descriptions on every entity, release notes, an initiative's hypothesis, an outcome's learning and next action, battle-card talk tracks, notes and the like.

Live collaboration

Once a feature is saved, both spec editors are collaborative: typing and selections are shared in real time with anyone else viewing the same feature. There is no toggle; an unsaved draft stays local until the row exists.

Related

• Features API reference
• Initiatives page: strategic parent
• Releases page: shipping bundle