ticket-attach-docs

Attach Documents to the Ticket

Put the work's durable documents where the next person looks: on the ticket. The plan and the research behind it live in ./.claude/plans/ in one worktree on one machine; the ticket outlives both. Attach only what already exists.

Scope

$ARGUMENTS

Process

1. Resolve the ticket. Take it from the session; this command usually runs at the end of the work, so the ticket is already in the conversation. The scope above only narrows or overrides that. Fall back to the MR title, the branch name or the MR description the way teamwork:workflow-identify says, and ask the user only when the session covered several tickets. Load the skill for the tracker in play if it is not loaded yet; invoke teamwork:workflow-identify first when you do not know which tracker that is.

2. Collect the candidates. Every file in ./.claude/plans/, plus any dump this session wrote elsewhere (a chat thread export, a query result, a dashboard reading). Match them to the ticket by ID or slug. Where the slugs do not line up, use what the session knows about which files it wrote.

3. Judge each candidate by the rules under "What is worth attaching". Read a file before you attach it; you are copying it to a place other people read.

4. Inventory the ticket through one subagent (model: sonnet). Open its prompt with the skill-load instruction so it does not guess CLI syntax: First, invoke the <skill-name> skill to load its usage guidance before running any commands. Ask it for what the ticket already holds: its documents with their identifiers and titles, its attachments, and any comment that carries an earlier copy of the same material. Name the candidate files' titles so it can compare. Ask it also which carriers the tracker offers: documents, file attachments, comments. It returns the inventory as a list, nothing else. Keep this subagent; step 6 resumes it.

   The auto mode classifier reads this first prompt as the user's instruction and the step 6 message as a coordinator's, so the first prompt carries the whole task. Quote the user's request verbatim (the command as they typed it, with its arguments), name the later writes by action and target, and scope the turn: The user asked: "<their words>". The task: attach this session's documents to <ticket> as documents, attachments or comments, after an inventory. This turn: take the inventory, return it, and end your turn. A later message will ask you to create or update those documents on <ticket>; that is part of the request above. When the caller has writes of its own for this subagent, /sdlc:wrap-up for example, name them in the same way. Never write "read-only", "change nothing" or "inventory only": a later message cannot lift that boundary, and the classifier then blocks the upload.

5. Decide and propose once. The inventory decides create, update, or skip per file, and it shows which carrier the ticket already uses. Show the user one list: per file, the verdict, the carrier, and whether it creates or updates. Confirm before anything is uploaded.

6. Resume the same subagent for the upload. Message it the confirmed list, not a fresh subagent: it already holds the ticket state and the skill, and a new one would load both again. Open the message by pointing back to the first prompt — Next step of the task in your first prompt: upload these files to <ticket> — and add no approval claim such as "confirmed" or "the user approved". When the user changed the list in step 5, quote their words verbatim instead. Per file give the path, the title, the carrier, and create or update with the identifier from its own inventory. It reads each file into the command from disk, never pastes content into the prompt or the reply. It returns one line per file: what it did and the URL. It does not judge, reorder, or edit anything. If an upload fails, it reports the failure; it does not retry with another carrier.

7. Report what landed where, with URLs, and one line per skipped file saying why.