---
name: mcp-mantis-ticket-writer
description: Draft or refine MantisBT ticket text using the corporate default template and produce complete copy-paste sections (Riassunto, Description, Steps To Reproduce, Additional Information when applicable). Use when the main goal is disciplined ticket writing, not full multi-source technical intake.
---

# MCP Mantis Ticket Writer

Skill specialistica per scrivere o migliorare ticket MantisBT con output rigoroso, sezioni complete e template nominati.

## Quando usarlo

Usalo quando il compito principale e':

- scrivere un nuovo ticket Mantis partendo da contesto tecnico/funzionale;
- perfezionare un ticket Mantis esistente con testo piu' chiaro e riproducibile;
- uniformare il ticket a un template di team;
- ottenere snippet copy-paste pronti per MantisBT.

Non usarlo come intake analitico universale multi-sorgente: in quel caso passa a `mcp-technical-analyst`.

## Workflow Base

1. Chiarisci scenario: `nuovo ticket` oppure `ticket esistente da perfezionare`.
2. Seleziona template: built-in attivo (`bug-standard`) oppure template locale esterno.
3. Raccogli solo evidenze necessarie da fonti disponibili (utente, docs, codebase, SQL, ticket Mantis).
4. Se mancano dati essenziali, fai domande progressive minime (1-3 per ciclo).
5. Genera sempre sezioni complete e autonome, racchiudendo ciascuna in un blocco di codice testuale separato (fenced code block) per facilitare il copia-incolla esatto. Per evitare problemi di annidamento se includi snippet di codice standard negli sviluppi, racchiudi ogni singola sezione tramite 4 backtick (` ````text ` ````):
   - Riassunto (Titolo standardizzato)
   - Description (Descrizione problema/contesto)
   - Steps To Reproduce (Mapping obbligatorio aziendale: contiene `# Sviluppi` e `## Riferimenti tecnici`. L'intera analisi tecnica del ticket va inserita obbligatoriamente in questa sezione)
   - Additional Information (Mapping obbligatorio aziendale: contiene `# Test`, solo se pertinenti)
6. Dichiara fonti usate, limiti, dubbi aperti e livello di affidabilita' della riproducibilita'.

## Regola decisionale primaria

Questa skill usa una regola binaria obbligatoria:

1. Se i dati minimi sono insufficienti, fai solo 1-3 domande bloccanti e fermati.
2. Se i dati minimi sono sufficienti, produci subito l'output finale Mantis-ready.

Regole vincolanti:

- la prima risposta utile deve essere gia' il drafting finale;
- non fare introduzioni narrative del tipo "prima ti spiego poi formatto";
- non offrire una seconda formattazione alternativa;
- non mescolare domande e drafting finale nello stesso turno, salvo chiarimenti gia' chiusi.
- il Riassunto deve rispettare il formato titolo: `**ARGOMENTO** - ***ARGOMENTO2*** - Descrizione`.
- heading markdown ammessi nelle sezioni operative (`# Sviluppi`, `## Riferimenti tecnici`, `# Test`) con fallback testuale in grassetto.

## Checklist dati minimi sufficienti

I dati sono sufficienti quando sono disponibili (o risolti con default conservativo) questi elementi:

- scenario: `nuovo ticket` o `ticket esistente`;
- template: esplicito oppure default `bug-standard` per bug generico;
- comportamento osservato con contesto minimo;
- impatto operativo noto;
- stato della riproduzione: passi verificati oppure gap dichiarabili senza inventare.
- stato test: presenti/richiesti (include `Additional Information`) oppure assenti (sezione omessa).
- riferimenti tecnici: disponibili/deducibili (path, funzione/metodo, tabelle) oppure assenti con limite esplicito.

## Regole di escalation prompt -> skill

1. Se il contesto e' troppo ambiguo o richiede correlazione forte tra piu fonti eterogenee, l'indagine deve passare per `mcp-technical-analyst`. E' fortemente raccomandato avviare in autonomia un **subagent** per l'esplorazione tecnica: una volta ottenuto il suo output analitico, provvederai tu a iniettarlo direttamente nella sezione `Steps To Reproduce` -> `## Riferimenti tecnici`.
2. Se il task e' multi-fase (analisi + implementazione + test + handoff), coordina con `mcp-master-orchestrator`.
3. Se si tratta di sola operazione di dominio (solo query SQL, solo fix codice), usa skill specialistica e torna qui solo per il testo ticket finale.

## Contratto di output


## Limiti della Skill e Passaggio di Consegne (Escalation)

Una volta attivata questa skill per scrivere o rifinire il ticket, verifica i tuoi limiti operativi:

1. Se il contesto fornito dal prompt è troppo spoglio per redigere un ticket completo, e richiede prima una forte indagine tecnica su più fonti tramite `mcp-technical-analyst`, puoi **avviare un subagent** fornendogli il contesto parziale e le istruzioni per eseguire l'analisi come analista. Una volta terminata l'indagine, acquisisci il suo report Markdown e usalo per popolare fedelmente la sezione tecnica (`Steps To Reproduce`) del ticket Mantis, assicurandoti che rispetti la sintassi supportata (vedi `mantis-syntax.md`).
2. Se il task richiesto non è solo scrivere il ticket, ma comprende un intervento multi-fase (analisi profonda + fix + codice + test + handoff), delega l'orchestrazione a `mcp-master-orchestrator`.
3. Se l'utente ti chiede puramente modifiche operative (es. scrivere o lanciare una query SQL complessa, fare refactoring di codice), affidati innanzitutto ai tool specialistici o alle skill pertinenti, completando l'operazione tecnica prima di stilare il testo finale del ticket tramite questa skill.

## Contratto di output

Output minimo obbligatorio per ogni esecuzione:

- template usato;
- scenario (`nuovo ticket` o `ticket esistente`);
- fonti consultate;
- limiti/dubbi aperti;
- sezioni complete in sintassi MantisBT. OGNI SEZIONE deve essere restituita all'interno di un blocco testuale isolato (es. a 4 backtick, ` ````text ` ````) per permettere il copia-incolla sicuro e prevenire rotture coi blocchi di codice annidati:
  - Riassunto
  - Description
  - Steps To Reproduce
  - Additional Information (solo quando applicabile)

Regole forti:

- se i dati minimi bastano, la prima risposta utile e' gia' il formato finale Mantis-ready;
- se i dati minimi non bastano, porre solo 1-3 domande bloccanti;
- i riferimenti tecnici negli sviluppi sono condizionali e strutturati quando verificabili:
  - componente/path relativo;
  - funzione o metodo (linea solo se certa);
  - tabelle reali coinvolte se note;
  - snippet codice/query usando tripli backtick (es. ```sql ... ```) per specificare il linguaggio.
- no patch/diff del ticket;
- no output frammentario da ricomporre;
- no invenzione di passaggi di riproduzione non verificati;
- no invenzione di test non richiesti o non deducibili;
- no invenzione di path/funzioni/linee/tabelle;
- anche in refinement, riscrivere sempre la sezione completa;
- nessuna fase narrativa preliminare non necessaria.

## Riferimenti

**MANDATORIO:** Leggi SEMPRE il file `references/template-format.md` prima di validare l'output in modo da comprendere l'esatto vincolo semantico richiesto ai campi Mantis nella vostra installazione aziendale.

Carica gli altri riferimenti solo se servono:

- [references/workflow.md](references/workflow.md)
- [references/template-format.md](references/template-format.md)
- [references/interactive-questions.md](references/interactive-questions.md)
- [references/boundaries-and-escalation.md](references/boundaries-and-escalation.md)
- [references/output-rules.md](references/output-rules.md)
- [references/output-examples.md](references/output-examples.md)
- [references/mantis-syntax.md](references/mantis-syntax.md) (Regole specifiche per Code Blocks e Diff)