Learn how this team writes tickets, and cache the result.

Slow: it reads the comments and linked changes of up to sample closed tickets, which is a few hundred API calls. Call it once per project, not once per question.

Pass from_tickets when the user can name good examples - those are taken as given and nothing is filtered out. Leave it empty and the tracker is mined instead: closed tickets are ranked by whether a merge request shipped for them, whether anyone had to reopen them, and how many clarifying questions they drew before work started.

What this team's tickets look like: template, length, labels, habits.

Reads the cached profile. Says so plainly if none has been learned yet rather than returning something empty that looks like an answer.

The skeleton to fill in when writing a new ticket here.

Use this before drafting, not after. It returns the sections this team actually uses and the length they actually write - then write the ticket yourself. The server has no opinion about the content.

Compare the issue template this repository declares with the tickets it gets.

Reads .github/ISSUE_TEMPLATE or .gitlab/issue_templates from the checkout and lines each field up against how often tickets actually carry it. The gap is the finding, and it runs both ways:

• A required field almost nobody fills in is a form asking for something people cannot easily supply. Say so: the cheap fix is to change the form, not to nag the team.

• A section most tickets carry that no form mentions is a convention the project grew and never wrote down. Adding it to the template is how it survives the next person who joins.

Use this when asked how to improve a board rather than one ticket. It is the only tool here that reads what the project said it wanted, instead of only what it does.

Gather what is known about a subject before you write the ticket for it.

Call this together with ticket_template, then write the ticket yourself. This returns evidence, not prose - and specifically the evidence you cannot get by reading the repository:

• which past tickets covered this ground, so you can say whether this is a duplicate before anyone spends a week on it;

• which files the merge requests for those tickets actually changed. That exists only in the tracker's history. It is usually the fastest way to find where the work will land, and it is worth naming in the ticket.

• which files in the checkout mention the subject, as a starting point for your own reading.

Read the files it points at before drafting. The list is a search result, not an understanding of the code, and it will include things that merely share a word.

Check a ticket you have written but not created yet.

Call this on your own draft before showing it to the user, and fix what it finds rather than reporting it. It is the same measurement review_ticket runs, so a draft that passes here passes there.

This exists so the check happens before the point of no return. Creating the ticket first notifies whoever watches the board and turns every fix into an edit with a history.

Measure one ticket against the learned house style.

Every finding cites a count over the exemplar sample. Repeat those numbers to the user - they are the difference between this and generic advice.

Review every open ticket and list them least-aligned first.

A planning tool: the answer to "what needs tidying before we can estimate any of this". One line per ticket, so call review_ticket for the detail on the ones that matter.