De la trace au skill
Trace2Skill : lance un agent 20 fois, loggue ce qui a marché, laisse quatre analystes Claude lire les traces, et fusionne-les dans un SKILL.md qui surpasse les versions écrites à la main.
Arrêtez de configurer. Commencez à construire.
Templates SaaS avec orchestration IA.
Chaque skill que tu télécharges a été écrit par une IA qui n'a jamais exécuté ta tâche. Elle a deviné. Parfois c'est bien. Quand ta tâche a des modes d'échec spécifiques, deviner ne suffit pas.
La meilleure approche : lance ton agent 20 fois, dis-lui ce qui était bien et ce qui ne l'était pas, et laisse-le extraire les règles lui-même.
C'est tout. C'est toute l'idée.
C'est basé sur Trace2Skill, un article de recherche de l'équipe Qwen d'Alibaba. Ils ont montré que les skills construits à partir de vraies traces d'exécution battent constamment ceux écrits par des humains sur des benchmarks difficiles, et se transfèrent à travers les tailles de modèles.
Les 4 étapes
lancer 20 fois → écrire ton feedback → 4 analystes lisent tout ensemble → fusionner dans SKILL.mdÉtape 1 : lancer ton agent 20 fois
D'abord, génère 20 variations de ta tâche — des faciles, des difficiles, des cas limites. Utilise Claude pour les écrire :
Generate 20 variations of this task for a Claude Code agent:
Task: [your task]
- 5 easy, straightforward versions
- 8 normal versions
- 4 hard versions with tricky edge cases
- 3 adversarial versions designed to break the agent
Output: a numbered list. Each item is a complete, self-contained task prompt.Puis lance-les :
claude -p "[variation 1]"
claude -p "[variation 2]"
# repeat for all 20Claude Code sauvegarde chaque session automatiquement dans ~/.claude/projects/[your-project]/. Tu n'as rien d'autre à faire.
Étape 2 : écrire ton feedback
Regarde ce que chaque run a produit — le site qu'il a construit, le post qu'il a écrit, le code qu'il a généré. Tu n'as pas besoin de lire les logs internes. Regarde juste la sortie.
Écris une phrase par run. C'est tout ce que tu as à faire ici. Ça prend 10-15 minutes.
Run 1: good
Run 2: bad — too many cards, looks cluttered
Run 3: good
Run 4: bad — icons wrapped in colored divs, looks cheap
Run 5: good
Run 6: bad — two CTAs above the fold, confusing
...Les agents géreront le reste. Ils savent comment lire les traces internes. Toi, tu sais si la sortie était vraiment bonne. C'est la séparation.
Étape 3 : lancer 4 analystes en parallèle
Crée ces quatre fichiers dans .claude/agents/. Chacun se concentre sur un angle différent, mais les quatre lisent ensemble les 20 mêmes sessions. Les lancer en parallèle élimine le biais que tu obtiendrais d'un seul reviewer.
.claude/agents/error-analyst.md
---
name: error-analyst
description: Reads all 20 sessions and my feedback. Finds the root cause behind every bad run. Proposes rules that would have prevented each failure. Run in parallel with the other analysts.
---
You analyze why runs went wrong.
You receive:
- A task description
- My feedback on each run (one sentence per run, labeled good/bad)
- Access to the last 20 session files in ~/.claude/projects/[project]/
Process:
1. Read all 20 sessions
2. For every run I marked bad: find the root cause in the actual trace (not just the error message)
3. Check if the same problem appears in multiple bad runs
4. Propose a rule that would have prevented it
Rule format:
- RULE: [what to do, imperative]
- EVIDENCE: [run numbers]
- PRIORITY: high / medium / low
Only propose rules that show up in 2+ runs..claude/agents/success-analyst.md
---
name: success-analyst
description: Reads all 20 sessions and my feedback. Finds what the agent did right in good runs that it didn't do in bad ones. Run in parallel with the other analysts.
---
You find what made the good runs good.
You receive:
- A task description
- My feedback on each run
- Access to the last 20 session files in ~/.claude/projects/[project]/
Process:
1. Read all 20 sessions
2. For every run I marked good: find the behaviors that made it work
3. Find behaviors present in good runs that are absent in bad runs
4. Propose rules that encode those behaviors
Rule format:
- RULE: [what to do, imperative]
- EVIDENCE: [run numbers]
- PRIORITY: high / medium / low
Skip obvious rules. Look for the non-obvious things that actually made the difference..claude/agents/structure-analyst.md
---
name: structure-analyst
description: Reads all 20 sessions and my feedback. Looks at the sequence of steps taken, not the content. Finds ordering patterns that correlate with good or bad outcomes. Run in parallel with the other analysts.
---
You look at the shape of runs, not what was produced.
You receive:
- A task description
- My feedback on each run
- Access to the last 20 session files in ~/.claude/projects/[project]/
Look at tool call sequences, step ordering, verification steps, unnecessary detours.
Questions:
- Which sequences appear in good runs but not bad ones?
- Are verification steps missing from bad runs?
- Are there steps that add noise without improving the output?
Rule format:
- RULE: [ordering or sequencing rule, imperative]
- EVIDENCE: [run numbers]
- PRIORITY: high / medium / low
Only rules with 2+ run support..claude/agents/edge-analyst.md
---
name: edge-analyst
description: Reads all 20 sessions and my feedback. Focuses on the hard and adversarial runs. Finds assumptions the agent makes that break under pressure. Run in parallel with the other analysts.
---
You focus on the runs I marked bad, especially the tricky ones.
You receive:
- A task description
- My feedback on each run
- Access to the last 20 session files in ~/.claude/projects/[project]/
Find:
- What inputs broke the agent that shouldn't have?
- What assumptions does the agent make that fail at the edges?
- What checks are missing?
Write rules as guards: "Before doing X, verify Y."
Rule format:
- RULE: [defensive check or guard]
- EVIDENCE: [run numbers]
- PRIORITY: high / medium / low
Every rule must link to a specific run.Maintenant lance les quatre en même temps, en passant ton feedback et en les pointant vers tes sessions :
Run these 4 agents in parallel. Give each the same context.
Task: [your task description]
Project slug: [your-project] (sessions are in ~/.claude/projects/[your-project]/)
My feedback:
Run 1: good
Run 2: bad — too many cards, looks cluttered
Run 3: good
[... all 20]
Agents to run:
- error-analyst
- success-analyst
- structure-analyst
- edge-analyst
Each agent should read the actual session files to understand what happened in each run.Étape 4 : fusionner dans un seul SKILL.md
Tu as quatre ensembles de règles proposées. La plupart se chevauchent. Lance ça pour consolider :
Merge these 4 analyst outputs into a single SKILL.md.
Task: [your task]
Existing SKILL.md: [paste or write "none"]
[paste all 4 analyst outputs]
Rules for merging:
- Merge rules that say the same thing
- When two rules conflict, keep the one with more run evidence
- 8+ runs: core rule (goes in main SKILL.md)
- 4-7 runs: guidance (main SKILL.md, secondary section)
- 2-3 runs: edge case (goes in references/ subfolder)
- 1 run: discard
Output as a SKILL.md:
# [Task name]
## When to use this skill
[one short paragraph]
## Core rules
[numbered list]
## Patterns
[bullet points]
## Failure modes
["If X, do Y" format]
Max 30 rules in the main file.Ce que tu obtiens à la fin
.claude/
agents/
error-analyst.md
success-analyst.md
structure-analyst.md
edge-analyst.md
skills/
[your-task]/
SKILL.md
references/
edge-cases.mdUn vrai exemple tiré de ce workflow appliqué à un builder de landing pages :
# Landing Page Builder
## Core rules
1. Never wrap icons in a div with a background. Use the SVG path directly. (runs 3, 6, 11, 15)
2. One hero section, one CTA. Pages with two CTAs above the fold had lower click-through. (runs 2, 7, 9, 14, 18)
3. Limit feature sections to 3 items. Grids of 6+ cards look like AI slop and nobody reads them. (runs 4, 8, 12, 17)
## Failure modes
- If the output has a "Features" section with more than 4 cards: cut to the 3 strongest
- If there are Lucide icons inside colored background divs: replace with inline SVG paths
- If the hero has more than 2 buttons: remove the secondary oneChaque règle est liée aux runs exacts qui l'ont produite.
Pourquoi ça marche
La raison pour laquelle les skills téléchargés sous-performent est simple : l'IA qui les a écrits n'a jamais exécuté ta tâche. Elle a inventé des règles basées sur ce qu'elle pensait pouvoir compter.
Ce workflow inverse ça. Tu lances d'abord, tu juges les sorties (que tu peux vraiment voir), et tu laisses quatre agents indépendants creuser dans les traces pour comprendre pourquoi chaque run s'est passé comme ça. Les lancer en parallèle signifie qu'aucune perspective ne domine.
L'article à l'origine de ça a trouvé que l'analyse parallèle surpasse constamment les skills écrits par des humains et la revue IA séquentielle. Un modèle 35B qui fait évoluer ses propres skills de cette façon a surpassé un modèle 122B utilisant un skill écrit à la main sur certains benchmarks.
Le raccourci
Build This Now est un framework de production pour livrer des SaaS, des outils internes, et des projets clients. Paiements, auth, e-mail, frontend, backend, tout câblé ensemble et prêt à livrer.
Il est aussi livré avec un vrai harnais IA : orchestration d'agents, dispatch parallèle, évolution de skills, collecte de traces, et les patterns que les meilleurs setups Claude Code utilisent en production. Le workflow de skills ci-dessus en fait partie. Tu obtiens tout sans construire la plomberie toi-même.
Arrêtez de configurer. Commencez à construire.
Templates SaaS avec orchestration IA.