file-ticket
File Ticket
File a new ticket: derive a title and body from the current conversation, fill in the target repo's issue template if it has one, surface near-duplicate open issues, get your review, then create it and hand back its number and URL.
This skill's flow is tracker-agnostic. Tracker-specific mechanics (the concrete implementation of each Operation below) live in skills/file-ticket/operations/<tracker>.md, one file per supported tracker, selected by this repo's configured tracker. V1 ships operations/github.md only.
1. Load or bootstrap the repo config
Read docs/agents/file-ticket.md for this repo's target repo, default labels, and tracker.
If that file doesn't exist yet, offer to create it:
- Target repo: never ask. Resolve silently via the
resolve-target-repo()Operation (no override, no default) and record the resolvedowner/repo. - Default labels: optional. Call
list-labels(repo)and present the repo's real labels for the user to pick defaults from; accept freeform text too, for a label that doesn't exist in the repo yet. An empty selection records the field as empty. - Tracker: always ask, via a closed-choice prompt: "Which tracker does this repo use? Currently supported:
github." Record whatever is answered, even if unsupported.
Present the drafted Target repo, Default labels, and Tracker together for confirmation before writing anything. If changes are requested, revise and present the full draft again. Once confirmed, write the file with just these three fields and ask whether to commit it on the current branch, folded into whatever this session is already about, or on a separate branch as its own PR. Either is legitimate, don't assume.
Whether just bootstrapped or loaded from an existing file, re-validate the loaded Tracker value against the trackers this build ships an operations file for (skills/file-ticket/operations/<tracker>.md exists; github only, today). If it isn't one of them, surface a loud warning (filing will fail) and stop. Do this on every load, not just at bootstrap, so support landing later clears the warning automatically and a config that regresses catches it again.