メニュー
Reference for using linear-cli (aliased as `linear`) to manage Linear.app issues, projects, cycles, and sprints from the terminal. Use when the user mentions Linear tickets, issues, project management, or sprint planning.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | linear-cli |
| description | Reference for using linear-cli (aliased as `linear`) to manage Linear.app issues, projects, cycles, and sprints from the terminal. Use when the user mentions Linear tickets, issues, project management, or sprint planning. |
linear)linear-cli is authenticated via OAuth 2.0. Verify with linear doctor.
linear i list --mine # My issues
linear i list -t TEAM --mine # Scoped to team
linear i list --since 7d --group-by state # Grouped
linear i list --label bug --count-only # Count
linear i get TEAM-123 # Details
linear i get TEAM-123 --comments # With comments
linear i get TEAM-1 TEAM-2 TEAM-3 # Batch
linear i create "Title" -t TEAM -p 1 # Create (1=urgent,2=high,3=med,4=low)
linear i create "Title" -t TEAM -d - # Pipe description from stdin
linear i create "Title" -t TEAM --parent PARENT-ID # Nest under parent/epic
linear i update TEAM-123 -s "In Progress" # Status
linear i update TEAM-123 -l bug -l urgent # Labels
linear i update TEAM-123 --due tomorrow # Due date
linear i update TEAM-123 -e 3 # Estimate
linear i start TEAM-123 --checkout # Start + git branch
linear i stop TEAM-123 # Back to backlog
linear i close TEAM-123 # Done
linear i assign TEAM-123 "Name" # Assign
linear i move TEAM-123 "Project" # Move to project
linear i transfer TEAM-123 TEAM # Transfer team
linear i comment TEAM-123 -b "text" # Comment
linear i archive TEAM-123 # Archive
linear i open TEAM-123 # Open in browser
linear i link TEAM-123 # Print URL
Load voice before writing non-trivial ticket descriptions; it is the gate for specifics, named actors, and no slop. Unless trivial (typo, formatting), cover:
Pipe long bodies via stdin (-d -) to avoid shell-quoting pain. For parents/epics, search via linear i search "<keywords>" --output json --compact --fields id,identifier,title then pass --parent <ID> at create.
linear rel list TEAM-123 # List relationships
linear rel add TEAM-1 -r blocks TEAM-2 # TEAM-1 blocks TEAM-2
linear rel add TEAM-1 -r blocked-by TEAM-2 # TEAM-1 blocked by TEAM-2
linear rel add TEAM-1 -r related TEAM-2 # Link as related
linear rel add TEAM-1 -r duplicate TEAM-2 # Mark as duplicate
linear rel remove TEAM-1 TEAM-2 # Remove link
linear rel parent TEAM-2 TEAM-1 # Set parent
linear rel unparent TEAM-2 # Remove parent
Relation types: blocks, blocked-by, related, duplicate.
linear st list -t TEAM # Workflow states
linear st get "In Progress" -t TEAM # State details
Use st list to discover valid names for i update -s.
linear b update-state -s Done TEAM-1 TEAM-2 # Bulk status
linear b assign --user me TEAM-1 TEAM-2 # Bulk assign
linear b label --add bug TEAM-1 TEAM-2 # Bulk label
linear b unassign TEAM-1 TEAM-2 # Bulk unassign
linear p list # Projects
linear p get "Name" # Details
linear p create "Name" -t TEAM # Create
linear t list # Teams
linear t get TEAM_KEY # Team details
linear t members TEAM_KEY # Members
linear c list -t TEAM # Cycles
linear c current -t TEAM # Current cycle
linear sp status -t TEAM # Sprint status
linear sp progress -t TEAM # Progress bar
linear sp burndown -t TEAM # Burndown chart
linear sp velocity -t TEAM # Velocity
linear g checkout TEAM-123 # Checkout/create branch
linear g branch TEAM-123 # Print branch name
linear g create TEAM-123 # Create branch (no checkout)
linear g pr TEAM-123 # GitHub PR
linear g pr TEAM-123 --draft # Draft PR
Detects current issue from git branch. Designed for AI agents.
linear context # Issue from branch
linear ctx --output json # JSON for parsing
Parses: fac-123-fix-bug, feature/FAC-456-new-feature.
linear history issue TEAM-123 # Activity log
linear hist issue TEAM-123 --limit 50 # More entries
linear triage list # Unassigned issues
linear tr claim TEAM-123 # Claim + backlog
linear tr snooze TEAM-123 --duration 1w # Snooze 1 week
Linear tickets often have Slack threads attached (in comments or description URLs).
If the slack-cli skill is available, use it to fetch thread context for richer understanding of an issue or feature goal:
# 1. Pull ticket details / comments for Slack URLs
linear i get TEAM-123 --comments
# 2. Extract channel ID + thread timestamp from the Slack URL
# e.g. https://workspace.slack.com/archives/C0123456789/p1234567890123456
# → channel=C0123456789, thread_ts=1234567890.123456
# 3. Fetch the thread via slack-cli
slack ch history C0123456789 --oldest 1234567890.123456 --count 50
Tickets often link artifacts holding the real failure state or design intent. Pull them when fetching the ticket, not later:
daily-cli-bug-report)Default is pull, not skip. A bug ticket without its bug report is empty; root-cause analysis runs on guesswork. Treat ticket + artifact as one comprehension step.
Read-only fetches are not spec-mode violations, even when they cache to disk. Spec mode restricts repo/workspace mutations -- not network reads or cache writes. The "spec mode means no downloads" reading produces symptom-anchored specs.
Use these flags when consuming output programmatically:
| Flag | Purpose |
|---|---|
--output json | JSON (also ndjson) |
--compact | No pretty-print |
--fields a,b,c | Limit fields (dot paths) |
--id-only | Only resource ID |
--quiet | Suppress decoration |
--format "{{identifier}} {{title}}" | Template |
--filter "state.name=In Progress" | Client-side filter |
--fail-on-empty | Non-zero exit on empty |
--dry-run | Preview |
ID=$(linear i create "Title" -t TEAM --id-only --quiet)
linear i update "$ID" -s "In Progress"
| Code | Meaning |
|---|---|
| 0 | Success |
| 1 | General error |
| 2 | Not found |
| 3 | Auth error |
| 4 | Rate limited |
linear d list # Documents
linear d create "Name" -c "Content" # Create doc
linear l list # Labels
linear l create "name" -c "#FF0000" # Create label
linear templates list # Templates
linear views list # Custom views
linear search "query" # Search issues
linear search "query" --output json --compact # JSON output
linear api query '{ viewer { id name } }' # Query
echo '{"query":"..."}' | linear api query - # Pipe
linear api mutate '<mutation>' # Mutate
linear watch TEAM-123 # Watch issue changes
linear watch -t TEAM # Watch team activity
linear export -t TEAM --format csv # Export CSV
linear export -t TEAM --format json # Export JSON
linear import --file data.csv -t TEAM # Import CSV
Full PR review workflows -- first-pass, deeper (overcoverage), follow-up (re-review). Load when the user invokes /review-pr or explicitly asks for a PR review, deeper wave, or re-review; never ambiently.
Shared atom for analyzing a diff and writing a structured PR description. Background knowledge for workflow commands -- not invoked directly.
Author a publication-grade single-file HTML design doc (RFCs, architecture proposals, sync prep). Editorial typography, decision cards, fact-checked code references, Playwright-verified layout, secret-gist publishing. Use when an engineer asks for a design doc, RFC, monograph, sync-prep brief, or "make this look like a real spec."
Shared atom for running quality checks, committing, and pushing. Background knowledge for workflow commands -- not invoked directly.
Self-review your aggregate diff before shipping to catch dead weight, junk code, perf misses, pattern drift, AI slop, and scope creep. Use when the user asks to scrub, stranger-review, or clean up changes prior to opening a PR.
Shared atom for structural maintainability judgment on a diff -- hunt code-judo simplifications, spaghetti-condition growth, file-size explosions, and orchestration smells. Background knowledge for review and self-review flows -- not invoked directly.