show-linear-issue
Use this skill when the user asks about a specific Linear issue by identifier (e.g. BLA-123, ENG-456) — for viewing the description, state, assignee, or comments. Trigger when the user says 'look up', 'check on', 'tell me about', 'what's on', or 'what is the status of' an identifier, or asks any direct question about an issue they reference. Do NOT trigger when an identifier appears incidentally inside other prose (commit messages, code review comments, release notes), where the user is talking about the issue rather than asking to fetch it.
- License 许可
- MIT
- 最近更新
- 2026-11-12
- Stars
- ★ 34
- Forks
- 2
01 前言 Front Matter
- name
- show-linear-issue
- description
- Use this skill when the user asks about a specific Linear issue by identifier (e.g. BLA-123, ENG-456) — for viewing the description, state, assignee, or comments. Trigger when the user says 'look up', 'check on', 'tell me about', 'what's on', or 'what is the status of' an identifier, or asks any direct question about an issue they reference. Do NOT trigger when an identifier appears incidentally inside other prose (commit messages, code review comments, release notes), where the user is talking about the issue rather than asking to fetch it.
- allowed-tools
- [ "Bash(accelerator config *)", "Bash(accelerator linear *)" ]
- argument-hint
- <IDENTIFIER> [--comments N]
- disable-model-invocation
- false
03 SKILL.md 正文
Show Linear Issue
!accelerator config context --skill show-linear-issue --fail-safe
Configuration: Set
work.integration: linearin.accelerator/config.md. See the### worksection ofconfigure/SKILL.mdfor the full reference.
Fetch and render a single Linear issue by identifier.
Step 1: Resolve the identifier
Read the issue identifier from the argument string (e.g. BLA-123). If none was
supplied, ask the user which issue to show.
Step 2: Fetch the issue
Run:
accelerator linear show <IDENTIFIER> [--comments N]
Run the bare launcher directly as an executable; never prefix it with
bash/sh/env (a wrapper prefix escapes the skill's allowed-tools
permission and forces an unnecessary prompt).
The subcommand emits a JSON document with a top-level outcome keyword —
found or not-found. When outcome is not-found, tell the user the issue
was not found.
Step 3: Render the issue
Render the issue's fields under .data.issue:
- Identifier:
.identifier - Title:
.title - State:
.state.name - Assignee:
.assignee.name(orunassigned) - Description:
.description— already native Markdown, render it directly (no ADF conversion). - Comments: each
.comments.nodes[].body(Markdown), if any.
!accelerator config instructions show-linear-issue --fail-safe
04 同仓库更多 Skills
explore-pr
Build an interactive, design-first and picture-first exploration page for a pull request — its architecture, abstractions and design decisions drawn as diagrams, a guided tour in reading order with code as the evidence, an attention map of where the risk sits, a ledger of its riskiest operations, prior review findings re-checked against the code, and simulations specific to the PR — with the reviewer's verdicts and notes saved. Use when the user wants to explore, understand or review a large pull request or its design, asks for a review page, walkthrough or visual explanation of a PR, or is struggling to review a big change.
update-work-item
Update fields (status, priority, tags, parent, etc.) of an existing work item. Use to transition status, change priority, manage tags, or edit any frontmatter field. No transition enforcement — arbitrary changes are allowed.
sync-work-items
Reconcile local work items in meta/work/ with the active remote tracker named by work.integration. Use when the user wants to sync, push, or pull work items to or from Jira or Linear, preview what a sync would change, or reconcile divergent local and remote state.
sync-work-items-recovery
Recovery procedures for work sync failures that need a person — terminal rows, refused pending pushes and refused orders. Read by sync-work-items — not invoked directly.
stress-test-work-item
Interactively stress-test a work item by grilling the user on scope, assumptions, acceptance criteria, edge cases, and dependencies to surface issues, gaps, and flawed assumptions before implementation is planned.
review-work-item
Review a work item through multiple quality lenses and collaboratively iterate based on findings. Use when the user wants to evaluate a work item before implementation or escalation.