@sentry/junior-github 0.123.0 → 0.124.1

package/dist/index.js

@@ -119,18 +119,18 @@ function sentryConversationUrl(conversationId) {
 function githubConversationFooter(conversationId, dashboardUrl) {
   const id = nonEmptyString(conversationId, "conversationId");
   const normalizedDashboardUrl = dashboardUrl?.trim();
-  const sessionUrl = normalizedDashboardUrl || sentryConversationUrl(id);
-  if (!sessionUrl) {
+  const sentryUrl = sentryConversationUrl(id);
+  const sessionLinks = normalizedDashboardUrl ? `[View Junior Session](${normalizedDashboardUrl})${sentryUrl ? ` [Sentry](${sentryUrl})` : ""}` : sentryUrl ? `[View Junior Session in Sentry](${sentryUrl})` : void 0;
+  if (!sessionLinks) {
     return void 0;
   }
-  const label = normalizedDashboardUrl ? "View Junior Session" : "View Junior Session in Sentry";
   const conversationMarker = `<!-- ${GITHUB_CONVERSATION_ID_MARKER}${encodeURIComponent(id)} -->`;
   return `${GITHUB_SESSION_FOOTER_START}
 ${conversationMarker}
 
 --
 
-[${label}](${sessionUrl})
+${sessionLinks}
 
 ${GITHUB_SESSION_FOOTER_END}`;
 }
@@ -382,7 +382,7 @@ function isDefinitiveGitHubIssueCreateRejection(error) {
   }
   return [400, 401, 404, 410, 422].includes(error.status);
 }
-function createGitHubIssueRequest(conversationId, input, actor) {
+function createGitHubIssueRequest(conversationId, input, actor, dashboardUrl) {
   const repo = parseRepo(input.repo);
   const labels = input.labels?.map(
     (label) => nonEmptyString2(label, "labels entry")
@@ -391,7 +391,8 @@ function createGitHubIssueRequest(conversationId, input, actor) {
     title: nonEmptyString2(input.title, "title"),
     body: appendGitHubFooter(
       appendGitHubRequesterAttribution(input.body ?? "", actor),
-      conversationId
+      conversationId,
+      dashboardUrl
     ),
     ...labels?.length ? { labels } : {}
   };
@@ -488,7 +489,8 @@ function createGitHubIssueTool(ctx) {
           const request = createGitHubIssueRequest(
             conversationId,
             parsedInput,
-            ctx.actor
+            ctx.actor,
+            ctx.slack?.conversationLink?.url
           );
           const pendingState = {
             status: "pending",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sentry/junior-github",
-  "version": "0.123.0",
+  "version": "0.124.1",
   "private": false,
   "publishConfig": {
     "access": "public"
@@ -31,7 +31,7 @@
     "@sinclair/typebox": "^0.34.49",
     "drizzle-orm": "^0.45.2",
     "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/github-issues/SKILL.md

@@ -57,7 +57,8 @@ Follow [references/research-rules.md](references/research-rules.md) for cross-ty
 - Prefer flat bullet lists over headed sections for simple issues. Remove empty sections.
 - Generalize session framing — strip channel references, slash commands, Slack thread IDs, user @mentions, and transcript fragments; replace with the underlying technical 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.
 - Preserve material source references inline.
 
 **Source attribution:**
@@ -74,6 +75,7 @@ Before running the `gh` create/edit command, check each gate. If any fails, revi
 - Title length ≤ 60 characters.
 - 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.
 
 Run [references/issue-quality-checklist.md](references/issue-quality-checklist.md) for holistic soft-signal review when the draft warrants it.
 
@@ -93,5 +95,5 @@ Run [references/issue-quality-checklist.md](references/issue-quality-checklist.m
 
 - Require explicit confirmation only for close/reopen or destructive broad rewrites.
 - Do not overwrite issue fields unless explicitly requested. Prefer partial updates over full body replacement.
-- For `bug` issues, do not present a fix as definitive unless root-cause evidence is explicit.
+- Keep ticket handoffs diagnosis-first. Root-cause evidence can establish what is wrong; it does not justify inventing what should be built or changed.
 - If repository or installation access is missing, stop and return a concrete remediation message.

package/skills/github-issues/references/issue-bug.md

@@ -30,7 +30,7 @@ Research informs what goes in the issue, not how structured it looks.
 3. Separate verified facts from unknowns — label each explicitly.
 4. Form root-cause hypotheses linked to evidence, with confidence (`high`, `medium`, `low`).
 
-Include fix suggestions only when the thread discusses fixes. Do not present a fix as certain without explicit evidence.
+Do not add fix suggestions. If the user explicitly asks to preserve a specific proposal from the source context, attribute it as proposed and keep it separate from verified facts and root-cause hypotheses.
 
 ## Context generalization
 

package/skills/github-issues/references/issue-examples.md

@@ -35,12 +35,10 @@ Good structure — problem-specific sections:
 > 2. First message acquires the lock
 > 3. Second message sets its dedup key, fails lock acquisition
 >
-> ## Expected behavior
+> ## Unknowns
 >
-> Either:
->
-> - **Option A**: Acquire lock before setting dedup key
-> - **Option B**: Clear dedup key on lock failure
+> - Whether lock contention is the only path that consumes the dedup slot without processing
+> - Whether the behavior reproduces across all message entry points
 >
 > ## Workaround
 >
@@ -71,7 +69,7 @@ Bad framing:
 
 > It would be nice to have better config reloading.
 
-Good framing — current state, gap, options:
+Good framing — current state, gap, and impact:
 
 > ## Current behavior
 >
@@ -81,12 +79,9 @@ Good framing — current state, gap, options:
 >
 > Config changes during incidents require redeploying, adding 2-3 minutes to mitigation.
 >
-> ## Options
+> ## Impact
 >
-> | Approach                    | Tradeoff                           |
-> | --------------------------- | ---------------------------------- |
-> | File watch + hot reload     | Simple, but no atomicity guarantee |
-> | Config service with polling | Consistent, but adds a dependency  |
+> During incidents, each config change adds 2-3 minutes of mitigation delay and requires an operator to coordinate the restart.
 
 ## Principles
 
@@ -94,7 +89,6 @@ Good framing — current state, gap, options:
 - Include code snippets when they clarify the pattern
 - Quantify scope precisely ("8 of 9", not "many")
 - Cross-reference related issues and PRs
-- Show concrete options with tradeoffs, not vague "should be fixed"
 - Use tables for structured comparisons
 
 ## Anti-patterns
@@ -102,7 +96,8 @@ Good framing — current state, gap, options:
 - Over-structured issues: using ## Summary, ## Impact, ## Root Cause headings for a 3-line bug
 - Adding "Expected behavior" or "Desired outcome" when the thread didn't state one
 - Restating the title as the first sentence of the body
-- Confident fix claims without root-cause evidence
+- Invented fixes, implementation steps, approaches, or options, even when the root cause is verified
+- Unattributed proposals mixed into verified diagnosis
 - Speculative detail mixed into verified facts
 - Dumping a list of URLs without inline context
 - Session-specific content (slash commands, channel references, raw transcript framing, or unrelated user chatter)

package/skills/github-issues/references/issue-feature.md

@@ -4,11 +4,11 @@ Load when issue type is `feature`. Cross-type rules (title length, delegated foo
 
 ## Primary goal
 
-Propose an intentional improvement with clear current-state analysis and practical options.
+Describe an intentional improvement through verified current-state analysis, the gap, and its impact without prescribing implementation.
 
 ## Shape
 
-A flat bullet list is fine for simple features. Use headed sections only when tradeoffs need detailed framing.
+A flat bullet list is fine for simple features. Use headed sections only when the current-state evidence and impact need detailed framing.
 
 **Summary** — up to 3 sentences describing the improvement. Short imperative title (e.g. "Support SAML SSO for enterprise orgs").
 
@@ -16,15 +16,14 @@ A flat bullet list is fine for simple features. Use headed sections only when tr
 
 - **Current behavior** — how the system works today
 - **Gap** — why current behavior is insufficient, with concrete impact
-- **Options** — viable approaches with tradeoffs (include only when the thread discusses alternatives)
 
-For simple features, skip sections and use flat bullets describing the gap and desired capability.
+For simple features, skip sections and use flat bullets describing the current behavior, gap, and impact.
 
 ## Research guidance
 
 1. Analyze current behavior and why it's insufficient.
 2. Gather prior art when available — include links and what each proves. If none found, omit rather than stating "none found."
-3. Frame options with tradeoffs when the thread discusses alternatives.
+3. Do not generate approaches or options. Preserve a specific proposal only when the user explicitly asks, attribute it, and keep it separate from the gap analysis.
 
 ## Context generalization
 

package/skills/github-issues/references/issue-quality-checklist.md

@@ -15,7 +15,8 @@ Soft-signal review beyond the hard gates in `SKILL.md` § Verify draft. Use when
 ## Anti-patterns to avoid
 
 - Overlong, sprawling bodies with no clear sections.
-- Confident solution claims that are weakly evidenced.
+- Invented fixes, implementation steps, approaches, or options, regardless of diagnostic confidence.
+- User-provided proposals presented without attribution or mixed into verified diagnosis.
 - Speculative detail mixed into verified sections.
 
 ## External guidance

package/skills/github-issues/references/issue-task.md

@@ -17,12 +17,12 @@ A task can be just a title + 2-3 bullets. Use headed sections only when scope is
 - **Background** — why this task exists, with code snippets if relevant
 - **Scope** — what's included and excluded, quantify when possible
 
-For simple tasks, skip sections and use flat bullets for scope and next step.
+For simple tasks, skip sections and use flat bullets for background and scope.
 
 ## Research guidance
 
 - Minimal research by default. Prefer first-party repository context when available.
-- Include implementation steps only when the thread discusses approach. Otherwise, state the goal and scope.
+- Do not generate implementation steps or approaches. Preserve a specific user-provided plan only when explicitly requested, attribute it, and keep it separate from verified scope.
 - Include dependencies or risks only when material.
 
 ## Context generalization