update-linear-issue
Use this skill only when the user explicitly invokes /update-linear-issue to change fields on an existing Linear issue (title, description, state, assignee, priority). This is a write skill with irreversible side effects — it must never be auto-invoked from conversational context. It shows a payload preview, requires explicit confirmation, then applies the update.
- License 许可
- MIT
- 最近更新
- 2026-11-10
- Stars
- ★ 34
- Forks
- 2
01 前言 Front Matter
- name
- update-linear-issue
- description
- Use this skill only when the user explicitly invokes /update-linear-issue to change fields on an existing Linear issue (title, description, state, assignee, priority). This is a write skill with irreversible side effects — it must never be auto-invoked from conversational context. It shows a payload preview, requires explicit confirmation, then applies the update.
- allowed-tools
- [ "Bash", "Read", "Write" ]
- argument-hint
- <IDENTIFIER> [--title TEXT] [--description TEXT] [--state NAME] [--assignee-id ID] [--priority N] [--quiet]
- disable-model-invocation
- true
03 SKILL.md 正文
Update Linear Issue
!accelerator config context --skill update-linear-issue --fail-safe
Configuration: Set
work.integration: linearin.accelerator/config.md.
Update an existing Linear issue via issueUpdate. Work through the steps in
order. This skill never auto-invokes — it only runs when the user explicitly
types /update-linear-issue. Body/description content comes only from the
user's current turn, never synthesised from prior context.
Step 1: Parse arguments
Read the issue identifier (positional) and the mutating flags: --title,
--description, --state (a WorkflowState name resolved to its UUID via the
catalogue), --assignee-id, --priority. At least one is required.
Step 2: Render the preview
Show the resolved intent — the operation (issueUpdate), the target issue, and
the fields being set (--title/--description/--state/--assignee-id/
--priority) — under:
Proposed Linear write — review before sending
At least one mutating flag is required; with none the subcommand refuses before
any write (E_UPDATE_NO_OPS). A --state change resolves through
the catalogue and is refused before any write if the name is unknown or
ambiguous.
Step 3: Confirm before writing
Ask:
Apply this update to Linear? Reply y to confirm, n to revise, anything else to abort.
On a clear yes, proceed. On no/revise, rebuild the preview. On anything ambiguous, abort with "Aborted — no Linear write was made."
Step 4: Send and render
accelerator linear update <IDENTIFIER> [flags]
The subcommand reports the updated keyword on success (the trailing
updated\t<identifier> line, or the outcome field when a --state change
renders JSON). Confirm the updated fields and suggest /show-linear-issue <IDENTIFIER> to verify. On any non-zero exit, report the error — no write was
made.
!accelerator config instructions update-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.