@sentry/junior-linear 0.123.0 → 0.124.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sentry/junior-linear",
-  "version": "0.123.0",
+  "version": "0.124.1",
   "private": false,
   "publishConfig": {
     "access": "public"
@@ -23,7 +23,7 @@
   ],
   "dependencies": {
     "zod": "^4.4.3",
-    "@sentry/junior-plugin-api": "0.123.0"
+    "@sentry/junior-plugin-api": "0.124.1"
   },
   "devDependencies": {
     "@types/node": "^25.9.1",

package/skills/linear/SKILL.md

@@ -45,7 +45,8 @@ Classify the work as `bug`, `feature`, or `task`. Shape the title and body per [
 - Prefer flat bullet lists over headed sections for simple issues.
 - Generalize session framing — strip channel references, slash commands, Slack thread IDs, user @mentions, and transcript fragments; replace with the underlying engineering problem.
 - Compress source material. Research notes, hypotheses, or transcripts become a short summary + scoped bullets — never paste raw investigation into the body.
-- Do not add desired outcome, expected behavior, or acceptance criteria unless the thread explicitly requests them.
+- Do not add desired outcome, expected behavior, acceptance criteria, fixes, implementation steps, approaches, or options unless the user explicitly asks to preserve a specific proposal.
+- Never infer a solution from research. If a user-provided proposal must be preserved, attribute it as a proposal and keep it separate from verified diagnosis.
 - 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 actor's real name. The action actor is the current `<actor>` or the person who explicitly asked you to create/update the issue, not necessarily the original reporter.
 
 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 actor, keep them separate with durable body text such as `Reported by Alice.` — do not reference Slack channels, threads, or conversation internals. 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.
@@ -62,6 +63,7 @@ Attribute the reporter by name when clear from the thread (e.g. "Raised by Alice
 - Delegated-action footer is the last line when applicable, using the action actor's real name, not the reporter's name unless they are the same person.
 - No session framing remains (channel refs, slash commands, @mentions, Slack thread IDs).
 - Body structure matches complexity — no empty sections, no restated title, no raw research dump.
+- No invented or unattributed solution, implementation step, approach, or option appears in the title or body.
 
 If any gate fails, revise and re-check before calling the Linear create/update tool.
 
@@ -81,4 +83,5 @@ If any gate fails, revise and re-check before calling the Linear create/update t
 - Reuse or update an existing Linear issue when it is clearly the same work instead of creating a duplicate.
 - Label uncertain details as assumptions in the Linear content when the thread leaves them unresolved.
 - Prefer concise, durable ticket text over verbatim Slack quotes or long transcript dumps.
+- Keep ticket handoffs diagnosis-first. Root-cause evidence can establish what is wrong; it does not justify inventing what should be built or changed.
 - Do not invent team-specific workflow names, labels, or estimate values without first confirming they exist.

package/skills/linear/references/common-use-cases.md

@@ -13,7 +13,7 @@ Use these patterns to shape concrete Linear requests.
 ## 2. Create a follow-up task from a debugging thread
 
 - Convert the thread into a scoped task when the work is cleanup, hardening, docs, or instrumentation rather than a production bug.
-- Keep the body focused on scope and concrete next step. Include desired outcome only if stated in the thread.
+- Keep the body focused on evidence, background, and scope. Do not generate a next step or desired outcome.
 - Set project, cycle, or assignee only when the destination is already clear from the thread.
 
 ## 3. Search for an existing issue before opening a new one
@@ -43,7 +43,7 @@ Use these patterns to shape concrete Linear requests.
 ## 7. Tighten an existing issue description
 
 - Fetch the current issue before editing.
-- Preserve existing accepted context, then add missing impact, reproduction, or expected outcome details from the thread.
+- Preserve existing accepted context, then add missing impact or reproduction details from the thread. Preserve a stated expected outcome only when the user explicitly asks for it.
 - Avoid overwriting structured content unless the user explicitly asks for a rewrite.
 
 ## 8. Create a ticket with Slack provenance but not Slack noise

package/skills/linear/references/issue-examples.md

@@ -48,7 +48,7 @@ Good body:
 
 Bad title: "Clean up some auth code"
 
-## Feature — with options
+## Feature — gap and impact
 
 Good title: "Support hot-reload for worker config"
 
@@ -56,10 +56,7 @@ Good body:
 
 > Workers read config at startup. Changes require a full restart, adding 2-3 minutes to incident mitigation.
 >
-> Options:
->
-> - File watch + hot reload — simple, no atomicity guarantee
-> - Config service with polling — consistent, adds a dependency
+> During incidents, each config change adds 2-3 minutes of mitigation delay and requires an operator to coordinate the restart.
 >
 > Requested by the platform team after repeated incident delays.
 >
@@ -75,7 +72,7 @@ Good body:
 >
 > - Original warning still applied after the thread was resolved
 > - The related PR remained blocked
-> - The bot should not resolve review threads without confirming the condition cleared
+> - No evidence in the thread showed that the underlying condition had cleared
 >
 > Action taken on behalf of David Cramer.
 
@@ -84,6 +81,7 @@ Good body:
 - Adding "Expected behavior" or "Desired outcome" when the thread didn't state one
 - Using headed sections (## Summary, ## Impact, ## Root Cause) for a 3-line issue
 - Restating the title as the first sentence of the body
-- Including fix suggestions when the thread only describes the problem
+- Inventing fixes, implementation steps, approaches, or options, even when diagnosis is strong
+- Mixing user-provided proposals into verified diagnosis without attribution
 - Dumping a list of URLs without inline context
 - Conflating the reporter with the action actor when they differ