---
name: support-ticket-create
description: "Create an Airtable support ticket in the Pysae Customer Service base from an Intercom conversation. Always includes a concise GitLab pre-analysis in the Notes field. Use when the user says /support-ticket-create, 'créer un ticket support', 'ticket Airtable', 'on transforme cet Intercom en ticket', or after investigating a bug that needs a Customer Service ticket."
argument-hint: "[Intercom conversation URL, .txt export, or raw bug description]"
allowed-tools:
  - Read
  - Glob
  - Grep
  - Bash
  - AskUserQuestion
  - Skill
---

Créer un ticket Airtable dans la base **Customer Service** (`app79vpJ07qFIOEm1`) à partir d'une conversation Intercom. Remplace l'automatisation N8N historique. Toujours inclure une pré-analyse GitLab concise dans le champ Notes.

**Prérequis :** MCP Airtable configuré. Pour l'investigation, `pysae-ai-tools code ensure-repo` est disponible (installé avec le package).

## Identifiants Airtable (fixes)

Voir [../references/support-airtable.md](../references/support-airtable.md) pour les IDs (base, tables, champs) et la grille criticité/impact. Voir [../references/support-vocabulary.md](../references/support-vocabulary.md) pour le mapping `Sujet` → repo GitLab.

## Workflow

1. **Lire la source** (Intercom .txt ou URL) — extraire : email du contact, description du problème, timestamps, captures, tests menés par Patrick.
2. **Matcher le contact** — recherche dans la table `Contacts` (`tblsA80YLd7cMOjoV`) par email. Si pas trouvé, on laisse vide, ce n'est pas bloquant.
3. **Matcher le compte** — si Patrick fournit un `group_id`, recherche dans la table `Comptes` (`tblbQQyq0RLodDcEb`) pour retrouver le nom du réseau. Sinon laisser vide.
4. **Investiguer le bug** — invoquer `/support-bug-investigate` avec le contexte disponible. Le skill clone les repos nécessaires localement et produit un rapport concis.
5. **Créer le ticket Airtable** via MCP Airtable `create_records` sur la table `tblHjCvyOcdq0Kw0z`. Remplir tous les champs selon les règles ci-dessous.
6. **Proposer la suite** à Patrick :
   - Créer l'issue GitLab → `/glab-issue-create --from-airtable <recID>` (le skill injectera les labels `workflow::To Do` + `Support 📞` en plus du template standard)
   - Option MR directe après l'issue, si petit fix → `/support-mr-fix`

## Règles de remplissage des champs

| Champ | Règle |
|---|---|
| **Nom** | Court, descriptif, style existant des tickets |
| **Status** | Toujours « Ouvert » |
| **Contact** | Match par email dans la table Contacts (sinon vide) |
| **Compte** | Match `group_id` → nom du réseau dans Comptes (sinon vide) |
| **Sujet** | Un parmi : OP, Driver, Info, Screen, Editor, API, INFRA — voir guide ci-dessous |
| **Responsable** | Toujours « Patrick LEMOS CAIXAS » |
| **Criticité** | 1-5 — **toujours sous-estimer**, viser < 8 étoiles cumulées |
| **Impact** | 1-5 — idem |
| **Date déclaration** | Date du jour |
| **Notes** | 3 sections (voir Structure Notes) |

## Guide de décision — champ `Sujet`

| Symptôme | Sujet |
|---|---|
| Backend, export, rapports, bugs de données | **API** |
| Bugs d'affichage sur la carte de supervision | **OP** |
| Bugs appli conducteur | **Driver** |
| Information voyageurs (données/logique) | **Info** |
| Affichage écran voyageurs | **Screen** |
| Éditeur GTFS / Plan de Transport | **Editor** |
| Serveur, déploiement, infrastructure | **INFRA** |

## Règle d'or — scoring Criticité + Impact

**Toujours éviter les tickets avec 8+ étoiles cumulées.** Sous-estimer plutôt que sur-estimer. N'atteindre 8+ que si réellement inévitable.

## Structure Notes (obligatoire)

Le champ Notes contient **toujours 3 sections dans cet ordre** :

### Section 1 — Observations Patrick

Reprendre intégralement le contexte de Patrick (depuis son message ou l'Intercom) :
- Ses tests, ce qu'il a essayé
- Les appels API qu'il a testés
- Les URLs, captures, comportements observés

**Preuve de première main, ne jamais la couper.**

### Section 2 — Pré-analyse Claude

La sortie directe du skill `/support-bug-investigate` : Résumé du bug / Cause racine / Chemin d'exécution / Quoi faire.

### Section 3 — Liens utiles

**Obligatoire.** Pour permettre aux devs de reproduire et vérifier :

```markdown
## Liens utiles
- Datadog logs : <URL de recherche directe avec le query construit>
- API en erreur : <endpoint exact depuis Datadog ou le message de Patrick>
- Conversation Intercom : <URL de la conversation>
- Code : <URL GitLab directe vers les fichiers source pertinents>
```

## Erreurs fréquentes

| Erreur | Correction |
|---|---|
| Sur-scorer | Par défaut, scorer bas. 4/5 et 5/5 sont exceptionnels. |
| Ne pas chercher dans Contacts | Toujours chercher l'email avant d'abandonner. |
| Notes vide ou sans pré-analyse | Toujours lancer `/support-bug-investigate` avant. |
| Mauvais Sujet | Backend = API, pas OP. Bugs d'affichage sur la carte de supervision = OP. |
| Bloquer sur `group_id` manquant | Créer le ticket, Compte reste vide. |
| Oublier les liens utiles | Toujours au moins Datadog + Intercom. |

## Enchaînement

Une fois le ticket créé, proposer à Patrick :
- `/glab-issue-create --from-airtable <recID>` pour créer l'issue GitLab dev (en respectant les conventions du projet : templates GitLab dynamiques, labels `priority::*`, `type::*`, board column `workflow::To Do`, `/label ~augmented`, plus `Support 📞`).
- Puis éventuellement `/support-mr-fix` si petit fix sans risque — jamais sans validation explicite de Patrick.

$ARGUMENTS
