Summary
Add support for listing ProjectLabels alongside existing IssueLabels by introducing a --type issue|project flag to labels list.
Part of #9
Background
Linear has two separate label systems:
|
IssueLabel |
ProjectLabel |
Has team field |
✅ team?: Maybe<Team> |
❌ No team field |
| Scope |
Workspace (team=null) OR team-scoped |
Workspace only |
Filter has team |
✅ IssueLabelFilter.team |
❌ Not available |
| Hierarchy |
✅ parent, children, isGroup |
✅ parent, children, isGroup |
Currently only IssueLabels are supported. ProjectLabels (used for categorizing projects) are not accessible.
Design Decisions
--type accepts issue (default) or project — no all option to avoid merged-pagination complexity. Agents can make two calls.
--type project combined with --team produces a validation error (project labels have no team concept).
- Output adds a
type field to all label results. This is a breaking change to the output shape.
Changes
GraphQL layer (graphql/queries/labels.graphql)
- Add
ProjectLabelFields fragment on ProjectLabel (id, name, color, description)
- Add
GetProjectLabels query on projectLabels root field with $first, $after, $filter variables
- Run
npm run generate
Service layer (src/services/label-service.ts)
- Add
type: "issue" | "project" to the Label interface
- Add
listProjectLabels(client, options) — same pattern as listLabels but without teamId parameter, queries GetProjectLabelsDocument
- Update
listLabels() to include type: "issue" in mapped output
Command layer (src/commands/labels.ts)
- Add
--type <type> option with choices issue (default), project
- Route to
listLabels() or listProjectLabels() based on --type
- Validate: error if
--type project combined with --team
Resolver layer
No changes needed for this ticket (read-only).
Tests
label-service.test.ts: happy path for listProjectLabels, update existing test to verify type: "issue" in output
- Validation test:
--type project --team X produces error
Output Change
Before:
{ "id": "abc", "name": "Bug", "color": "#FF0000" }
After:
{ "id": "abc", "name": "Bug", "color": "#FF0000", "type": "issue" }
Summary
Add support for listing ProjectLabels alongside existing IssueLabels by introducing a
--type issue|projectflag tolabels list.Part of #9
Background
Linear has two separate label systems:
IssueLabelProjectLabelteamfieldteam?: Maybe<Team>team=null) OR team-scopedteamIssueLabelFilter.teamparent,children,isGroupparent,children,isGroupCurrently only IssueLabels are supported. ProjectLabels (used for categorizing projects) are not accessible.
Design Decisions
--typeacceptsissue(default) orproject— noalloption to avoid merged-pagination complexity. Agents can make two calls.--type projectcombined with--teamproduces a validation error (project labels have no team concept).typefield to all label results. This is a breaking change to the output shape.Changes
GraphQL layer (
graphql/queries/labels.graphql)ProjectLabelFieldsfragment onProjectLabel(id, name, color, description)GetProjectLabelsquery onprojectLabelsroot field with$first,$after,$filtervariablesnpm run generateService layer (
src/services/label-service.ts)type: "issue" | "project"to theLabelinterfacelistProjectLabels(client, options)— same pattern aslistLabelsbut withoutteamIdparameter, queriesGetProjectLabelsDocumentlistLabels()to includetype: "issue"in mapped outputCommand layer (
src/commands/labels.ts)--type <type>option with choicesissue(default),projectlistLabels()orlistProjectLabels()based on--type--type projectcombined with--teamResolver layer
No changes needed for this ticket (read-only).
Tests
label-service.test.ts: happy path forlistProjectLabels, update existing test to verifytype: "issue"in output--type project --team Xproduces errorOutput Change
Before:
{ "id": "abc", "name": "Bug", "color": "#FF0000" }After:
{ "id": "abc", "name": "Bug", "color": "#FF0000", "type": "issue" }