traduction
This commit is contained in:
@@ -0,0 +1,217 @@
|
||||
---
|
||||
name: agent-browser
|
||||
description: CLI d’automatisation de navigateur pour agents IA. À utiliser lorsque l’utilisateur doit interagir avec des sites web, notamment naviguer dans des pages, remplir des formulaires, cliquer sur des boutons, prendre des captures d’écran, extraire des données, tester des apps web ou automatiser toute tâche navigateur. Les déclencheurs incluent les demandes de type "open a website", "fill out a form", "click a button", "take a screenshot", "scrape data from a page", "test this web app", "login to a site", "automate browser actions", ou toute tâche nécessitant une interaction web programmatique.
|
||||
allowed-tools: Bash(agent-browser:*)
|
||||
---
|
||||
|
||||
# Automatisation de navigateur avec agent-browser
|
||||
|
||||
## Workflow principal
|
||||
|
||||
Toute automatisation de navigateur suit ce schéma :
|
||||
|
||||
1. **Naviguer** : `agent-browser open <url>`
|
||||
2. **Capturer l’état** : `agent-browser snapshot -i` (obtenir des références d’éléments comme `@e1`, `@e2`)
|
||||
3. **Interagir** : utiliser les refs pour cliquer, remplir, sélectionner
|
||||
4. **Reprendre une capture d’état** : après navigation ou changements DOM, obtenir de nouvelles refs
|
||||
|
||||
```bash
|
||||
agent-browser open https://example.com/form
|
||||
agent-browser snapshot -i
|
||||
# Output: @e1 [input type="email"], @e2 [input type="password"], @e3 [button] "Submit"
|
||||
|
||||
agent-browser fill @e1 "user@example.com"
|
||||
agent-browser fill @e2 "password123"
|
||||
agent-browser click @e3
|
||||
agent-browser wait --load networkidle
|
||||
agent-browser snapshot -i # Check result
|
||||
```
|
||||
|
||||
## Commandes essentielles
|
||||
|
||||
```bash
|
||||
# Navigation
|
||||
agent-browser open <url> # Navigate (aliases: goto, navigate)
|
||||
agent-browser close # Close browser
|
||||
|
||||
# Snapshot
|
||||
agent-browser snapshot -i # Interactive elements with refs (recommended)
|
||||
agent-browser snapshot -i -C # Include cursor-interactive elements (divs with onclick, cursor:pointer)
|
||||
agent-browser snapshot -s "#selector" # Scope to CSS selector
|
||||
|
||||
# Interaction (use @refs from snapshot)
|
||||
agent-browser click @e1 # Click element
|
||||
agent-browser fill @e2 "text" # Clear and type text
|
||||
agent-browser type @e2 "text" # Type without clearing
|
||||
agent-browser select @e1 "option" # Select dropdown option
|
||||
agent-browser check @e1 # Check checkbox
|
||||
agent-browser press Enter # Press key
|
||||
agent-browser scroll down 500 # Scroll page
|
||||
|
||||
# Get information
|
||||
agent-browser get text @e1 # Get element text
|
||||
agent-browser get url # Get current URL
|
||||
agent-browser get title # Get page title
|
||||
|
||||
# Wait
|
||||
agent-browser wait @e1 # Wait for element
|
||||
agent-browser wait --load networkidle # Wait for network idle
|
||||
agent-browser wait --url "**/page" # Wait for URL pattern
|
||||
agent-browser wait 2000 # Wait milliseconds
|
||||
|
||||
# Capture
|
||||
agent-browser screenshot # Screenshot to temp dir
|
||||
agent-browser screenshot --full # Full page screenshot
|
||||
agent-browser pdf output.pdf # Save as PDF
|
||||
```
|
||||
|
||||
## Motifs courants
|
||||
|
||||
### Soumission de formulaire
|
||||
|
||||
```bash
|
||||
agent-browser open https://example.com/signup
|
||||
agent-browser snapshot -i
|
||||
agent-browser fill @e1 "Jane Doe"
|
||||
agent-browser fill @e2 "jane@example.com"
|
||||
agent-browser select @e3 "California"
|
||||
agent-browser check @e4
|
||||
agent-browser click @e5
|
||||
agent-browser wait --load networkidle
|
||||
```
|
||||
|
||||
### Authentification avec persistance d’état
|
||||
|
||||
```bash
|
||||
# Login once and save state
|
||||
agent-browser open https://app.example.com/login
|
||||
agent-browser snapshot -i
|
||||
agent-browser fill @e1 "$USERNAME"
|
||||
agent-browser fill @e2 "$PASSWORD"
|
||||
agent-browser click @e3
|
||||
agent-browser wait --url "**/dashboard"
|
||||
agent-browser state save auth.json
|
||||
|
||||
# Reuse in future sessions
|
||||
agent-browser state load auth.json
|
||||
agent-browser open https://app.example.com/dashboard
|
||||
```
|
||||
|
||||
### Extraction de données
|
||||
|
||||
```bash
|
||||
agent-browser open https://example.com/products
|
||||
agent-browser snapshot -i
|
||||
agent-browser get text @e5 # Get specific element text
|
||||
agent-browser get text body > page.txt # Get all page text
|
||||
|
||||
# JSON output for parsing
|
||||
agent-browser snapshot -i --json
|
||||
agent-browser get text @e1 --json
|
||||
```
|
||||
|
||||
### Sessions parallèles
|
||||
|
||||
```bash
|
||||
agent-browser --session site1 open https://site-a.com
|
||||
agent-browser --session site2 open https://site-b.com
|
||||
|
||||
agent-browser --session site1 snapshot -i
|
||||
agent-browser --session site2 snapshot -i
|
||||
|
||||
agent-browser session list
|
||||
```
|
||||
|
||||
### Navigateur visuel (débogage)
|
||||
|
||||
```bash
|
||||
agent-browser --headed open https://example.com
|
||||
agent-browser highlight @e1 # Highlight element
|
||||
agent-browser record start demo.webm # Record session
|
||||
```
|
||||
|
||||
### Fichiers locaux (PDF, HTML)
|
||||
|
||||
```bash
|
||||
# Open local files with file:// URLs
|
||||
agent-browser --allow-file-access open file:///path/to/document.pdf
|
||||
agent-browser --allow-file-access open file:///path/to/page.html
|
||||
agent-browser screenshot output.png
|
||||
```
|
||||
|
||||
### Simulateur iOS (Mobile Safari)
|
||||
|
||||
```bash
|
||||
# List available iOS simulators
|
||||
agent-browser device list
|
||||
|
||||
# Launch Safari on a specific device
|
||||
agent-browser -p ios --device "iPhone 16 Pro" open https://example.com
|
||||
|
||||
# Same workflow as desktop - snapshot, interact, re-snapshot
|
||||
agent-browser -p ios snapshot -i
|
||||
agent-browser -p ios tap @e1 # Tap (alias for click)
|
||||
agent-browser -p ios fill @e2 "text"
|
||||
agent-browser -p ios swipe up # Mobile-specific gesture
|
||||
|
||||
# Take screenshot
|
||||
agent-browser -p ios screenshot mobile.png
|
||||
|
||||
# Close session (shuts down simulator)
|
||||
agent-browser -p ios close
|
||||
```
|
||||
|
||||
**Prérequis :** macOS avec Xcode, Appium (`npm install -g appium && appium driver install xcuitest`)
|
||||
|
||||
**Appareils réels :** fonctionne avec des appareils iOS physiques s’ils sont préconfigurés. Utilise `--device "<UDID>"`, où l’UDID provient de `xcrun xctrace list devices`.
|
||||
|
||||
## Cycle de vie des refs (important)
|
||||
|
||||
Les refs (`@e1`, `@e2`, etc.) sont invalidées lorsque la page change. Reprends toujours un snapshot après :
|
||||
|
||||
- Clics sur des liens ou boutons qui naviguent
|
||||
- Soumissions de formulaires
|
||||
- Chargement de contenu dynamique (menus déroulants, modales)
|
||||
|
||||
```bash
|
||||
agent-browser click @e5 # Navigates to new page
|
||||
agent-browser snapshot -i # MUST re-snapshot
|
||||
agent-browser click @e1 # Use new refs
|
||||
```
|
||||
|
||||
## Localisateurs sémantiques (alternative aux refs)
|
||||
|
||||
Lorsque les refs sont indisponibles ou peu fiables, utilise des localisateurs sémantiques :
|
||||
|
||||
```bash
|
||||
agent-browser find text "Sign In" click
|
||||
agent-browser find label "Email" fill "user@test.com"
|
||||
agent-browser find role button click --name "Submit"
|
||||
agent-browser find placeholder "Search" type "query"
|
||||
agent-browser find testid "submit-btn" click
|
||||
```
|
||||
|
||||
## Documentation approfondie
|
||||
|
||||
| Référence | Quand l’utiliser |
|
||||
|-----------|------------------|
|
||||
| [references/commands.md](references/commands.md) | Référence complète des commandes avec toutes les options |
|
||||
| [references/snapshot-refs.md](references/snapshot-refs.md) | Cycle de vie des refs, règles d’invalidation, dépannage |
|
||||
| [references/session-management.md](references/session-management.md) | Sessions parallèles, persistance d’état, scraping concurrent |
|
||||
| [references/authentication.md](references/authentication.md) | Flows de login, OAuth, gestion 2FA, réutilisation d’état |
|
||||
| [references/video-recording.md](references/video-recording.md) | Workflows d’enregistrement pour débogage et documentation |
|
||||
| [references/proxy-support.md](references/proxy-support.md) | Configuration proxy, tests géographiques, rotation de proxies |
|
||||
|
||||
## Templates prêts à l’emploi
|
||||
|
||||
| Template | Description |
|
||||
|----------|-------------|
|
||||
| [templates/form-automation.sh](templates/form-automation.sh) | Remplissage de formulaire avec validation |
|
||||
| [templates/authenticated-session.sh](templates/authenticated-session.sh) | Connexion une fois, réutilisation de l’état |
|
||||
| [templates/capture-workflow.sh](templates/capture-workflow.sh) | Extraction de contenu avec captures d’écran |
|
||||
|
||||
```bash
|
||||
./templates/form-automation.sh https://example.com/form
|
||||
./templates/authenticated-session.sh https://app.example.com/login
|
||||
./templates/capture-workflow.sh https://example.com ./output
|
||||
```
|
||||
@@ -0,0 +1,89 @@
|
||||
---
|
||||
name: presentation-structure
|
||||
description: Connaissance du format des slides de présentation, du système de niveaux, de la navigation et de la structure des sections
|
||||
---
|
||||
|
||||
# Skill Presentation Structure
|
||||
|
||||
Connaissance de la façon dont la présentation dans `presentation/index.html` est structurée.
|
||||
|
||||
## Emplacement du fichier
|
||||
|
||||
`presentation/index.html` — une présentation HTML mono-fichier avec CSS et JS inline.
|
||||
|
||||
## Format des slides
|
||||
|
||||
Chaque slide est un div avec `data-slide` (numéro séquentiel) et éventuellement `data-level` (niveau de journey aux points de transition) :
|
||||
|
||||
```html
|
||||
<!-- Regular slide — inherits level from previous data-level slide -->
|
||||
<div class="slide" data-slide="12">
|
||||
<h1>Slide Title</h1>
|
||||
<!-- content -->
|
||||
</div>
|
||||
|
||||
<!-- Level transition slide — sets new level for this slide and all following -->
|
||||
<div class="slide section-slide" data-slide="10" data-level="low">
|
||||
<h1>Section Name</h1>
|
||||
<p class="section-desc">Level: Low — description of this section</p>
|
||||
</div>
|
||||
|
||||
<!-- Title slide (centered) -->
|
||||
<div class="slide title-slide" data-slide="1">
|
||||
<h1>Presentation Title</h1>
|
||||
<p class="subtitle">Subtitle text</p>
|
||||
</div>
|
||||
```
|
||||
|
||||
## Système de niveaux de la Journey Bar
|
||||
|
||||
La présentation utilise un système à 4 niveaux au lieu de pourcentages cumulés :
|
||||
|
||||
- Les niveaux sont définis via l'attribut `data-level` sur les slides de transition clés (section dividers)
|
||||
- Toutes les slides après une slide `data-level` héritent de ce niveau jusqu'à la transition suivante
|
||||
- La journey bar se remplit à 25% / 50% / 75% / 100% pour Low / Medium / High / Pro
|
||||
- La barre est masquée sur la slide 1 (title slide) ; à partir de la slide 2, elle est affichée
|
||||
- Les slides avant le premier `data-level` (slides 2–9) affichent une barre vide (aucun niveau encore défini)
|
||||
- Un `.level-badge` est injecté par JS sur le `<h1>` des slides portant `data-level` — ne le code PAS en dur dans le HTML
|
||||
|
||||
### Transitions de niveaux par section
|
||||
|
||||
| Section | Plage de slides | data-level | Hauteur de barre |
|
||||
|---------|-----------------|------------|------------------|
|
||||
| Part 0: Introduction | Slides 1-4 | (aucun) | masquée / vide |
|
||||
| Part 1: Prerequisites | Slides 5-9 | (aucun) | vide |
|
||||
| Part 2: Better Prompting | Slides 10-17 | `low` | 25% |
|
||||
| Part 3: Project Memory | Slides 18-24 | `medium` | 50% |
|
||||
| Part 4: Structured Workflows | Slides 25-28 | (hérite medium) | 50% |
|
||||
| Part 5: Domain Knowledge | Slides 29-33 | `high` | 75% |
|
||||
| Part 6: Agentic Engineering | Slides 34-46 | `high` | 75% |
|
||||
| Appendix | Slides 47+ | (hérite high) | 75% |
|
||||
|
||||
## Système de navigation
|
||||
|
||||
- `goToSlide(n)` — utilisé dans les liens de TOC, doit correspondre aux vrais numéros `data-slide`
|
||||
- `totalSlides` est auto-calculé depuis le DOM (`document.querySelectorAll('[data-slide]').length`)
|
||||
- Touches fléchées, Space et swipe tactile pour la navigation
|
||||
- Le compteur affiche `current / total` en bas à gauche
|
||||
|
||||
## Règles de renumérotation
|
||||
|
||||
Après ajout, suppression ou réordonnancement de slides :
|
||||
1. Renuméroter TOUS les attributs `data-slide` séquentiellement à partir de 1
|
||||
2. Mettre à jour tous les appels `goToSlide()` dans la slide TOC/Journey Map
|
||||
3. Le JS `totalSlides` s'auto-calcule — aucune mise à jour manuelle nécessaire
|
||||
4. Vérifier qu'il n'y a ni trou ni doublon
|
||||
|
||||
## Format des section dividers
|
||||
|
||||
Les section dividers utilisent la classe `section-slide`. Les section dividers de transition de niveau portent `data-level` et affichent le nom du niveau dans la description :
|
||||
|
||||
```html
|
||||
<div class="slide section-slide" data-slide="10" data-level="low">
|
||||
<p class="section-number">Part 2</p>
|
||||
<h1>Better Prompting</h1>
|
||||
<p class="section-desc">Level: Low — effective prompting for real results.</p>
|
||||
</div>
|
||||
```
|
||||
|
||||
Le JS injectera un `.level-badge` (par ex. "→ Low") dans le `<h1>` au runtime quand le niveau change — ne l'ajoute pas manuellement en HTML.
|
||||
@@ -0,0 +1,106 @@
|
||||
---
|
||||
name: presentation-styling
|
||||
description: Connaissance des classes CSS, patterns de composants et coloration syntaxique dans la présentation
|
||||
---
|
||||
|
||||
# Skill Presentation Styling
|
||||
|
||||
Classes CSS et patterns HTML utilisés dans `presentation/index.html`.
|
||||
|
||||
## Classes de composants CSS
|
||||
|
||||
### Layout
|
||||
|
||||
- `.two-col` — layout grille 2 colonnes avec gap de 24px
|
||||
- `.info-grid` — grille 2 colonnes pour cartes d'information
|
||||
- `.col-card` — carte dans une colonne (ajouter `.good` pour bordure verte, `.bad` pour bordure rouge)
|
||||
- `.info-card` — carte dans une grille d'information
|
||||
|
||||
### Blocs de contenu
|
||||
|
||||
- `.trigger-box` — boîte grise avec bordure gauche sombre (concepts clés, prérequis)
|
||||
- `.how-to-trigger` — boîte verte avec bordure verte (actions "Try This")
|
||||
- `.warning-box` — boîte orange avec bordure d'avertissement (avertissements importants)
|
||||
- `.code-block` — bloc sombre d'affichage de code avec police monospace
|
||||
|
||||
### Listes
|
||||
|
||||
- `.use-cases` — conteneur pour items liste icône+texte
|
||||
- `.use-case-item` — item individuel avec icône et texte
|
||||
- `.feature-list` — liste bordée simple
|
||||
|
||||
### Tags & badges
|
||||
|
||||
- `.matcher-tag` — tag inline gris en forme de pill
|
||||
- `.weight-badge` — badge pill vert (auto-injecté par JS pour les slides pondérées)
|
||||
|
||||
## Coloration syntaxique des blocs de code
|
||||
|
||||
Dans `.code-block`, utilise ces spans pour les couleurs de syntaxe :
|
||||
|
||||
```html
|
||||
<div class="code-block">
|
||||
<span class="comment"># This is a comment</span>
|
||||
<span class="key">field_name</span>: <span class="string">value</span>
|
||||
<span class="cmd">></span> command to run
|
||||
</div>
|
||||
```
|
||||
|
||||
- `.comment` — vert (#6a9955) pour commentaires
|
||||
- `.key` — bleu (#9cdcfe) pour noms de propriétés/clés
|
||||
- `.string` — orange (#ce9178) pour valeurs string
|
||||
- `.cmd` — jaune (#dcdcaa) pour commandes/prompts
|
||||
|
||||
## Patterns de types de slides
|
||||
|
||||
### Slide de contenu avec deux colonnes (Good vs Bad)
|
||||
```html
|
||||
<div class="slide" data-slide="N" data-weight="5">
|
||||
<h1>Title</h1>
|
||||
<div class="two-col">
|
||||
<div class="col-card bad">
|
||||
<h4>Before (Vibe Coding)</h4>
|
||||
<!-- bad example -->
|
||||
</div>
|
||||
<div class="col-card good">
|
||||
<h4>After (Agentic)</h4>
|
||||
<!-- good example -->
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
```
|
||||
|
||||
Ne code pas en dur `<span class="weight-badge">` dans le HTML de la slide. Le JavaScript de présentation injecte et retire automatiquement les weight badges.
|
||||
|
||||
### Slide de contenu avec exemple de code
|
||||
```html
|
||||
<div class="slide" data-slide="N">
|
||||
<h1>Title</h1>
|
||||
<div class="trigger-box">
|
||||
<h4>Key Concept</h4>
|
||||
<p>Description</p>
|
||||
</div>
|
||||
<div class="code-block"><span class="comment"># Example</span>
|
||||
<span class="key">field</span>: <span class="string">value</span></div>
|
||||
</div>
|
||||
```
|
||||
|
||||
### Pattern de liste avec icônes
|
||||
```html
|
||||
<div class="use-cases">
|
||||
<div class="use-case-item">
|
||||
<span class="use-case-icon">EMOJI</span>
|
||||
<div class="use-case-text">
|
||||
<strong>Title</strong>
|
||||
<span>Description text</span>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
```
|
||||
|
||||
## Spécifique Journey Bar
|
||||
|
||||
- `.journey-bar` — barre fixe sous la progress bar
|
||||
- `.journey-bar.hidden` — masquée sur la title slide
|
||||
- La couleur de la journey bar transite du rouge (0%) au vert (100%) via interpolation HSL
|
||||
- Les weight badges sont auto-injectés par JS dans les éléments `h1` des slides pondérées
|
||||
@@ -0,0 +1,170 @@
|
||||
---
|
||||
name: vibe-to-agentic-framework
|
||||
description: Le cadre conceptuel derrière la présentation — ce que signifie "Vibe Coding to Agentic Engineering", pourquoi le parcours est structuré ainsi, et comment chaque slide s'inscrit dans l'arc narratif
|
||||
---
|
||||
|
||||
# Le framework "Vibe Coding to Agentic Engineering"
|
||||
|
||||
Ce skill enseigne le **modèle conceptuel** derrière la présentation. Chaque slide et section existe pour raconter une seule histoire : comment un développeur passe progressivement du "vibe coding" non structuré (niveau Low) à l'agentic engineering de haut niveau (niveau High).
|
||||
|
||||
## Concept central
|
||||
|
||||
**Vibe Coding (niveau Low)**, c'est quand un développeur utilise Claude Code sans structure — pas de contexte projet, pas de conventions, pas de connaissance réutilisable. Chaque prompt est un tirage à pile ou face. Claude peut créer des endpoints aléatoires, ignorer les patterns existants, sauter les tests et produire du code incohérent. La codebase dérive vers l'entropie à chaque interaction.
|
||||
|
||||
**Agentic Engineering (niveau High)**, c'est quand Claude Code fonctionne comme un système d'ingénierie entièrement configuré. Il connaît l'architecture projet (CLAUDE.md), suit des conventions scopées (Rules), charge l'expertise de domaine à la demande (Skills), délègue à des travailleurs spécialisés (Agents), orchestre des workflows multi-étapes (Commands), automatise les événements de cycle de vie (Hooks) et se connecte aux outils externes (MCP Servers). Chaque prompt produit du code cohérent, testé et de qualité production.
|
||||
|
||||
Le trajet entre ces deux extrêmes est **incrémental et cumulatif**. Chaque bonne pratique construit sur les précédentes, et la présentation les enseigne dans l'ordre où un développeur devrait les adopter.
|
||||
|
||||
## Le système de parcours à 4 niveaux
|
||||
|
||||
La présentation utilise un système de scoring à 4 niveaux au lieu d'une barre de pourcentage :
|
||||
|
||||
| Niveau | Ordre | Couleur | Hauteur Journey Bar | Description |
|
||||
|--------|-------|---------|---------------------|-------------|
|
||||
| Low | 1 | Rouge/orange (`hsl(0, 70%, 45%)`) | 25% | Territoire vibe coding — aucune structure |
|
||||
| Medium | 2 | Jaune (`hsl(40, 70%, 45%)`) | 50% | Workflows structurés, un peu d'automatisation |
|
||||
| High | 3 | Vert clair (`hsl(80, 70%, 45%)`) | 75% | Connaissance de domaine, skills, agents custom |
|
||||
| Pro | 4 | Vert profond (`hsl(120, 70%, 45%)`) | 100% | Agentic engineering complet, équipes multi-agents |
|
||||
|
||||
La journey bar est masquée sur la slide 1 (title slide) et apparaît à partir de la slide 2. Les niveaux sont définis via les attributs `data-level` sur les slides de transition clés et hérités par les slides suivantes jusqu'au changement de niveau suivant. Un `.level-badge` est injecté par JS sur le `h1` de la slide quand le niveau change (ne pas le coder en dur dans le HTML).
|
||||
|
||||
## L'exemple fil rouge : monorepo TodoApp
|
||||
|
||||
Chaque technique est démontrée sur un projet full-stack réaliste. La présentation montre la transformation d'un projet nu (vibe coding) vers un projet avec configuration Claude Code complète (agentic engineering) :
|
||||
|
||||
**Avant (Vibe Coding) :**
|
||||
```
|
||||
todoapp/
|
||||
├── backend/ # FastAPI (Python)
|
||||
│ ├── main.py
|
||||
│ ├── routes/
|
||||
│ ├── models/
|
||||
│ └── tests/
|
||||
└── frontend/ # Next.js (TypeScript)
|
||||
├── components/
|
||||
├── pages/
|
||||
└── lib/
|
||||
```
|
||||
|
||||
**Après (Agentic Engineering) :**
|
||||
```
|
||||
todoapp/
|
||||
├── .claude/ # Claude Code config
|
||||
│ ├── agents/ # Custom subagents
|
||||
│ ├── skills/ # Domain knowledge
|
||||
│ ├── commands/ # Slash commands
|
||||
│ ├── hooks/ # Lifecycle scripts
|
||||
│ ├── rules/ # Modular instructions
|
||||
│ ├── settings.json # Team settings
|
||||
│ └── settings.local.json # Personal settings
|
||||
├── backend/
|
||||
│ └── CLAUDE.md # Backend instructions
|
||||
├── frontend/
|
||||
│ └── CLAUDE.md # Frontend instructions
|
||||
├── .mcp.json # Managed MCP servers
|
||||
└── CLAUDE.md # Project instructions
|
||||
```
|
||||
|
||||
**Pourquoi TodoApp ?** C'est assez petit pour tenir sur des slides, mais assez complexe pour démontrer de vrais problèmes : un backend avec patterns de routes et conventions de tests, un frontend avec hiérarchie de composants et tokens de design, et une structure monorepo où les sujets transverses (comme ajouter une nouvelle fonctionnalité) exigent une coordination des deux côtés.
|
||||
|
||||
TodoApp rend concret le problème du vibe coding : sans structure, demander à Claude "add a notes feature" produit un endpoint `/api/notes` aléatoire qui ne suit pas les patterns `routes/todos.py`, une page autonome sans navigation sidebar, et zéro test. Avec un setup agentique complet, la même demande produit une route suivant les patterns existants, une page intégrée à la sidebar, et des tests alignés avec le style `test_todos.py`.
|
||||
|
||||
## L'arc du parcours : pourquoi cet ordre
|
||||
|
||||
La présentation suit une séquence pédagogique délibérée. Chaque section déverrouille une nouvelle couche de capacité :
|
||||
|
||||
### Part 0: Introduction (Slides 1–4, no weight)
|
||||
**Objectif :** poser le cadre. Introduire TodoApp, définir vibe coding et montrer la destination.
|
||||
- Title slide établit la métaphore du parcours
|
||||
- Example Project montre la transformation : comparaison avant/après de TodoApp — structure projet nue vs structure avec configuration Claude Code complète (.claude/, CLAUDE.md, .mcp.json, etc.)
|
||||
- "What is Vibe Coding?" crée la baseline 0% — le point de douleur
|
||||
- Journey Map fournit une TOC cliquable montrant tout le chemin à venir
|
||||
|
||||
### Part 1: Prerequisites (Slides 5–9, no weight)
|
||||
**Objectif :** installer Claude Code et le faire tourner. C'est purement logistique — pas encore de pratiques d'ingénierie.
|
||||
- Installation, authentification, première session, aperçu d'interface
|
||||
- Pas de poids, parce que savoir installer un outil n'améliore pas la qualité du code
|
||||
- La "first session" EST du vibe coding — c'est intentionnel, pour que le développeur fasse l'expérience directe de l'état 0%
|
||||
|
||||
### Part 2: Better Prompting (Slides 10–17, Level: Low)
|
||||
**Objectif :** première vraie amélioration. De meilleurs inputs produisent de meilleurs outputs, même sans configuration projet.
|
||||
- **Good vs Bad Prompts :** prompts spécifiques et scopés vs demandes vagues. L'amélioration la plus simple possible.
|
||||
- **Providing Context :** utiliser `@files` pour donner à Claude le code dont il a besoin. Réduit immédiatement les hallucinations.
|
||||
- **Context Window & /compact :** comprendre la fenêtre de contexte finie évite les réponses dégradées dans les longues sessions.
|
||||
- **Plan Mode :** `/plan` force la réflexion avant le code. Évite l'effort gaspillé sur de mauvaises approches.
|
||||
|
||||
**Pourquoi niveau Low :** le prompting est fondamental mais limité. Il améliore les interactions individuelles, mais ne crée pas de connaissance projet durable. Chaque session repart de zéro.
|
||||
|
||||
### Part 3: Project Memory (Slides 18–24, Level: Medium)
|
||||
**Objectif :** le saut de la connaissance de session vers la connaissance projet. Claude se souvient maintenant entre les sessions.
|
||||
- **CLAUDE.md & /init :** le "README pour Claude" du projet. Établit architecture, stack technique et conventions. C'est le fichier le plus impactant.
|
||||
- **What to Include :** conseils pratiques pour écrire un contenu CLAUDE.md efficace (moins de 150 lignes, focus sur ce que Claude doit savoir).
|
||||
- **Rules :** conventions scopées par chemin dans `.claude/rules/`. Les règles sont un multiplicateur — elles s'appliquent automatiquement à chaque fichier correspondant, imposant la cohérence sans effort développeur. Une seule règle `backend-testing.md` garantit que chaque test suit le même pattern pour toujours.
|
||||
|
||||
**Pourquoi niveau Medium :** la mémoire projet transforme Claude d'un outil stateless en collaborateur conscient du contexte. Mais la connaissance seule ne crée pas de workflows.
|
||||
|
||||
### Part 4: Structured Workflows (Slides 25–28, Level: Medium)
|
||||
**Objectif :** approches systématiques qui évitent l'effort gaspillé et améliorent la qualité d'exécution.
|
||||
- **Task Lists :** découper le travail complexe en étapes suivables. Évite le scope drift et garantit la complétude.
|
||||
- **Model Selection :** choisir le bon modèle (Opus pour l'architecture, Sonnet pour l'implémentation, Haiku pour les tâches rapides) optimise coût et qualité.
|
||||
|
||||
**Pourquoi toujours Medium :** les workflows sont importants mais restent des concepts relativement simples. Ils construisent sur la mémoire projet de la Part 3 et l'utilisent plus systématiquement. Le passage à High arrive avec la connaissance de domaine.
|
||||
|
||||
### Part 5: Domain Knowledge (Slides 29–33, Level: High)
|
||||
**Objectif :** expertise réutilisable, à la demande. Les skills sont le pont entre mémoire statique (CLAUDE.md/Rules) et agents dynamiques.
|
||||
- **What Are Skills :** skills comme connaissance de domaine packagée que Claude charge quand c'est pertinent. Le concept de divulgation progressive.
|
||||
- **Creating Skills :** pratique : construire un skill `frontend-conventions` pour TodoApp qui enseigne tokens Tailwind, patterns de composants et intégration sidebar.
|
||||
- **Skill Frontmatter & Invocation :** détails techniques : frontmatter YAML, invocation manuelle vs auto-découverte, option `context: fork`.
|
||||
|
||||
**Pourquoi niveau High :** les skills sont le premier concept "multiplicateur" — une définition de skill améliore chaque interaction future dans son domaine. Mais les skills sont de la connaissance passive ; ils ont besoin d'agents pour devenir actifs.
|
||||
|
||||
### Part 6: Agentic Engineering (Slides 34–46, Level: High)
|
||||
**Objectif :** la destination couverte dans cette présentation. Agents autonomes et spécialisés qui se coordonnent pour construire des fonctionnalités end-to-end.
|
||||
- **What Are Agents :** le concept de sous-agents spécialisés avec outils contraints et skills préchargés.
|
||||
- **Frontend Engineer Agent :** agent concret qui utilise les conventions frontend de TodoApp, ajoute les routes à la sidebar, suit les tokens de design. La comparaison avant/après montre la transformation.
|
||||
- **Backend Engineer Agent :** agent parallèle pour le backend — suit les patterns de routes FastAPI, modèles SQLAlchemy, écrit des tests alignés avec le style existant.
|
||||
- **Commands & Orchestration :** pattern capstone : Command → Agent → Skills. Une seule commande `/add-feature` coordonne agents frontend + backend, chacun avec ses skills, pour livrer une fonctionnalité complète. C'est le sommet architectural.
|
||||
- **Hooks & MCP :** automatisation de cycle de vie (pre-commit checks, notifications sonores) et intégration d'outils externes. La couche finale d'automatisation.
|
||||
- **Command → Agent → Skills :** diagramme d'architecture complet. Montre comment tout se connecte : les commandes invoquent les agents, les agents chargent les skills, les skills fournissent la connaissance. C'est la slide de compréhension "High level".
|
||||
|
||||
**Pourquoi niveau High :** cette section couvre les pratiques à plus forte valeur enseignées dans cette présentation. Tout ce qui précède y mène. Orchestration et workflows agentiques représentent le plafond de ce cours — le Pro complet (équipes multi-agents, patterns d'orchestration avancés) est hors périmètre de cette présentation.
|
||||
|
||||
### La slide High Level (Slide 44)
|
||||
Le moment de célébration. Montre la configuration complète de TodoApp :
|
||||
- CLAUDE.md pour le contexte projet
|
||||
- Rules pour conventions scopées par chemin
|
||||
- Skills pour connaissance de domaine
|
||||
- Agents pour exécution cohérente
|
||||
- Commands pour workflows orchestrés
|
||||
- Hooks pour automatisation de cycle de vie
|
||||
- Serveurs MCP pour outils externes
|
||||
|
||||
### Appendix (Slides 47+, no weight)
|
||||
**Objectif :** matériel de référence. Chaque commande, paramètre et option de configuration. Pas de poids car ce sont des lookup de référence, pas des jalons du parcours. Inclut : usage des outils, toutes les commandes slash, workflows commit/PR, options de personnalisation, astuces de débogage et règles d'or.
|
||||
|
||||
## Comment utiliser ce framework lors de l'édition des slides
|
||||
|
||||
Quand tu crées ou modifies des slides, considère :
|
||||
|
||||
1. **Où ce concept se situe-t-il dans le parcours ?** Une slide sur "meilleurs messages d'erreur dans les prompts" appartient à la Part 2 (prompting, niveau Low). Une slide sur "agent memory scopes" appartient à la Part 6 (agentic, niveau High).
|
||||
|
||||
2. **Quel est l'avant/après ?** Chaque slide significative doit montrer implicitement ou explicitement le contraste : ce qui se passe au niveau Low (vibe coding) vs avec cette technique. Utilise TodoApp pour rendre ça concret.
|
||||
|
||||
3. **L'assignation de niveau est-elle juste ?** Les transitions de niveau ont lieu aux frontières de sections Part. Les slides individuelles dans une section héritent du niveau de section.
|
||||
|
||||
4. **Est-ce que ça construit sur ce qui précède ?** Les Skills supposent que le développeur connaît déjà CLAUDE.md et Rules. Les Agents supposent qu'il connaît les Skills. Les Commands supposent qu'il connaît les Agents. Ne référence jamais un concept avant sa section.
|
||||
|
||||
5. **Utilise TodoApp.** Les explications abstraites perdent l'audience. Montre le vrai code `routes/todos.py`, le vrai composant `Sidebar.tsx`, le vrai contenu `CLAUDE.md`. L'exemple fil rouge est ce qui rend le framework tangible.
|
||||
|
||||
## Tableau de référence des transitions de niveau
|
||||
|
||||
| Slide | Nom de slide | data-level | Label de niveau |
|
||||
|-------|--------------|------------|-----------------|
|
||||
| 10 | Better Prompting (section divider) | `data-level="low"` | Low |
|
||||
| 18 | Project Memory (section divider) | `data-level="medium"` | Medium |
|
||||
| 29 | Domain Knowledge (section divider) | `data-level="high"` | High |
|
||||
| 34 | Agentic Engineering (section divider) | `data-level="high"` | High |
|
||||
|
||||
Toutes les autres slides héritent du niveau du dernier attribut `data-level` défini avant elles. Les slides 1–9 (Intro + Prerequisites) n'ont pas de niveau et gardent la barre masquée jusqu'à la slide 2, qui affiche "Low" (les slides 2–9 sont avant la première transition de niveau à la slide 10, donc la barre reste vide/zéro jusqu'à la slide 10).
|
||||
|
||||
**Note :** la présentation principale (`presentation/index.html`) plafonne au niveau **High** — `data-level="pro"` n'est pas utilisé. Le tick Pro reste visible sur la journey bar comme plafond théorique, mais le remplissage ne l'atteint jamais. La présentation vidéo (`1-video-workflow.html`) plafonne au niveau **Medium**.
|
||||
@@ -0,0 +1,32 @@
|
||||
---
|
||||
name: time-skill
|
||||
description: Afficher l'heure actuelle en Pakistan Standard Time (PKT, UTC+5). Utiliser quand l'utilisateur demande l'heure actuelle, l'heure au Pakistan ou PKT.
|
||||
user-invocable: true
|
||||
---
|
||||
|
||||
# Time Skill
|
||||
|
||||
Ce skill affiche la date et l'heure actuelles en Pakistan Standard Time (PKT).
|
||||
|
||||
## Tâche
|
||||
|
||||
Afficher la date et l'heure actuelles en Pakistan Standard Time (UTC+5).
|
||||
|
||||
## Instructions
|
||||
|
||||
1. **Obtenir l'heure actuelle** : lance la commande bash suivante :
|
||||
```
|
||||
TZ='Asia/Karachi' date '+%Y-%m-%d %H:%M:%S %Z'
|
||||
```
|
||||
|
||||
2. **Afficher le résultat** : montre l'heure dans ce format :
|
||||
```
|
||||
Current Time in Pakistan (PKT): YYYY-MM-DD HH:MM:SS PKT
|
||||
```
|
||||
|
||||
## Exigences
|
||||
|
||||
- Toujours utiliser la timezone `Asia/Karachi` (UTC+5)
|
||||
- Utiliser le format 24 heures
|
||||
- Inclure la date avec l'heure
|
||||
- Garder la sortie concise — aucun commentaire supplémentaire
|
||||
@@ -0,0 +1,47 @@
|
||||
---
|
||||
name: weather-fetcher
|
||||
description: Instructions pour récupérer les données de température météo actuelle de Dubaï, UAE, depuis l'API Open-Meteo
|
||||
user-invocable: false
|
||||
allowed-tools:
|
||||
- "WebFetch(*)"
|
||||
---
|
||||
|
||||
# Skill Weather Fetcher
|
||||
|
||||
Ce skill fournit les instructions pour récupérer les données météo actuelles.
|
||||
|
||||
## Tâche
|
||||
|
||||
Récupérer la température actuelle pour Dubaï, UAE, dans l'unité demandée (Celsius ou Fahrenheit).
|
||||
|
||||
## Instructions
|
||||
|
||||
1. **Récupérer les données météo** : utilise l'outil WebFetch pour obtenir les données météo actuelles de Dubaï depuis l'API Open-Meteo.
|
||||
|
||||
Pour **Celsius** :
|
||||
- URL : `https://api.open-meteo.com/v1/forecast?latitude=25.2048&longitude=55.2708¤t=temperature_2m&temperature_unit=celsius`
|
||||
|
||||
Pour **Fahrenheit** :
|
||||
- URL : `https://api.open-meteo.com/v1/forecast?latitude=25.2048&longitude=55.2708¤t=temperature_2m&temperature_unit=fahrenheit`
|
||||
|
||||
2. **Extraire la température** : depuis la réponse JSON, extraire la température actuelle :
|
||||
- Champ : `current.temperature_2m`
|
||||
- Le label d'unité est dans : `current_units.temperature_2m`
|
||||
|
||||
3. **Retourner le résultat** : retourne clairement la valeur de température et l'unité.
|
||||
|
||||
## Sortie attendue
|
||||
|
||||
Après avoir exécuté les instructions de ce skill :
|
||||
```
|
||||
Current Dubai Temperature: [X]°[C/F]
|
||||
Unit: [Celsius/Fahrenheit]
|
||||
```
|
||||
|
||||
## Notes
|
||||
|
||||
- Récupérer seulement la température, ne faire aucune transformation et n'écrire aucun fichier
|
||||
- Open-Meteo est gratuit, ne requiert aucune clé API et utilise des recherches par coordonnées pour la fiabilité
|
||||
- Coordonnées de Dubaï : latitude 25.2048, longitude 55.2708
|
||||
- Retourner clairement la valeur numérique de température et l'unité
|
||||
- Supporter Celsius et Fahrenheit selon la demande de l'appelant
|
||||
@@ -0,0 +1,29 @@
|
||||
---
|
||||
name: weather-svg-creator
|
||||
description: Crée une carte météo SVG affichant la température actuelle de Dubaï. Écrit le SVG dans orchestration-workflow/weather.svg et met à jour orchestration-workflow/output.md.
|
||||
---
|
||||
|
||||
# Skill Weather SVG Creator
|
||||
|
||||
Crée une carte météo SVG visuelle pour Dubaï, UAE, et écrit les fichiers de sortie.
|
||||
|
||||
## Tâche
|
||||
|
||||
Tu recevras une valeur de température et une unité (Celsius ou Fahrenheit) depuis le contexte appelant. Crée une carte météo SVG et écris à la fois le SVG et un résumé Markdown.
|
||||
|
||||
## Instructions
|
||||
|
||||
1. **Créer le SVG** — utilise le template SVG de [reference.md](reference.md), en remplaçant les placeholders par les valeurs réelles
|
||||
2. **Écrire le fichier SVG** — lis puis écris dans `orchestration-workflow/weather.svg`
|
||||
3. **Écrire le résumé** — lis puis écris dans `orchestration-workflow/output.md` avec le template Markdown de [reference.md](reference.md)
|
||||
|
||||
## Règles
|
||||
|
||||
- Utilise la valeur de température et l'unité exactes fournies — ne re-fetch pas et ne modifie pas
|
||||
- Le SVG doit être autonome et valide
|
||||
- Les deux fichiers de sortie vont dans le répertoire `orchestration-workflow/`
|
||||
|
||||
## Ressources additionnelles
|
||||
|
||||
- Pour le template SVG, le template de sortie et les specs de design, voir [reference.md](reference.md)
|
||||
- Pour les paires exemple entrée/sortie, voir [examples.md](examples.md)
|
||||
@@ -0,0 +1,79 @@
|
||||
# Weather SVG Creator — Exemples
|
||||
|
||||
## Exemple 1 : Celsius
|
||||
|
||||
### Entrée
|
||||
|
||||
```
|
||||
Temperature: 26.2°C
|
||||
Unit: Celsius
|
||||
```
|
||||
|
||||
### Sortie SVG (`orchestration-workflow/weather.svg`)
|
||||
|
||||
```svg
|
||||
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 300 160" width="300" height="160">
|
||||
<rect width="300" height="160" rx="12" fill="#1a1a2e"/>
|
||||
<text x="150" y="45" text-anchor="middle" fill="#8892b0" font-family="system-ui" font-size="14">Unit: Celsius</text>
|
||||
<text x="150" y="100" text-anchor="middle" fill="#ccd6f6" font-family="system-ui" font-size="42" font-weight="bold">26.2°C</text>
|
||||
<text x="150" y="140" text-anchor="middle" fill="#64ffda" font-family="system-ui" font-size="16">Dubai, UAE</text>
|
||||
</svg>
|
||||
```
|
||||
|
||||
### Sortie Markdown (`orchestration-workflow/output.md`)
|
||||
|
||||
```markdown
|
||||
# Weather Result
|
||||
|
||||
## Temperature
|
||||
26.2°C
|
||||
|
||||
## Location
|
||||
Dubai, UAE
|
||||
|
||||
## Unit
|
||||
Celsius
|
||||
|
||||
## SVG Card
|
||||
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Exemple 2 : Fahrenheit
|
||||
|
||||
### Entrée
|
||||
|
||||
```
|
||||
Temperature: 79.2°F
|
||||
Unit: Fahrenheit
|
||||
```
|
||||
|
||||
### Sortie SVG (`orchestration-workflow/weather.svg`)
|
||||
|
||||
```svg
|
||||
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 300 160" width="300" height="160">
|
||||
<rect width="300" height="160" rx="12" fill="#1a1a2e"/>
|
||||
<text x="150" y="45" text-anchor="middle" fill="#8892b0" font-family="system-ui" font-size="14">Unit: Fahrenheit</text>
|
||||
<text x="150" y="100" text-anchor="middle" fill="#ccd6f6" font-family="system-ui" font-size="42" font-weight="bold">79.2°F</text>
|
||||
<text x="150" y="140" text-anchor="middle" fill="#64ffda" font-family="system-ui" font-size="16">Dubai, UAE</text>
|
||||
</svg>
|
||||
```
|
||||
|
||||
### Sortie Markdown (`orchestration-workflow/output.md`)
|
||||
|
||||
```markdown
|
||||
# Weather Result
|
||||
|
||||
## Temperature
|
||||
79.2°F
|
||||
|
||||
## Location
|
||||
Dubai, UAE
|
||||
|
||||
## Unit
|
||||
Fahrenheit
|
||||
|
||||
## SVG Card
|
||||
|
||||
```
|
||||
@@ -0,0 +1,62 @@
|
||||
# Weather SVG Creator — Référence
|
||||
|
||||
## Template SVG
|
||||
|
||||
```svg
|
||||
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 300 160" width="300" height="160">
|
||||
<rect width="300" height="160" rx="12" fill="#1a1a2e"/>
|
||||
<text x="150" y="45" text-anchor="middle" fill="#8892b0" font-family="system-ui" font-size="14">Unit: [Celsius/Fahrenheit]</text>
|
||||
<text x="150" y="100" text-anchor="middle" fill="#ccd6f6" font-family="system-ui" font-size="42" font-weight="bold">[value]°[C/F]</text>
|
||||
<text x="150" y="140" text-anchor="middle" fill="#64ffda" font-family="system-ui" font-size="16">Dubai, UAE</text>
|
||||
</svg>
|
||||
```
|
||||
|
||||
### Placeholders
|
||||
|
||||
| Placeholder | Remplacer par | Exemple |
|
||||
|-------------|---------------|---------|
|
||||
| `[Celsius/Fahrenheit]` | Nom complet de l'unité depuis l'entrée | `Celsius` |
|
||||
| `[value]` | Température numérique depuis l'entrée | `26.2` |
|
||||
| `[C/F]` | Abréviation de l'unité | `C` ou `F` |
|
||||
|
||||
### Specs de design
|
||||
|
||||
| Propriété | Valeur |
|
||||
|-----------|--------|
|
||||
| Dimensions | 300 x 160 px |
|
||||
| Rayon des coins | 12 px |
|
||||
| Arrière-plan | `#1a1a2e` (dark navy) |
|
||||
| Label d'unité | `#8892b0` (bleu atténué), 14px |
|
||||
| Température | `#ccd6f6` (bleu clair), 42px bold |
|
||||
| Lieu | `#64ffda` (accent teal), 16px |
|
||||
| Police | `system-ui` |
|
||||
| Tout le texte | Centré (`text-anchor="middle"` à x=150) |
|
||||
|
||||
---
|
||||
|
||||
## Template Markdown de sortie
|
||||
|
||||
```markdown
|
||||
# Weather Result
|
||||
|
||||
## Temperature
|
||||
[value]°[C/F]
|
||||
|
||||
## Location
|
||||
Dubai, UAE
|
||||
|
||||
## Unit
|
||||
[Celsius/Fahrenheit]
|
||||
|
||||
## SVG Card
|
||||
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Chemins de sortie
|
||||
|
||||
| Fichier | Chemin |
|
||||
|---------|--------|
|
||||
| Carte SVG | `orchestration-workflow/weather.svg` |
|
||||
| Résumé Markdown | `orchestration-workflow/output.md` |
|
||||
Reference in New Issue
Block a user