Summary
Add file-attachment support to the workflow plugin's issue surface when the
issue provider is Jira (Data Center): upload local files, see what is
attached after a fetch, and download attachments to local disk.
Jira-only throughout — GitHub issues have no equivalent REST surface, so the
verbs refuse any non-Jira provider and the issue-attach runbook intent is
injected into the LLM context only under Jira (GitHub/filesystem sessions
never learn the feature exists).
Capabilities
Upload
workflow issue attach add --issue <KEY> [--type <t>] <file>... — uploads
one or more local files in a single multipart request
(X-Atlassian-Token: no-check). Additive (no overwrite); refreshes the
issue cache afterward.
List (projection)
A fetch projects the issue's attachment list to a sibling attachment.md
(one line per attachment: - <id>: <filename> (<size> bytes)), written only
when the issue has attachments and surfaced in the fetch output alongside
relation.md. Deliberately kept out of issue.md body/frontmatter so the
authored content stays clean.
Download
workflow issue attach get --issue <KEY> (--id <ID>... | --name <FN>... | --all) [--out <dir>]
— resolves the chosen attachments against a live issue GET and downloads the
bytes (curl -L) to local disk so they can be opened/read. Defaults to the
issue cache dir's attachments/ subdir.
Flow: fetch → read ids from attachment.md → attach get --id <ID> → Read
the downloaded file.
Implementation
- Client:
jira_upload_attachments (multipart) + jira_download_attachment
(follow-redirect download); shared auth lines factored out.
- Provider:
add_attachment (write) + get_attachment (read) operations;
base raises not-implemented so GitHub inherits as unsupported.
- Projection:
attachment.md normalize/render/write + read-only protection,
surfaced via IssueFetchContext.attachments.
- Backend/CLI:
attach subcommand group (add / get), Jira-only legacy
guard.
- Hook injection: provider-keyed
snippets/runbook/<provider>.md.
- Tests added across client/provider/cache/dispatcher/hook layers.
- Plugin version 0.6.3 → 0.7.1.
Summary
Add file-attachment support to the workflow plugin's issue surface when the
issue provider is Jira (Data Center): upload local files, see what is
attached after a fetch, and download attachments to local disk.
Jira-only throughout — GitHub issues have no equivalent REST surface, so the
verbs refuse any non-Jira provider and the
issue-attachrunbook intent isinjected into the LLM context only under Jira (GitHub/filesystem sessions
never learn the feature exists).
Capabilities
Upload
workflow issue attach add --issue <KEY> [--type <t>] <file>...— uploadsone or more local files in a single multipart request
(
X-Atlassian-Token: no-check). Additive (no overwrite); refreshes theissue cache afterward.
List (projection)
A fetch projects the issue's attachment list to a sibling
attachment.md(one line per attachment:
- <id>: <filename> (<size> bytes)), written onlywhen the issue has attachments and surfaced in the fetch output alongside
relation.md. Deliberately kept out ofissue.mdbody/frontmatter so theauthored content stays clean.
Download
workflow issue attach get --issue <KEY> (--id <ID>... | --name <FN>... | --all) [--out <dir>]— resolves the chosen attachments against a live issue GET and downloads the
bytes (
curl -L) to local disk so they can be opened/read. Defaults to theissue cache dir's
attachments/subdir.Flow:
fetch→ read ids fromattachment.md→attach get --id <ID>→ Readthe downloaded file.
Implementation
jira_upload_attachments(multipart) +jira_download_attachment(follow-redirect download); shared auth lines factored out.
add_attachment(write) +get_attachment(read) operations;base raises not-implemented so GitHub inherits as unsupported.
attachment.mdnormalize/render/write + read-only protection,surfaced via
IssueFetchContext.attachments.attachsubcommand group (add/get), Jira-only legacyguard.
snippets/runbook/<provider>.md.