attach-jira-issue
Use this skill only when the user explicitly invokes /attach-jira-issue to upload one or more local files as attachments to a Jira issue. This is a write skill with irreversible side effects — it must never be auto-invoked from conversational context. Previews what will be uploaded and requires explicit confirmation before POSTing.
- License 许可
- MIT
- 最近更新
- 2026-11-10
- Stars
- ★ 34
- Forks
- 2
01 前言 Front Matter
- name
- attach-jira-issue
- description
- Use this skill only when the user explicitly invokes /attach-jira-issue to upload one or more local files as attachments to a Jira issue. This is a write skill with irreversible side effects — it must never be auto-invoked from conversational context. Previews what will be uploaded and requires explicit confirmation before POSTing.
- allowed-tools
- [ "Bash", "Read", "Write" ]
- argument-hint
- ISSUE-KEY FILE [FILE...]
- disable-model-invocation
- true
03 SKILL.md 正文
Attach files to a Jira Issue
!accelerator config context --skill attach-jira-issue --fail-safe
Upload one or more local files as attachments to a Jira issue. Work through
the steps below in order. This skill never auto-invokes — it only runs when
the user explicitly types /attach-jira-issue.
Step 1: Parse flags
Required:
KEY— issue key (first positional), e.g.ENG-42FILE [FILE...]— one or more local file paths to upload
Step 2: Preview the resolved intent
Show, under Proposed Jira write — review before sending:
POSTattachments to<KEY>;- the file list: for each path, run
wc -c <path>via Bash and show the basename with a humanised size (≥ 1 048 576 bytes → MB, ≥ 1 024 bytes → KB, otherwise bytes). A missing or unreadable path is surfaced here — say which file could not be read and stop, making no API call. - ⚠️ "Attachments cannot be removed by this skill once uploaded."
Step 3: Confirm before writing
Ask the user:
Send this to Jira? Reply y to confirm, n to revise, anything else to abort.
A clear y/yes proceeds; a n/revise stays in review (typically different
paths or a different key); anything ambiguous aborts with "Aborted — no Jira
write was made."
Step 4: Send the request
accelerator jira attach <KEY> <FILE> [FILE...]
Run the bare launcher directly as an executable; never prefix it with
bash/sh/env and never pipe its output.
Step 5: Render the response
On success the subcommand emits the attachments as a JSON array (it carries no outcome envelope — success is the clean, zero-status run). For each element show the filename, id, and humanised size (same KB/MB logic as Step 2):
✓ Attached to <KEY>:
- <filename> (ID: <id>, <humanised-size>)
If the array is empty or unparseable, tell the user "Upload succeeded but the
response was empty or unreadable." On a non-zero exit, show the error — a
missing/unreadable file or a credential failure names its cause on stderr;
suggest /init-jira for a credential failure.
Examples
Example — single file
User: /attach-jira-issue ENG-42 ./screenshot.png
Skill previews the upload (screenshot.png, e.g. 84.3 KB), waits for y,
uploads, and confirms with the returned id and size.
!accelerator config instructions attach-jira-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.