---
name: support-mr-fix
description: >
  Open a direct GitLab merge request that fixes a Pysae support bug, once the Airtable ticket and
  GitLab issue exist, the root cause is 100% identified, and Patrick has explicitly agreed the fix is
  small enough — it adds a small-fix safety gate upfront, delegates the code/branch/MR work to
  /code-implement, then updates the Airtable ticket with the MR URL. Use when the user says /support-mr-fix,
  'on propose une MR', 'on fait la MR', 'fix direct', 'correction directe', 'corrige ce bug et fais la MR',
  'ouvre une MR pour ce fix', 'open a MR to fix this', 'fix it directly', 'do the direct fix',
  'patch this and open the MR', or as a follow-up to /glab-issue-create --from-airtable. Distinct from
  /support-bug-investigate (which only diagnoses the root cause) — this skill actually writes the fix
  and opens the MR.
argument-hint: "[GitLab issue IID or URL, Airtable record ID if not already known]"
allowed-tools:
  - Read
  - Edit
  - Write
  - Glob
  - Grep
  - Bash
  - AskUserQuestion
  - Skill
---

Ouvrir une MR directe sur le repo Pysae concerné, **uniquement** quand le fix est petit et la cause racine 100% identifiée. Vient **après** `/support-ticket-create` puis `/glab-issue-create --from-airtable` — le ticket Airtable et l'issue GitLab restent la source de vérité pour la traçabilité.

Ce skill **n'implémente pas lui-même** le code : il ajoute une gate de validation en amont et un post-traitement Airtable en aval, puis délègue à `/code-implement` qui applique toutes les conventions du projet (branche `<type>/<IID>-<slug>`, commits atomiques, tests obligatoires, changelog, quality gate, MR via `glab` avec `Closes #<IID>`, `/label ~augmented`).

## Required tools

- `glab`
- `jq`

Run `pysae-ai-tools tools require <tools>` before starting; if it exits non-zero, abort and report the install command from stderr to the user.

## Quand utiliser — checklist « petit fix sans risque »

**Déclencheur** : Patrick accepte explicitement d'ouvrir une MR directe après une investigation, typiquement juste après que `/glab-issue-create --from-airtable` a retourné une IID.

**Toutes ces conditions doivent être vraies :**

- ✅ Cause racine 100% identifiée et confirmée par Patrick **et** Claude ensemble
- ✅ 1 à 5 fichiers touchés typiquement
- ✅ Pas de migration de base, pas de changement de schéma MongoDB
- ✅ Pas de changement d'API publique (pas de champ renommé, pas de nouveau endpoint, pas de changement de forme de réponse)
- ✅ Logique scopée : une condition, un bug de rendu, un mauvais label, un edge case identifié
- ❌ **Au moindre doute** → s'arrêter à `/glab-issue-create --from-airtable` et laisser un dev prendre le ticket

**Règle d'or** — *Always propose, never assume*. Claude propose la MR directe, Patrick valide, puis on avance. **Jamais** commencer à créer une branche sans accord explicite.

## Prérequis

Avant d'invoquer ce skill, tout cela doit exister :

- **Ticket Airtable** créé via `/support-ticket-create`
- **Issue GitLab** créée via `/glab-issue-create --from-airtable <recID>` — on a besoin de l'**IID** et du **project path** (ex : `pysae/api`)
- **Cause racine** documentée dans la description de l'issue (output de `/support-bug-investigate`)
- **Accord explicite** de Patrick pour ouvrir une MR directe

## Workflow

### 1. Gate de validation (obligatoire)

Avant toute action, demander à Patrick :

> Je propose d'enchaîner avec une MR de correction directe.
> - Cause racine : *{résumé en 1 phrase}*
> - Fichiers à modifier : *{liste, 1-5 max}*
> - Pas de migration DB ✅ — pas de changement d'API publique ✅
>
> Tu valides ? (y/N)

Si Patrick refuse ou hésite → **stop**. On laisse un dev prendre l'issue.

Si Patrick valide, on note l'`<IID>` et le `<recID>` Airtable (transmis dans `$ARGUMENTS` ou récupérables depuis le contexte de la conversation).

### 2. Cloner (ou mettre à jour) le repo localement

```bash
# PROJECT_PATH vient de l'issue GitLab (ex: pysae/api)
pysae-ai-tools code ensure-repo "${PROJECT_PATH}"
```

Note le `local_path` retourné. Se placer dans ce répertoire pour la suite :

```bash
cd "$(pysae-ai-tools code ensure-repo "${PROJECT_PATH}" | jq -r '.local_path')"
```

### 3. Déléguer l'implémentation à `/code-implement`

Invoquer `/code-implement <ISSUE_IID>` depuis le repo cloné. Le skill s'occupe de :

- Transition `workflow::In progress` sur l'issue
- Création de la branche `<type>/<IID>-<slug>` (type depuis le label `type::*` — pour un bug support c'est `fix/`)
- Lecture de l'issue, implémentation du fix
- Commits atomiques avec les bons préfixes Conventional Commits
- **Tests obligatoires** — pas de MR sans test qui prouve le fix
- Quality gate (ruff / black / mypy / pytest / pre-commit selon le repo)
- Entrée changelog dans `changelogs/`
- Création de la MR via `glab` avec `Closes #<IID>`, `/label ~augmented`, assignée à Patrick

Pas de duplication de ces étapes ici — le skill `/code-implement` est la source de vérité.

### 4. Post-traitement Airtable

Une fois la MR créée, **mettre à jour le ticket Airtable** via MCP Airtable (append au champ existant, ne pas écraser) :

```
baseId        = app79vpJ07qFIOEm1
tableIdOrName = tblHjCvyOcdq0Kw0z
recordId      = <recID>
fields        = {"Ticket Gitlab": "<issue_url>\n<mr_url>"}
```

Le champ `Ticket Gitlab` contient déjà l'URL de l'issue (écrite par `/glab-issue-create --from-airtable`). On ajoute l'URL de la MR en dessous.

### 5. Rapport à Patrick

Message final :

```
✅ MR ouverte : {mr_url}
Fichiers modifiés : {liste}
Tests ajoutés : {liste}
Issue {issue_url} → workflow::Under review
Ticket Airtable {rec_id} → MR URL ajoutée
```

## Ce que ce skill NE fait PAS

- **Pas de règles de nommage de branche propres** — `/code-implement` les applique (`fix/<IID>-<slug>`)
- **Pas de règles de formatage de commits/MR/changelog** — idem, héritées du projet
- **Pas d'assignee/labels spécifiques** — `/code-implement` + `/glab-mr` les gèrent (assigné à l'auteur, `augmented`, etc.)
- **Pas de test writing** — `/code-implement` exige un test qui prouve le fix

Si les conventions du projet changent (format changelog, label `augmented`, templates MR), elles sont automatiquement prises en compte — ce skill ne les duplique pas.

## Erreurs fréquentes

| Erreur | Correction |
|---|---|
| Démarrer sans accord explicite de Patrick | Toujours demander d'abord. Une MR directe est un engagement. |
| Sauter `ensure-repo` | Toujours passer par lui — sinon on bosse sur une copie périmée. |
| Dupliquer les règles de `/code-implement` | Laisser `/code-implement` faire son boulot, ce skill est un wrapper. |
| Oublier la mise à jour Airtable | Toujours append l'URL de la MR au champ `Ticket Gitlab`. |
| Proposer une MR si le fix touche > 5 fichiers | Stop, c'est trop gros pour un fix direct. Laisser au dev. |

## Enchaînement

**Avant** : `/support-ticket-create` puis `/glab-issue-create --from-airtable <recID>`.
**Pendant** : `/code-implement <IID>` (invoqué par ce skill).
**Après** : suivi de la MR en review par Patrick ou le dev de garde.

$ARGUMENTS
