AI Coding Workflow, Rules & Skills : guide complet (avec exemples)

1. Pourquoi le codage IA a besoin de Workflow, Rules et Skills en couches

Les assistants de codage IA sont des Agents avec accès aux outils : ils lisent les dépôts, modifient des fichiers, exécutent le terminal. Leur faiblesse est évidente—chaque nouveau chat repart de zéro sans réinjection des normes d’équipe. Pire : certains empilent style de code, politique Git, checklists de release et runbooks d’incident dans une seule User Rule. Chaque message porte alors des milliers de tokens de politique, au détriment des diffs et logs utiles.

La bonne pratique 2026 : séparer contraintes et procédures en trois couches :

• Workflow : comment démarrer une tâche IA—commandes slash, modes Plan/Agent, déclencheurs CI, orchestration Agent distante.
• Rules : ce qui tient toujours—style, répertoires interdits, tests obligatoires, lignes rouges sécurité.
• Skills : ce qui s’exécute à la demande—checklists review, release Xcode, runbooks de migration, généralement dans SKILL.md.

Même logique que notre guide des modes de développement Agent : les points d’entrée définissent les frontières, pas les paramètres du modèle. Standard ouvert Skills : Agent Skills Specification ; Rules Cursor : documentation.

La superposition améliore aussi la revue : modifier une Rule impacte chaque conversation future—cela mérite un PR soigné. Mettre à jour un Skill ne coûte du contexte qu’à l’invocation. Changer un Workflow touche la doc de commande ou le job CI, pas le comportement global.

2. Comment classifier Workflow, Rules et Skills

2.1 Workflow — démarrage et orchestration

Le Workflow répond à qui lance l’Agent, et quand. Exemples : commandes Cursor /generate-blog, bascule Plan/Agent, /loop Claude Code, GitHub Actions avec IA pour corriger le CI, passerelles OpenClaw vers Mac distant. Le Workflow traite déclencheurs, machines d’état, chemins d’artefacts—pas le formatage d’une ligne.

2.2 Rules — couche de contraintes permanente

Les Rules sont du contexte résident : .cursor/rules/*.mdc, Settings, AGENTS.md. Contenu : diff minimal, zones interdites, conventions de commit, langue de réponse, tests obligatoires. Rules : courtes, fermes, exécutables. Pas de procédure release en 30 étapes dans une Rule—c’est du Skill.

2.3 Skills — runbooks à la demande

Les Skills sont des paquets chargés à la demande : .claude/skills/<name>/SKILL.md ou .cursor/skills/<name>/SKILL.md. L’Agent lit d’abord description dans le frontmatter. Approfondissement : guide Claude Code Skills : framework 10 skills.

3. Tableau comparatif

3.1 Rules vs Skills

4. Matrice de décision

5. Stacks recommandés

Stack A — minimum (demi-journée)

• 3 User Rules : diff minimal, pas de commit non sollicité, lint après edits
• .cursor/rules/blog-writing.mdc spécifique au repo
• Skill commit pour Conventional Commits

Stack B — équipe

• testing.mdc + security.mdc (< 80 lignes)
• Skills code-review, security-review
• PR : /security-review avant merge

Stack C — iOS

• xcode-release avec disable-model-invocation: true
• Pas de *.xcodeproj sans demande explicite
• M4 local ou Hashvps Cloud Mac ; tendances GitHub Actions macOS

Stack D — contenu/docs

• /generate-blog (brief → zh → i18n)
• blog-standard-spec-v1.mdc
• Skills translate-to, seo-optimize

6. Erreurs fréquentes

• « Tout dans les User Rules » → Prompt gonflé ; runbooks dans les Skills.
• « Plus de Skills = mieux » → Conflits de description ; moins de 10, frontières claires.
• « Workflow remplace le CI » → Gates dans GitHub Actions / Xcode Cloud.
• « Rules et Skills ensemble » → Mécanismes de revue différents.
• « xcode-release sans Mac » → codesign exige macOS.
• « Plan Mode = Workflow » → Plan = interaction ; Workflow = répétable et scriptable.

7. Sept étapes avec exemples

1. Auditer les prompts répétés : même checklist trois fois ? → Skill.
2. Écrire 3 Rules : uniquement les lignes rouges « toujours vraies ».
3. Créer les dossiers Skill : mkdir -p .cursor/skills/code-review ou .claude/skills/code-review.
4. Frontmatter SKILL.md : verbe + scénario ; risque : disable-model-invocation: true.
5. Définir le Workflow : gates dans .cursor/commands/*.md.
6. Commiter dans Git : Rules et Skills avec le code.
7. Lier les nœuds d’exécution : shell/Xcode → macOS (local ou Cloud Mac).

# .cursor/rules/core.mdc
---
description: Core engineering constraints for this repo
globs: "**/*"
---
- Minimize diff scope; do not refactor unrelated code.
- Never commit unless the user explicitly asks.
- Run tests for touched packages before claiming done.

# .cursor/skills/code-review/SKILL.md
---
name: code-review
description: Review staged git diff for bugs, security, and test gaps. Use when user asks for review or before PR.
---
1. Run `git diff --staged` (or compare branch to main).
2. Output: Critical / Warning / Suggestion in three sections.
3. Do not auto-fix unless user asks.

# .cursor/commands/release-ios.md
## Workflow
1. User confirms brief / scope on main branch.
2. Agent runs /test-runner Skill on changed targets.
3. Manual /xcode-release only after CI green.
4. Post changelog; never skip codesign on shared runner.

8. Synthèse

En 2026, la compétitivité du codage IA repose sur l’ingénierie de workflow, pas sur un score de modèle. Workflow démarre les tâches ; Rules gardent la ligne ; Skills transforment les checklists seniors en runbooks versionnés. D’abord superposer—ensuite un abonnement plus cher.

La capacité du modèle n’est pas la ligne de partage ; les points d’entrée et frontières d’exécution le sont. Cursor Rules · Claude Code Skills · Agent Skills