comment-linear-issue
Use this skill only when the user explicitly invokes /comment-linear-issue to add a Markdown comment to an existing Linear issue. This is a write skill with irreversible side effects — it must never be auto-invoked from conversational context. It shows the comment preview, requires explicit confirmation, then posts the comment.
- License 许可
- MIT
- 最近更新
- 2026-11-13
- Stars
- ★ 34
- Forks
- 2
01 前言 Front Matter
- name
- comment-linear-issue
- description
- Use this skill only when the user explicitly invokes /comment-linear-issue to add a Markdown comment to an existing Linear issue. This is a write skill with irreversible side effects — it must never be auto-invoked from conversational context. It shows the comment preview, requires explicit confirmation, then posts the comment.
- allowed-tools
- [ "Bash", "Read", "Write" ]
- argument-hint
- <IDENTIFIER> --body TEXT | --body-file PATH [--quiet]
- disable-model-invocation
- true
03 SKILL.md 正文
Comment on a Linear Issue
!accelerator config context --skill comment-linear-issue --fail-safe
Configuration: Set
work.integration: linearin.accelerator/config.md.
Add a Markdown comment to a Linear issue via commentCreate. Work through the
steps in order. This skill never auto-invokes — it only runs when the user
explicitly types /comment-linear-issue.
The comment body comes ONLY from text the user typed this turn or a file path the user named this turn — never synthesised from prior context.
Step 1: Parse arguments
Read the issue identifier (positional) and the body source (--body TEXT or
--body-file PATH).
Step 2: Render the preview
Resolve the body: if --body-file PATH was given, read the file; otherwise take
--body TEXT verbatim. If neither is present, STOP with E_COMMENT_NO_BODY.
Show the resolved intent — the operation (commentCreate), the target issue,
and the Markdown body — under:
Proposed Linear write — review before sending
Step 3: Confirm before writing
Ask:
Post this comment 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 comment add <IDENTIFIER> --body "..."
The subcommand emits a JSON envelope with a top-level outcome keyword. On
added, confirm the comment was posted. On any non-zero exit, report the error
and stop.
!accelerator config instructions comment-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.