ticket-draft: incorrect error message suggesting i couldnt' file an issue #130

--- Turn 1 ---

Person: Idea for a skill or routine that combines the audit and update ticket skills (or tools underneath). it's basically a skill that updates the backlog for a single user. It would look at the status of a single users PRs, local work in sessions, and any other context i'm not thinking of, and then update tickets (including pushing out the due date if necessary, changing status, posting a comment, closing with a reason etc.). It would not by default update anyone elses ticket, unless you are assigned or reporter, and it would ask for all the changes.

Does this make sense? I assume we have all the tooling already there too.

Tools: Bash x2

Claude: It makes sense, and most of what it needs already exists. The closest fit is a new **`mine` sweep inside `ticket-audit`** rather than a separate skill. `ticket-audit`'s Apply step already turns findings into a `using-jira` write plan, and that plan already handles closing with a reason, changing due dates, changing the assignee and posting comments. The Atlassian gate hook already blocks any Jira write the plan didn't list. What the plugin lacks is the part you're adding: picking out one person's tickets and tying each ticket to that person's own work.

## What's already there

| Need | Existing piece |
| --- | --- |
| Read a ticket | `source-reader`, task `ticket` |
| State of each PR (whose move is next, unanswered threads, draft age, branch behind) | `pr-reader` in `state` mode, as the `pulls` sweep already uses it |
| Where a ticket stands from local work | `scripts/next_phase.py`, reading `.review/` and the branch, which is what `/work` uses |
| Match a ticket to its PR by key in the title or branch | The `estimates` sweep already does this |
| Close as done vs. close as won't-do | `ticket-audit` Apply's `close` row, mapped through `jira.roles` |
| Approve every change before it's written | `skills/using-jira/write-plan.md` plus `hooks/atlassian-gate.sh` and `.review/jira-approval.json` |
| Re-scope or split a ticket | Handed to `/lasp-dev:ticket-draft <key>` |
| GitHub Issues as the tracker | `skills/ticket-audit/github.md` |

## Gaps

1. **Choosing the tickets.** Every current sweep covers the whole project and reports "by ticket, never by person" on purpose. The `mine` sweep would select `assignee = currentUser() OR reporter = currentUser()` instead. A sweep run by the person on their own tickets doesn't conflict with that rule, but the skill should say why it's the exception. The "only my tickets" rule has to be enforced when the plan is built: the gate hook checks approval, not who owns a ticket. That makes it worth a test that a ticket belonging to someone else never becomes a plan item.
2. **Local work across repositories.** `next_phase.py` only reads the repository it runs in. The standard's `profiles/` lists repository names, not where they're cloned on your machine, so the sweep needs those paths, or it has to ask for them.
3. **Session history.** `scripts/transcript_excerpt.py` only pulls the last few turns of the current session. Nothing maps past sessions to tickets. Each session file under `~/.claude/projects/` does record the git branch, so sessions could be matched to tickets that way. They're large to read, though, and private. My recommendation is to use `.review/` (plans, build outcomes) and git activity first and treat transcripts as an optional extra.
4. **New due dates.** Apply's `re-date` currently takes the new date from the milestone's month. "This is slipping" needs a date nobody has given. Under your "don't invent a default" rule, the sweep should flag the ticket as overdue or at risk, with the evidence, and ask you for the date.
5. **Comment and status actions.** Apply has no row yet for "post a progress comment" or for a status change that isn't a close (for example, moving a ticket into review because its PR is open). Both are small additions to the table. Also, the AI assistance level label covers PR prose and published pages but not Jira comments; you'd need to decide whether these comments carry it.

On running it as a routine: a scheduled cloud agent can't see your local sessions or `.review/` files, and every write needs your yes anyway. A schedule could at most produce the report and the plan in read-only form for you to approve later.

Two decisions would shape it:
- Should session transcripts be read at all, or is `.review/` plus git enough?
- Should Jira comments carry the AI assistance level?

If you like, I can draft this as a GitHub issue on the plugin with `/lasp-dev:ticket-draft`, with those two left as open questions.

--- Turn 2 ---

Person: yes, draft the issue. I agree with your suggestion 3 on the .review over transcripts.

Tools: Skill (lasp-dev:ticket-draft), Bash

Claude asked: This repository has no issue tracker recorded, so ticket-draft won't take its GitHub-issue path without one. How should I go on? To draft it as a GitHub issue anyway, type that under Other.

Person answered: Thats incorrect. We are in the plugins repo here repos/dev-tools. we track issues on github at lasp/dev-tools

Tools: Bash, Write, Agent (lasp-dev:source-reader), Agent (lasp-dev:ticket-investigator), Bash

Claude: I'm waiting on the duplicate search and the code investigation.

Claude: The duplicate search found #92, an open skill-feedback issue asking for "an option just for my tickets (could modify ticket audit)". I'll compare it with the full idea once the code investigation is back.