---
name: forge-quick
description: "Mode rapide : mini-plan + exécution directe pour modifications mineures"
disable-model-invocation: true
allowed-tools:
  - Read
  - Write
  - Edit
  - Glob
  - Grep
  - Bash
---

## Contexte dynamique (injecté automatiquement)

**Dernière action quick :**
!`ls -t .planning/quick/ 2>/dev/null | head -1 || echo "Aucune action quick précédente"`

**Branche / status :**
!`git branch --show-current 2>/dev/null && git status --porcelain 2>/dev/null || echo "git non disponible"`

---

# forge-quick — Mode rapide

Tu exécutes une modification mineure (bug fix, ajout ciblé, refactor léger) sans
passer par le pipeline complet discuss → plan → execute → verify. Tu génères un
mini-plan, tu exécutes directement, et tu traces le tout dans `.planning/quick/`.

**IMPORTANT (D13)** : Les hooks de sécurité restent actifs. forge-quick n'est PAS
un bypass des garde-fous. enforce-files, check-scope, detect-residuals — tout
s'applique normalement.

---

## Entrée

`$ARGUMENTS` = description de la tâche (obligatoire).

Si `$ARGUMENTS` est vide ou absent :
> "Usage : `/forge-quick \"description de la tâche\"`
> Exemples :
> - `/forge-quick \"fix: le bouton submit ne répond pas au clic\"`
> - `/forge-quick \"add: endpoint GET /api/health\"`
> - `/forge-quick \"refactor: extraire la validation dans un helper\"`"

---

## Étape 1 — Préparation

### 1.1 — Générer le slug

Transformer la description en slug kebab-case :
- Retirer le préfixe `fix:`, `add:`, `refactor:` etc. s'il est présent (le garder pour le commit)
- Convertir en minuscules
- Remplacer les espaces et caractères spéciaux par des tirets
- Retirer les caractères non alphanumériques (sauf tirets)
- Tronquer à 40 caractères maximum
- Retirer les tirets en début/fin

Exemple : `"fix: le bouton submit ne fonctionne pas"` → `bouton-submit-ne-fonctionne-pas`

### 1.2 — Déterminer le numéro séquentiel

```bash
ls -d .planning/quick/[0-9][0-9][0-9]-* 2>/dev/null | tail -1
```

Si aucun dossier n'existe → `001`. Sinon, incrémenter le dernier numéro.
Formater sur 3 chiffres : `001`, `002`, ..., `999`.

### 1.3 — Créer le répertoire de tracking

```bash
mkdir -p .planning/quick/{NNN}-{slug}
```

---

## Étape 2 — Mini-plan

Générer un mini-plan XML via dagsmith-tools.js :

```bash
node .claude/bin/dagsmith-tools.js quick-plan --desc "$ARGUMENTS" --id "Q-{NNN}"
```

Écrire la sortie dans `.planning/quick/{NNN}-{slug}/PLAN.md` :

```markdown
# Quick — {NNN}-{slug}

> Généré par forge-quick

## Description
{$ARGUMENTS}

## Mini-plan
{sortie XML de quick-plan}
```

---

## Étape 3 — Lecture du contexte

Avant d'exécuter, lire :

1. Le mini-plan généré — comprendre les tâches à faire
2. `BLUEPRINT.md` — vérifier les conventions du projet (§7)
3. Les fichiers concernés par la modification — comprendre le code existant

Identifier les fichiers qui seront modifiés. Si le scope n'est pas clair depuis
la description, analyser le codebase pour localiser les fichiers pertinents.

---

## Étape 4 — Exécution directe

Exécuter les tâches du mini-plan toi-même (pas de teammate — le skill fait le travail).

Pour chaque tâche du mini-plan :
1. Lire les fichiers concernés
2. Implémenter la modification
3. Vérifier que la modification est cohérente avec le code existant

**Rappel** : les hooks sont actifs (D13). Si un hook bloque une action
(enforce-files, check-scope), respecter le blocage et ajuster le scope.

---

## Étape 5 — Vérification légère

### 5.1 — Tests

Lancer les tests du projet si disponibles :

```bash
# Détecter la commande de test
# Node.js : npm test ou node --test
# Python : pytest
# Rust : cargo test
# Adapter selon le projet
```

Si les tests échouent :
> "Les tests échouent après la modification. Vérifie le résultat et corrige
> avant de relancer `/forge-quick`."

Ne PAS commiter si les tests échouent.

### 5.2 — Structure (si pertinent)

Si des fichiers ont été créés, vérifier la structure :

```bash
node .claude/bin/dagsmith-tools.js check-structure --root .
```

---

## Étape 6 — Tracking (SUMMARY.md)

Écrire `.planning/quick/{NNN}-{slug}/SUMMARY.md` :

```markdown
# Quick {NNN} — {slug}

> Généré par forge-quick

## Description
{$ARGUMENTS}

## Fichiers modifiés
- {chemin} — {description du changement}

## Tests
- {PASS/FAIL/SKIP} — {détails}

## Résultat
{SUCCÈS/ÉCHEC}
```

---

## Étape 7 — Commit

Si l'exécution est réussie et les tests passent :

```bash
git add {fichiers modifiés} .planning/quick/{NNN}-{slug}/
git commit -m "{prefix}(quick-{NNN}): {description courte}"
```

Le préfixe du commit est déterminé par la description :
- `fix:` → `fix(quick-{NNN}): ...`
- `add:` → `feat(quick-{NNN}): ...`
- `refactor:` → `refactor(quick-{NNN}): ...`
- Autre → `chore(quick-{NNN}): ...`

---

## Étape 8 — Mise à jour STATE.md

Logger l'action quick dans STATE.md :

```bash
node .claude/bin/dagsmith-tools.js state-update \
  --key "## Quick Actions" \
  --value "Q-{NNN}: {description} ($(date -u +%Y-%m-%dT%H:%M:%SZ))" \
  --root .
```

---

## Étape 9 — Log pipeline

```
[{timestamp}] forge-quick: Q-{NNN} "{description}" — {SUCCÈS/ÉCHEC} ({N fichiers modifiés})
```

---

## Étape 10 — Résumé

**Si succès :**
> "Quick fix Q-{NNN} terminé.
> - Fichiers modifiés : {liste}
> - Tests : {PASS/SKIP}
> - Commit : `{hash}` — {message}
> - Tracking : `.planning/quick/{NNN}-{slug}/`"

**Si échec (tests échouent) :**
> "Quick fix Q-{NNN} échoué — les tests ne passent pas.
> Les modifications n'ont PAS été commitées.
> Corrige les problèmes puis relance `/forge-quick \"$ARGUMENTS\"`."

---

## Règles absolues

- **$ARGUMENTS obligatoire** — ne jamais exécuter sans description
- **Hooks actifs (D13)** — forge-quick n'est PAS un bypass de sécurité
- **Scope minimal** — ne modifier que ce qui est strictement nécessaire pour la description
- **Un seul commit** — pas de commits multiples, pas de refactor bonus
- **Tracking obligatoire** — même les quick changes sont traçables dans `.planning/quick/`
- **Ne PAS commiter** si les tests échouent
- **dagsmith-tools.js** pour STATE.md (D17) et quick-plan
- Ne pas utiliser forge-quick pour des tâches qui nécessitent le pipeline complet — si la description implique plus de ~5 fichiers ou un changement architectural, recommander le pipeline