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 branch name or the MR title, 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. If you do not know which tracker that is, invoke sdlc:team-workflow-identify first.
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.
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. 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.