linearlisted

# Linear Workflow Linear is the source of truth for what's being worked on. Keep issues in sync with reality, and treat an issue's history as shared — prefer adding over rewriting. Resolve teams, projects, labels, statuses, and people **by name** (`list_teams`, `list_projects`, `list_issue_labels`, `list_issue_statuses`, `list_users`). Never paste raw IDs. ## Before Starting a Task 1. **Search first.** Look for an existing issue before doing the work — `list_issues(query:…)`, or filter by project/label/assignee. Don't assume there isn't one. 2. **If none exists**, don't silently create it. Ask the user the scope: which team and project, and whether it's one issue or several sub-issues. Then create it per *Creating Issues*. 3. **If one exists**, read it fully (`get_issue`, `includeRelations:true`) and bring it up to date before working: - Does the status reflect reality? Move it (e.g. → In Progress). - Is the assignee whoever is actually doing it? Fix it. - Is context missing — a decision, a new constraint, a related issue? Add it as a comment. ## While Working - **Sync through comments** (`save_comment`), promptly. When you hit a blocker, change approach, or learn something that shifts scope, leave a comment — don't let the issue drift from reality, and don't bury the change by rewriting the description. - **Move status as it changes**: In Progress when you start, In Review when a PR is open, Done when merged. ## Editing the Description The description is the