Use this skill when creating, updating, or closing a Linear issue; when the user describes untracked work that should be a Linear issue; when drafting issue content; or when the user says "create an issue", "log this in Linear", "add this to Linear", "update the issue", "close out the issue", "mark it done".
From project-managernpx claudepluginhub nthplusio/functional-claude --plugin project-managerThis skill uses the workspace's default tool permissions.
Executes pre-written implementation plans: critically reviews, follows bite-sized steps exactly, runs verifications, tracks progress with checkpoints, uses git worktrees, stops on blockers.
Guides idea refinement into designs: explores context, asks questions one-by-one, proposes approaches, presents sections for approval, writes/review specs before coding.
Dispatches parallel agents to independently tackle 2+ tasks like separate test failures or subsystems without shared state or dependencies.
Create, update, and close Linear issues with consistent, clean formatting.
Always use the appropriate template based on issue type. Keep it concise — no filler, no unnecessary sections.
## What's Broken
[One sentence: what fails and the user impact]
## Steps to Reproduce
1.
2.
## Acceptance Criteria
- [ ] Bug no longer occurs under the described conditions
- [ ] [Regression test or verification step if applicable]
## Goal
[One sentence: what we're enabling and why it matters]
## Acceptance Criteria
- [ ]
- [ ]
## Goal
[One sentence: what needs to be done and why]
## Acceptance Criteria
- [ ]
Ask the user: "Is this a bug, feature, or task?" — or classify from context.
Fill in the template based on the user's description. Ask clarifying questions only if the problem statement or acceptance criteria are unclear.
Quality checklist before creating:
Scoping rule: Each issue should be completable in a single PR. If the user describes a large feature (e.g., "add auth system"), suggest decomposing it into a parent issue with sub-issues (e.g., "add middleware", "add token refresh", "add logout"). The parent issue needs no PR — it closes when all sub-issues close.
Show the draft to the user for quick review, then create:
save_issue {
team: "<team_key>",
title: "<concise title>",
description: "<template content>",
priority: <1-4>, // 1=urgent, 2=high, 3=normal, 4=low
assignee: "me",
project: "<project_name>" // only if linear_project_id is set in project config
}
If a linear_project_id is configured, always attach new issues to that project. If not set, create issues at the team level only.
Update ~/.claude/project-manager/cache/<slug>/context.json with the new issue ID and title.
When work in progress diverges from the issue description:
get_issue { id: "<issue_id>" }save_issue { id: "<issue_id>", title?, description?, state? }Linear auto-closes issues via PR descriptions when using the Closes <ID> format in PRs. Do not manually close issues unless:
To manually close: save_issue { id: "<issue_id>", state: "completed" }
To find available states: list_issue_statuses { team: "<team_key>" }.
When the user describes work, check if it matches an open issue:
list_issues { query: "<keywords>", team: "<team_key>", project: "<project_name>" }
Include project in the search if linear_project_id is configured, to avoid matching issues from other projects.