@sentry/junior-linear 0.20.0 → 0.21.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
package/skills/linear/SKILL.md
CHANGED
|
@@ -12,11 +12,11 @@ Use this skill for Linear issue workflows in the harness.
|
|
|
12
12
|
|
|
13
13
|
Load references conditionally based on the request:
|
|
14
14
|
|
|
15
|
-
| Need | Read
|
|
16
|
-
| ------------------------------------------------ |
|
|
17
|
-
| Any Linear operation | [references/api-surface.md](references/api-surface.md)
|
|
18
|
-
| Create, update, comment, assign, or state change | [references/common-use-cases.md](references/common-use-cases.md), [references/issue-writing.md](references/issue-writing.md) |
|
|
19
|
-
| Auth issues, ambiguity, or tool failures | [references/troubleshooting-workarounds.md](references/troubleshooting-workarounds.md)
|
|
15
|
+
| Need | Read |
|
|
16
|
+
| ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
|
|
17
|
+
| Any Linear operation | [references/api-surface.md](references/api-surface.md) |
|
|
18
|
+
| Create, update, comment, assign, or state change | [references/common-use-cases.md](references/common-use-cases.md), [references/issue-writing.md](references/issue-writing.md), [references/issue-examples.md](references/issue-examples.md) |
|
|
19
|
+
| Auth issues, ambiguity, or tool failures | [references/troubleshooting-workarounds.md](references/troubleshooting-workarounds.md) |
|
|
20
20
|
|
|
21
21
|
## Workflow
|
|
22
22
|
|
|
@@ -38,10 +38,14 @@ Load references conditionally based on the request:
|
|
|
38
38
|
- Prefer a short read/search step before mutating when you need to confirm the existing issue, team, project, or workflow state.
|
|
39
39
|
- For create/update operations, classify the work as a `bug`, `feature`, or `task` and shape the title/body accordingly.
|
|
40
40
|
- For issue creation, ground the ticket in the actual engineering problem:
|
|
41
|
-
-
|
|
42
|
-
-
|
|
41
|
+
- use a short descriptive title for bugs, short imperative title for tasks and features
|
|
42
|
+
- summarize the problem and impact; include expected outcome only when the thread states one
|
|
43
|
+
- mention who raised the issue when clear from the thread
|
|
44
|
+
- attach screenshots from the thread as image links when present
|
|
45
|
+
- preserve relevant URLs inline (Sentry, GitHub, docs, reproduction links) — do not dump a link list
|
|
46
|
+
- prefer flat bullet lists over headed sections for simple issues
|
|
43
47
|
- translate Slack-specific phrasing into product or engineering language
|
|
44
|
-
- remove
|
|
48
|
+
- remove channel names, slash commands, and session chatter unless the user explicitly wants them preserved
|
|
45
49
|
- When setting optional fields, stay literal:
|
|
46
50
|
- use the team's actual workflow states instead of assuming generic names like `Todo` or `In Progress`
|
|
47
51
|
- use only Linear's standard priority levels: `low`, `medium`, `high`, `urgent`
|
|
@@ -4,7 +4,7 @@ Use these patterns to shape concrete Linear requests.
|
|
|
4
4
|
|
|
5
5
|
## 1. Create a bug from a Slack incident thread
|
|
6
6
|
|
|
7
|
-
- Summarize the broken behavior
|
|
7
|
+
- Summarize the broken behavior and impact. Include expected behavior only if stated in the thread.
|
|
8
8
|
- Resolve the right team before creating because Linear issues cannot be created without one.
|
|
9
9
|
- If the thread does not name a destination, use `linear.team` and `linear.project` channel defaults before asking a follow-up.
|
|
10
10
|
- Preserve relevant Sentry, GitHub, replay, trace, or dashboard links from the thread.
|
|
@@ -13,7 +13,7 @@ Use these patterns to shape concrete Linear requests.
|
|
|
13
13
|
## 2. Create a follow-up task from a debugging thread
|
|
14
14
|
|
|
15
15
|
- Convert the thread into a scoped task when the work is cleanup, hardening, docs, or instrumentation rather than a production bug.
|
|
16
|
-
- Keep the body focused on
|
|
16
|
+
- Keep the body focused on scope and concrete next step. Include desired outcome only if stated in the thread.
|
|
17
17
|
- Set project, cycle, or assignee only when the destination is already clear from the thread.
|
|
18
18
|
|
|
19
19
|
## 3. Search for an existing issue before opening a new one
|
|
@@ -49,7 +49,8 @@ Use these patterns to shape concrete Linear requests.
|
|
|
49
49
|
## 8. Create a ticket with Slack provenance but not Slack noise
|
|
50
50
|
|
|
51
51
|
- Mention that the work originated from a Slack discussion only when that context helps future readers.
|
|
52
|
-
-
|
|
52
|
+
- Mention who raised the issue when clear from the thread (e.g. "Reported by Jane from the support team").
|
|
53
|
+
- Strip channel references, slash commands, and conversational filler unless the user explicitly wants them preserved.
|
|
53
54
|
|
|
54
55
|
## 9. Set priority, labels, or estimate from thread context
|
|
55
56
|
|
|
@@ -0,0 +1,74 @@
|
|
|
1
|
+
# Issue Examples
|
|
2
|
+
|
|
3
|
+
Calibrate structure and depth by comparing good and bad patterns.
|
|
4
|
+
|
|
5
|
+
## Bug — simple
|
|
6
|
+
|
|
7
|
+
Good title: "Webhook delivery drops events over 256KB"
|
|
8
|
+
|
|
9
|
+
Good body (flat bullets, no headings):
|
|
10
|
+
|
|
11
|
+
> Events exceeding 256KB are silently dropped by the webhook proxy. The proxy returns 200 but never forwards the payload. Affects ~2% of production events based on recent Sentry data.
|
|
12
|
+
>
|
|
13
|
+
> - Sentry issue: https://sentry.io/issues/12345
|
|
14
|
+
> - Proxy logs show `payload_too_large` but no alert fires
|
|
15
|
+
> - Reported by the oncall engineer during weekend incident
|
|
16
|
+
>
|
|
17
|
+
> Action taken on behalf of Alice.
|
|
18
|
+
|
|
19
|
+
Bad body (over-structured for a simple bug):
|
|
20
|
+
|
|
21
|
+
> ## Summary
|
|
22
|
+
>
|
|
23
|
+
> There is a problem with webhooks.
|
|
24
|
+
>
|
|
25
|
+
> ## Root Cause
|
|
26
|
+
>
|
|
27
|
+
> The payload is too large.
|
|
28
|
+
>
|
|
29
|
+
> ## Expected Behavior
|
|
30
|
+
>
|
|
31
|
+
> Webhooks should work with large payloads.
|
|
32
|
+
>
|
|
33
|
+
> ## Impact
|
|
34
|
+
>
|
|
35
|
+
> Some events are dropped.
|
|
36
|
+
|
|
37
|
+
## Task — simple
|
|
38
|
+
|
|
39
|
+
Good title: "Remove deprecated legacyAuth middleware"
|
|
40
|
+
|
|
41
|
+
Good body:
|
|
42
|
+
|
|
43
|
+
> `legacyAuth` middleware is unused since SDK v2.1 migration. 7 of 8 patches in `process*.ts` exist solely for scheduling compatibility and can be removed.
|
|
44
|
+
>
|
|
45
|
+
> - Flagged by Bob during PR #312 review
|
|
46
|
+
>
|
|
47
|
+
> Action taken on behalf of Bob.
|
|
48
|
+
|
|
49
|
+
Bad title: "Clean up some auth code"
|
|
50
|
+
|
|
51
|
+
## Feature — with options
|
|
52
|
+
|
|
53
|
+
Good title: "Support hot-reload for worker config"
|
|
54
|
+
|
|
55
|
+
Good body:
|
|
56
|
+
|
|
57
|
+
> Workers read config at startup. Changes require a full restart, adding 2-3 minutes to incident mitigation.
|
|
58
|
+
>
|
|
59
|
+
> Options:
|
|
60
|
+
>
|
|
61
|
+
> - File watch + hot reload — simple, no atomicity guarantee
|
|
62
|
+
> - Config service with polling — consistent, adds a dependency
|
|
63
|
+
>
|
|
64
|
+
> Requested by the platform team after repeated incident delays.
|
|
65
|
+
>
|
|
66
|
+
> Action taken on behalf of Carol.
|
|
67
|
+
|
|
68
|
+
## Anti-patterns
|
|
69
|
+
|
|
70
|
+
- Adding "Expected behavior" or "Desired outcome" when the thread didn't state one
|
|
71
|
+
- Using headed sections (## Summary, ## Impact, ## Root Cause) for a 3-line issue
|
|
72
|
+
- Restating the title as the first sentence of the body
|
|
73
|
+
- Including fix suggestions when the thread only describes the problem
|
|
74
|
+
- Dumping a list of URLs without inline context
|
|
@@ -4,24 +4,32 @@ Use this reference when creating a new Linear issue or substantially improving a
|
|
|
4
4
|
|
|
5
5
|
## Classify the work item
|
|
6
6
|
|
|
7
|
-
Infer the issue
|
|
7
|
+
Infer the issue type before drafting:
|
|
8
8
|
|
|
9
|
-
| Type
|
|
10
|
-
|
|
|
11
|
-
| `bug`
|
|
12
|
-
| `feature` | Net-new capability, product expansion, or workflow improvement
|
|
13
|
-
| `task`
|
|
9
|
+
| Type | Use when |
|
|
10
|
+
| --------- | --------------------------------------------------------------------------- |
|
|
11
|
+
| `bug` | Broken behavior, regressions, failures, incidents, or user-visible defects |
|
|
12
|
+
| `feature` | Net-new capability, product expansion, or workflow improvement |
|
|
13
|
+
| `task` | Cleanup, instrumentation, docs, maintenance, follow-up, or operational work |
|
|
14
14
|
|
|
15
|
-
Default to `task` when the request does not clearly describe a defect or a net-new capability.
|
|
15
|
+
Default to `task` when the request does not clearly describe a defect or a net-new capability. Structure should match complexity — simple issues need only a few bullets, complex bugs may warrant headed sections.
|
|
16
|
+
|
|
17
|
+
## Title rules
|
|
18
|
+
|
|
19
|
+
- Bug: short description of the broken behavior (e.g. "Webhook delivery drops events over 256KB")
|
|
20
|
+
- Task: short imperative command (e.g. "Add rate-limit headers to ingest endpoint")
|
|
21
|
+
- Feature: short imperative describing the capability (e.g. "Support SAML SSO for enterprise orgs")
|
|
16
22
|
|
|
17
23
|
## Drafting rules
|
|
18
24
|
|
|
19
|
-
- Use
|
|
20
|
-
-
|
|
21
|
-
-
|
|
22
|
-
-
|
|
23
|
-
-
|
|
24
|
-
-
|
|
25
|
+
- Use terse, specific language. No filler phrases, no restating the title in the body.
|
|
26
|
+
- Specify who raised the issue when clear from the thread (e.g. "Reported by a customer in #support" or "Flagged by the oncall engineer").
|
|
27
|
+
- Attach screenshots from the thread as image links when present.
|
|
28
|
+
- Link relevant domain info (Sentry issues, GitHub PRs, docs pages, dashboards) inline where context helps — do not dump a link list.
|
|
29
|
+
- Use bullet lists for multi-item details. Omit section headings when a flat list is sufficient.
|
|
30
|
+
- Do not add a desired outcome or expected behavior section unless the thread explicitly states one.
|
|
31
|
+
- Generalize Slack context: remove channel names, slash commands, and session chatter unless the user explicitly wants them preserved.
|
|
32
|
+
- Include code snippets, stack traces, or exact commands only when they materially improve understanding.
|
|
25
33
|
|
|
26
34
|
## Linear-specific field guidance
|
|
27
35
|
|
|
@@ -34,6 +42,23 @@ Default to `task` when the request does not clearly describe a defect or a net-n
|
|
|
34
42
|
- Labels may be workspace- or team-scoped. Reuse an existing matching label when possible instead of introducing near-duplicates.
|
|
35
43
|
- If the tool exposes structured link attachments, attach the important URLs there and keep the prose body focused on interpretation rather than raw link dumping.
|
|
36
44
|
|
|
45
|
+
## Delegated action footer
|
|
46
|
+
|
|
47
|
+
When creating a new issue on behalf of a user, append a final line:
|
|
48
|
+
|
|
49
|
+
`Action taken on behalf of <name>.`
|
|
50
|
+
|
|
51
|
+
## Pre-creation checklist
|
|
52
|
+
|
|
53
|
+
Before submitting, verify:
|
|
54
|
+
|
|
55
|
+
- Title is type-appropriate (descriptive for bugs, imperative for tasks/features)
|
|
56
|
+
- Body uses flat bullets where headings aren't needed
|
|
57
|
+
- No desired outcome section unless the thread stated one
|
|
58
|
+
- Reporter is mentioned when known
|
|
59
|
+
- Screenshots and domain links are attached when present in thread
|
|
60
|
+
- No session-specific noise (channel names, slash commands, conversational filler)
|
|
61
|
+
|
|
37
62
|
## Duplicate handling
|
|
38
63
|
|
|
39
64
|
- Search silently before creating a new issue when the request appears related to existing work.
|