t3bootstrap-upgrade-skills/redmine-issue-workflow/SKILL.md

name, description, metadata

name	description	metadata
redmine-issue-workflow	Read and update issues on a self-hosted Redmine via its REST API from the CLI — list/read tickets, add notes, change status, edit an existing journal note in place, and download attachments. Use when a project tracks its work/bugs in Redmine and you need to look up 'the next fixes', check a ticket's details, mark work done, or maintain a collection ('Sammelticket') ticket. Covers: API-key auth via header (never inline the secret), the issues/journals/attachments endpoints, Textile (NOT Markdown) formatting, localized statuses, and the posting-style rules (keep customer-visible notes minimal — strike through or 'erledigt', don't write the bug's cause; don't post unless asked).	author version Wappler 1.3

Redmine issue workflow (REST API, CLI)

Read and update a self-hosted Redmine project's issues over its REST API from the shell. Redmine is where the team tracks bugs / "next fixes"; you look tickets up, and — only when asked — mark work done.

Placeholders (keep the concrete values in project memory, not here)

• <REDMINE_URL> — e.g. https://redmine.example.com.
• <PROJECT_SLUG> — the project identifier (used as project_id), e.g. ivv. (Numeric id also works.)
• <API_KEY_FILE> — a chmod 600 file holding the per-user REST API key (from Redmine → My account → API access key). Never inline the key — always read it in the header via $(cat …).
• <ISSUE_ID> / <JOURNAL_ID> — the ticket / journal-note ids.

Auth (every call)

curl -s -H "X-Redmine-API-Key: $(cat <API_KEY_FILE>)" "<REDMINE_URL>/…"

Keeps the secret out of the command line (auto-mode/secret guards block a literal key).

Read

• Open issues (the "next fixes"): GET /issues.json?project_id=<PROJECT_SLUG>&status_id=open&sort=priority:desc&limit=100 (status_id=open = all non-closed; sort=updated_on:desc to see the newest activity.)
• One issue with its notes: GET /issues/<ISSUE_ID>.json?include=journals,attachments.
• Pipe JSON through python3 -c "import sys,json;…" to print id / status / subject / assignee / notes.
• Statuses may be localized. A German instance uses: Fehler = bug (open), Gewünscht = wishlist/requested, Empfohlen = recommended, Abnahme = ready for customer sign-off. Confirm the instance's own status names via GET /issue_statuses.json before setting one by id.

Update (only when the user asks — see posting style)

• Add a note / change status / progress on an issue:

  curl -s -X PUT -H "X-Redmine-API-Key: $(cat <API_KEY_FILE>)" -H "Content-Type: application/json" \
    -d '{"issue":{"notes":"…","status_id":<N>,"done_ratio":<0-100>}}' \
    "<REDMINE_URL>/issues/<ISSUE_ID>.json"      # → 204 No Content on success
  

• Edit an EXISTING journal note in place (e.g. a collection ticket's item list that one person keeps appending to): PUT /journals/<JOURNAL_ID>.json with {"journal":{"notes":"…"}} → 204. Get the journal id from the issue's include=journals.
• Collection / "Sammelticket" pattern: one ticket stays open and holds a numbered item list (often in a single journal note). As items are done, strike them through and the ticket stays open for more.

Formatting — Textile, NOT Markdown

Redmine renders Textile by default. Consequences:

• Strike-through = -text- (Markdown ~~…~~ does nothing).
• A leading # is an ordered-list item, not a heading (Markdown # headings render as <ol><li>).
• Bold *text*, italic _text_, inline code @code@.

Posting style (team rules — important)

• Don't post unless asked. The user often does the Redmine updates themselves; offer/confirm first.
• Keep customer-visible notes minimal. Do NOT write out the bug's cause / technical explanation in the ticket. To mark something done, strike the item through (-…-) or just write "erledigt" beside it, where appropriate. The detailed root-cause/fix belongs in your own notes/memory, not the ticket. Two or three sentences is the norm: what is done, where to check it. No commit hashes, no file names, no before/after measurements — the customer did not ask how, only whether.
• No icons, emoji or decorative symbols in ticket text (no ✅/✔/→/⚠, no bullets made of glyphs). Plain sentences, plus Textile markup where it carries meaning (strike-through, bold). Team rule.
• Never set or change assigned_to_id. Post the note and the status, leave the assignee alone — reassigning is the user's call and a wrong one pulls a colleague into a ticket that isn't theirs. Note that status_id and done_ratio are fine to set; only ownership is off limits.
• Before posting a status change, prefer to draft the (short, German if the project is German) note and confirm the target status with the user.

Who does what — the same team across all TYPO3 projects

The assignee tells you what KIND of work a ticket is. These roles hold across projects, so read them before deciding whether a ticket is yours to act on. Any of them may be the one operating you — don't assume which, and don't assume a ticket is theirs just because they are asking about it.

• Ilja — senior developer. Code, templates, SCSS, TypoScript, deployments.
• Sven — senior developer and maintainer of the shared WapplerSystems extensions (address, ws_slider, hero-item, …). Coordinate with him before cutting a tag on one of those.
• Ranju — junior developer. Also on the development side, so a ticket assigned to her is technical, not editorial.
• Corinna — design and the bulk of editorial work. Content tickets (texts, images, page structure) are hers.
• Eva — project management, plus light editorial changes. Typically the one who maintains a Sammelticket's item list and re-assigns tickets.

Consequences:

• A ticket assigned to Corinna or Eva is editorial — don't silently do the work. Report what you found if it helps, but leave the change to them.
• CSS and code are yours even when the ticket is assigned to someone else. Tickets often mix the two: split them by the NATURE of each item, not by the assignee, do the technical half, and say plainly which half you left alone and why.
• This is also why the assignee must never be changed by you (above): it encodes the routing.

Attachments

GET /attachments/download/<id>/<name> needs the exact filename (a placeholder → 404 HTML). Reliable: GET /attachments/<id>.json → read content_url → curl -L THAT with the API-key header. Attached "screenshots" are often browser print-to-PDF files — readable directly once downloaded.