@sentry/junior-linear 0.30.0 → 0.32.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@sentry/junior-linear",
3
- "version": "0.30.0",
3
+ "version": "0.32.0",
4
4
  "private": false,
5
5
  "publishConfig": {
6
6
  "access": "public"
@@ -1,12 +1,11 @@
1
1
  ---
2
2
  name: linear
3
3
  description: Manage Linear issues through Linear's hosted MCP server. Use when users ask to create a Linear ticket, update a Linear issue, add a Linear comment, move work between states, assign work, or look up Linear issue, team, or project details from Slack context.
4
- uses-config: linear.team linear.project
5
4
  ---
6
5
 
7
6
  # Linear Operations
8
7
 
9
- Use this skill for Linear issue workflows in the harness.
8
+ Use this skill for Linear issue workflows.
10
9
 
11
10
  ## Reference loading
12
11
 
@@ -31,10 +30,8 @@ Load references conditionally based on the request:
31
30
  - If the request refers to an existing Linear item indirectly, inspect the current thread context for the previously mentioned issue key or URL before asking the user to restate it.
32
31
  - Ask one concise follow-up only when a write is blocked after considering both explicit user input and any configured defaults, such as multiple plausible teams, no clear target issue, or no valid team for a new issue.
33
32
 
34
- 2. Discover and prepare MCP tools:
33
+ 2. Prepare the Linear operation:
35
34
 
36
- - `loadSkill` returns `available_tools` for this skill, including the exact `tool_name` values and input schemas exposed in this turn.
37
- - Call those exact tool names directly. Use `searchTools` only if you need to rediscover or filter the active Linear tools later in the turn.
38
35
  - Prefer a short read/search step before mutating when you need to confirm the existing issue, team, project, or workflow state.
39
36
 
40
37
  3. Draft issue content (create or substantial rewrite):
@@ -49,9 +46,9 @@ Classify the work as `bug`, `feature`, or `task`. Shape the title and body per [
49
46
  - Generalize session framing — strip channel references, slash commands, Slack thread IDs, user @mentions, and transcript fragments; replace with the underlying engineering problem.
50
47
  - Compress source material. Research notes, hypotheses, or transcripts become a short summary + scoped bullets — never paste raw investigation into the body.
51
48
  - Do not add desired outcome, expected behavior, or acceptance criteria unless the thread explicitly requests them.
52
- - When the request originated from a Slack thread or any on-behalf-of context, append a final line `Action taken on behalf of <name>.` using the user's real name.
49
+ - When the request originated from a Slack thread or any on-behalf-of context, append a final line `Action taken on behalf of <name>.` using the action requester's real name. The action requester is the current `<requester>` or the person who explicitly asked you to create/update the issue, not necessarily the original reporter.
53
50
 
54
- Attribute the reporter by name when clear from the thread (e.g. "Raised by Alice during incident triage") — do not reference Slack channels, threads, or conversation metadata. Attach screenshots from the thread as image links when present. Preserve relevant URLs (Sentry, GitHub, docs, repro links) inline — do not dump a link list.
51
+ Attribute the reporter by name when clear from the thread (e.g. "Raised by Alice during incident triage"). If the reporter differs from the action requester, keep them separate with durable body text such as `Reported by Alice.` — do not reference Slack channels, threads, or conversation metadata. Attach screenshots from the thread as image links when present. Preserve relevant URLs (Sentry, GitHub, docs, repro links) inline — do not dump a link list.
55
52
 
56
53
  4. Set optional Linear fields literally:
57
54
 
@@ -62,7 +59,7 @@ Attribute the reporter by name when clear from the thread (e.g. "Raised by Alice
62
59
  5. Verify draft before mutating:
63
60
 
64
61
  - Title length ≤ 60 characters.
65
- - Delegated-action footer is the last line when applicable.
62
+ - Delegated-action footer is the last line when applicable, using the action requester's real name, not the reporter's name unless they are the same person.
66
63
  - No session framing remains (channel refs, slash commands, @mentions, Slack thread IDs).
67
64
  - Body structure matches complexity — no empty sections, no restated title, no raw research dump.
68
65
 
@@ -2,14 +2,6 @@
2
2
 
3
3
  Use this reference for any Linear operation.
4
4
 
5
- ## Runtime contract
6
-
7
- - `loadSkill` returns `available_tools` for this skill, including the exact Linear MCP `tool_name` values exposed in the current turn.
8
- - Call those exact `tool_name` values directly.
9
- - Use `searchTools` only when you need to rediscover or filter the active Linear tools later in the same turn.
10
- - Do not hardcode raw Linear MCP tool names in advance. Tool discovery is part of the workflow.
11
- - Return the canonical Linear issue key or URL after successful writes.
12
-
13
5
  ## Provider capabilities
14
6
 
15
7
  Linear's hosted MCP server is intended for authenticated remote MCP access to Linear data.
@@ -26,49 +18,20 @@ The current public docs describe support for finding, creating, and updating obj
26
18
 
27
19
  ## Operation patterns
28
20
 
29
- | Intent | Minimum tool pattern |
30
- | -------------------- | ---------------------------------------------------------------------------------------------------------------- |
31
- | Inspect an issue | Resolve the issue by key, URL, or search query, then fetch current state before answering. |
21
+ | Intent | Minimum tool pattern |
22
+ | -------------------- | ---------------------------------------------------------------------------------------------------------------------------- |
23
+ | Inspect an issue | Resolve the issue by key, URL, or search query, then fetch current state before answering. |
32
24
  | Create an issue | Confirm the team first, then create the issue with grounded title/body content and only the optional fields you can justify. |
33
- | Update fields | Fetch current issue state first, then mutate only the requested fields. |
34
- | Add a comment | Resolve the exact issue first, then add a concise comment with durable links and next steps. |
35
- | Move state or assign | Read the current issue and team workflow first when state, workflow, or assignee ambiguity could cause the wrong mutation. |
36
- | Check for duplicates | Search for an existing matching issue before opening a new one when the request appears related to ongoing work. |
37
-
38
- ## Config helpers
39
-
40
- Use these commands only when the user explicitly asks to inspect or store Linear defaults for the current conversation/channel.
41
-
42
- Resolve team default:
43
-
44
- ```bash
45
- jr-rpc config get linear.team
46
- ```
47
-
48
- Set team default:
49
-
50
- ```bash
51
- jr-rpc config set linear.team Platform
52
- ```
53
-
54
- Resolve project default:
55
-
56
- ```bash
57
- jr-rpc config get linear.project
58
- ```
59
-
60
- Set project default:
61
-
62
- ```bash
63
- jr-rpc config set linear.project "Cross-team reliability"
64
- ```
25
+ | Update fields | Fetch current issue state first, then mutate only the requested fields. |
26
+ | Add a comment | Resolve the exact issue first, then add a concise comment with durable links and next steps. |
27
+ | Move state or assign | Read the current issue and team workflow first when state, workflow, or assignee ambiguity could cause the wrong mutation. |
28
+ | Check for duplicates | Search for an existing matching issue before opening a new one when the request appears related to ongoing work. |
65
29
 
66
30
  ## Content expectations
67
31
 
68
32
  - Translate Slack-thread wording into stable product or engineering language.
69
33
  - Preserve material links already present in the conversation, such as Sentry, GitHub, docs, repro, or dashboard URLs.
70
- - If the active MCP tool exposes structured link attachments, prefer those over burying important URLs only inside the prose body.
71
34
  - Keep provenance concise. Mention Slack origin only when it helps future readers understand why the issue exists.
72
- - Treat team, status, labels, estimate, cycle, and project as structured properties, not prose-only body content, when the MCP tool exposes them and the values are actually known.
35
+ - Treat team, status, labels, estimate, cycle, and project as structured properties, not prose-only body content, when those fields are available and the values are actually known.
73
36
  - Prefer partial updates over full rewrites.
74
37
  - Label assumptions clearly when the thread leaves important details uncertain.
@@ -66,6 +66,4 @@ Use these patterns to shape concrete Linear requests.
66
66
 
67
67
  ## 11. When a user asks to set channel defaults for a Linear-heavy Slack thread
68
68
 
69
- - Use `jr-rpc config set linear.team <team name or key>` when the user explicitly asks to store a team default and the channel consistently routes new work to the same team.
70
- - Use `jr-rpc config set linear.project <project name>` when the user explicitly asks to store a project default and the channel mostly tracks one project.
71
69
  - Treat both defaults as optional. Explicit user input wins whenever a request names a different team or project.
@@ -65,6 +65,20 @@ Good body:
65
65
  >
66
66
  > Action taken on behalf of Carol.
67
67
 
68
+ ## Distinct reporter/requester
69
+
70
+ Good body:
71
+
72
+ > The reviewer bot resolved its own warning even though the underlying issue still appeared valid.
73
+ >
74
+ > Reported by Bojan Oro.
75
+ >
76
+ > - Original warning still applied after the thread was resolved
77
+ > - The related PR remained blocked
78
+ > - The bot should not resolve review threads without confirming the condition cleared
79
+ >
80
+ > Action taken on behalf of David Cramer.
81
+
68
82
  ## Anti-patterns
69
83
 
70
84
  - Adding "Expected behavior" or "Desired outcome" when the thread didn't state one
@@ -72,3 +86,4 @@ Good body:
72
86
  - Restating the title as the first sentence of the body
73
87
  - Including fix suggestions when the thread only describes the problem
74
88
  - Dumping a list of URLs without inline context
89
+ - Conflating the reporter with the action requester when they differ
@@ -4,8 +4,6 @@ Use this reference when Linear MCP work fails or the request is ambiguous.
4
4
 
5
5
  | Symptom | Likely cause | Response |
6
6
  | --------------------------------------------------------- | ------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- |
7
- | No Linear tools are available after loading the skill | The skill was not loaded or the provider tools were not activated for the turn | Load the skill first and use the returned `available_tools`; use `searchTools` only if you need to rediscover them later in the turn. |
8
- | Linear asks for authorization | The user has not connected Linear MCP access yet | Let the MCP OAuth flow pause and resume automatically; do not ask the user to paste credentials manually. |
9
7
  | Authorization completes but the write still fails | The connected Linear account lacks access to the target team, project, or issue | Retry only after confirming the target is visible to the user; otherwise explain the concrete access blocker. |
10
8
  | Creating a new issue is blocked | No team was resolved for the issue | Ask for the team only when it is not already clear from the thread, project context, or existing issue references. |
11
9
  | Search returns too many matches | The request lacks a specific issue key, team, project, or title phrase | Narrow the search with the most specific identifier present in the thread, then ask one concise follow-up only if ambiguity remains. |