---
name: support-ticket-create
description: >
  Create an Airtable support ticket in the Pysae Customer Service base from an Intercom conversation,
  always including a concise GitLab pre-analysis in the Notes field. Use when the user says /support-ticket-create,
  'crée un ticket support', 'créer un ticket support', 'ticket Airtable', 'ouvre un ticket support',
  'on transforme cet Intercom en ticket', 'transforme cette conversation en ticket', 'enregistre ce bug en ticket',
  'create a support ticket', 'open a support ticket', 'turn this Intercom into a ticket', 'log this as a support ticket',
  or after investigating a bug that needs a Customer Service ticket. Distinct from /support-product-ticket
  (a Notion roadmap suggestion) and /glab-issue-create (a GitLab dev issue) — this skill files the Airtable
  Customer Service support 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
