Use this skill only when the user explicitly invokes /transition-linear-issue to move an existing Linear issue to a different workflow state. This is a write skill with irreversible side effects — it must never be auto-invoked from conversational context. The target state name is resolved to its UUID from the cached catalogue (no live lookup). Shows a preview, requires explicit confirmation, then applies the transition.
Scanned 9/10/2026
Install to Claude Code
npx -y skills add atomicinnovation/accelerator --skill transition-linear-issue --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Transition Linear Issue?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/atomicinnovation-transition-linear-issue)More formats (shields.io, HTML) on the badges page.
---
name: transition-linear-issue
description: >
Use this skill only when the user explicitly invokes /transition-linear-issue
to move an existing Linear issue to a different workflow state. This is a write
skill with irreversible side effects — it must never be auto-invoked from
conversational context. The target state name is resolved to its UUID from the
cached catalogue (no live lookup). Shows a preview, requires explicit
confirmation, then applies the transition.
argument-hint: "<IDENTIFIER> <STATE-NAME> [--quiet]"
disable-model-invocation: true
allowed-tools:
- Bash
- Read
- Write
---
# Transition a Linear Issue
!`accelerator config context --skill transition-linear-issue --fail-safe`
> **Configuration**: Set `work.integration: linear` in `.accelerator/config.md`.
Move a Linear issue to a target WorkflowState via `issueUpdate`, resolving the
state name to its team-scoped UUID **from the cached catalogue** — there is no
live lookup. Work through the steps in order. This skill never auto-invokes.
## Step 1: Parse arguments
Read the issue identifier and the target state name (both positional, e.g.
`/transition-linear-issue BLA-123 "In Progress"`).
## Step 2: Render the preview
Show the resolved intent — the operation (`issueUpdate` state change), the target
issue, and the target state name — under:
> **Proposed Linear write — review before sending**
State matching is case-insensitive and trimmed. Resolution happens inside the
subcommand from the cached catalogue; a name that is not in the catalogue or is
shared by two states is refused at send time **before any write**
(`E_TRANSITION_STATE_NOT_IN_CATALOGUE`, `E_TRANSITION_STATE_AMBIGUOUS`).
## Step 3: Confirm before writing
Ask:
> Transition this issue? Reply **y** to confirm, **n** to revise, anything else
> to abort.
On a clear yes, proceed. On anything ambiguous, abort with "Aborted — no Linear
write was made."
## Step 4: Send and render
```
accelerator linear transition <IDENTIFIER> "<STATE-NAME>"
```
The subcommand emits a JSON envelope with a top-level `outcome` keyword. On
`transitioned`, confirm the new state and suggest `/show-linear-issue
<IDENTIFIER>` to verify. On a non-zero exit naming
`E_TRANSITION_STATE_NOT_IN_CATALOGUE` or `E_TRANSITION_STATE_AMBIGUOUS`, the
state could not be resolved and no write was made — suggest `/init-linear` to
refresh, or ask the user to pick an unambiguous state.
!`accelerator config instructions transition-linear-issue --fail-safe`
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!