# Features

> Atomic shipping units: spec'd, prioritized, allocated, and traced upstream to themes and downstream to releases.

Source: https://productos.ca/documentation/pages/golden-thread/features (last reviewed 2026-10-04)

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](https://productos.ca/documentation/pages/tools/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](https://productos.ca/documentation/api/v1/mcp) 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](https://productos.ca/documentation/api/v1/mcp).

## 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](https://productos.ca/documentation/pages/settings/overview) (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](https://productos.ca/documentation/guides/integrations/github).
- **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](https://productos.ca/documentation/api/v1/reference/features)
- [Initiatives page](https://productos.ca/documentation/pages/golden-thread/initiatives): strategic parent
- [Releases page](https://productos.ca/documentation/pages/golden-thread/releases): shipping bundle