fix(skills): make --label and --assignee actually work in Linear skill - #27213
Closed
flamiinngo wants to merge 3 commits into
Closed
fix(skills): make --label and --assignee actually work in Linear skill#27213flamiinngo wants to merge 3 commits into
flamiinngo wants to merge 3 commits into
Conversation
The check-windows-footguns.py script outputs a checkmark (U+2713) and cross (U+2717) to report results. Windows terminals default to cp1252, which cannot encode these characters, so running the script on Windows threw a UnicodeEncodeError before any results were printed. This made the tool completely unusable on the exact platform it exists to help -- a developer on Windows trying to check their code for Windows-safety issues would just get a crash instead. Fix: reconfigure stdout and stderr to UTF-8 at the start of main(), before any output is produced. Verified on Windows 11 Home with Python 3.13 (terminal defaulting to cp1252).
When creating or updating a Linear issue, the --label and --assignee flags were listed in the help text but never wired up. You could pass them and the command would succeed, but the issue would be created without either. No error, no warning -- they were just silently dropped. This adds the missing name-to-ID lookups so the flags work as advertised. If a label or assignee name does not exist in the team, you now get a clear error message instead of a quiet no-op. Tested against a live Linear workspace on Windows 11.
Collaborator
…solvers
Three crash bugs found in code review:
1. _resolve_member_id crashed with AttributeError when the GraphQL API
returned null for a member displayName field. Fixed by using
(member.get('displayName') or '').lower() instead of direct access.
2. cmd_update_issue crashed with TypeError when issue['team'] was null.
Fixed by using (issue.get('team') or {}).get('id') with an explicit
error message if the team id cannot be determined.
3. Both _resolve_label_id and _resolve_member_id fetched only the first
100 results with no pagination. Teams with more than 100 labels or
members would silently return None, causing unnecessary failures.
Fixed by paginating with hasNextPage/endCursor until all results
are checked.
Contributor
Author
|
Closing as duplicate of #21143. One note for that PR: the global _resolve_assignee_id may assign to users outside |
This was referenced May 19, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What was broken
The Linear skill's create-issue and update-issue commands listed --label
and --assignee in the help text, but passing them did nothing. The issue
would be created successfully with neither the label nor assignee applied
no error, no warning, just silently dropped.
Fix
Added two lookup helpers that search the team's labels and members by
name and return their IDs. Both create-issue and update-issue now use
these to resolve names before sending the API request.
If a label or assignee name doesn't exist in the team, the command exits
with a clear error message instead of pretending it worked.
Verified on