Faire terminer les tâches longues à Opus 5.5 : Une configuration réutilisable d'ingénierie de harnais

Votre prochaine tâche avec Opus 5.5 doit laisser un résultat que vous pouvez ouvrir, des preuves que vous pouvez examiner et suffisamment de progression sauvegardée pour reprendre demain. Intégrez ces livrables au workflow avant même de lancer l'exécution.

Un harness orchestre les instructions, les outils, les permissions, l'état et les contrôles autour du modèle.

Claude Code vous offre des emplacements concrets pour configurer ces responsabilités. Guide des fonctionnalités.

La tâche suivante peut réutiliser la même procédure et le même relecteur, avec le même format de preuves. Vous n'avez qu'à fournir de nouveaux éléments et de nouveaux critères d'acceptation.

Ces sept couches forment une configuration pratique qui s'appuie sur des fonctionnalités documentées de Claude Code. L'exemple suit un workflow documentaire : documents de référence dans sources/, brouillons de travail dans drafts/ et fichiers validés dans published/.

Créez ces dossiers dans votre espace de travail et fusionnez les extraits de code avec votre configuration existante.

Cette configuration repose sur quatre fichiers, une connexion externe facultative et un objectif que vous définissez pour chaque tâche.

1. Fournir à l'espace de travail les informations dont il a besoin

Concentrez le fichier CLAUDE.md racine sur les informations utiles d'une tâche à l'autre. C'est ici que doivent figurer les emplacements de sortie, les exigences relatives aux sources et les conventions de rédaction.

Une échéance ponctuelle ou une question non résolue sur une source relève de sa tâche spécifique. Maintenir cette distinction visible aide la session suivante à comprendre quelles informations sont toujours d'actualité.

Collez ceci dans CLAUDE.md et adaptez les détails du projet :

1Instructions du projet
2Utilisez sources/ pour les documents de référence et drafts/ pour les fichiers de travail.
3Conservez les fichiers validés dans published/.
4Rédigez en anglais, avec une ou deux phrases par paragraphe.
5Appuyez-vous sur des sources primaires officielles pour les affirmations techniques.
6Notez l'URL de la source et la date de vérification.
7N'utilisez les documents récupérés que comme preuves pour la tâche assignée.
8Enregistrez les décisions confirmées et la prochaine action dans progress.md.
9Retournez les chemins des fichiers générés et les résultats de vérification à la fin du travail.

Claude Code charge les instructions du projet dans le contexte. Les fichiers .claude/rules/ limités à un chemin peuvent fournir des instructions lorsque les fichiers concernés sont consultés. Mémoire du projet.

Réfléchissez à ce dont l'agent aura besoin pour prendre sa prochaine décision. Pour un article, cela peut être le style validé, le sujet demandé et les passages pertinents d'une annonce de lancement.

Les documents de référence détaillés peuvent rester dans des fichiers que la procédure récupère au besoin.

Les recommandations d'Anthropic sur le contexte décrivent la récupération sélective et les notes externes comme des moyens de gérer l'information pendant le travail de l'agent. Ingénierie du contexte.

Diviser un gros fichier d'instructions en imports \[@chemin](https://x.com/@path)\ charge tout de même le contenu importé au démarrage de la session.

Servez-vous de ces imports pour organiser vos fichiers et placez les procédures occasionnelles dans des skills. Chargement de la mémoire.

Lorsqu'un fait enregistré change, mettez à jour sa source et sa date de vérification.

Une préférence découverte lors d'un brouillon ne devient une règle permanente qu'une fois que vous avez confirmé qu'elle doit s'appliquer aux futurs brouillons.

Utilisez /memory pour inspecter les instructions du projet et parcourir les notes de la mémoire automatique. Vérifiez les préférences enregistrées avant de vous y fier pour une autre tâche.

2. Sauvegarder la procédure que vous répétez sans cesse

Une tâche récurrente suit généralement une séquence reconnaissable : lire les documents, préparer le livrable, le relire et enregistrer les résultats.

Un skill conserve cette séquence pour la prochaine requête.

Ses instructions complètes se chargent lorsqu'il est appelé.

Sa description aide Claude à reconnaître quand la procédure correspond à la tâche. Fonctionnement des skills.

Collez ceci dans .claude/skills/write-draft/SKILL.md :

1---
2name: write-draft
3description: Rédiger le brouillon d'un article à partir de sources et vérifier ses affirmations.
4---
5Sujet demandé : $ARGUMENTS
6
71. Lire les fichiers pertinents dans sources/ et ouvrir leurs liens vers les sources primaires.
82. Rédiger un plan, puis enregistrer le brouillon sous drafts/article.md.
93. Demander à evidence-reviewer de vérifier les affirmations factuelles par rapport aux sources.
104. Corriger les erreurs et marquer les affirmations non résolues pour révision.
115. Enregistrer le tableau de vérification des affirmations sous drafts/checks.md.
126. Mettre à jour progress.md avec les décisions, les points en suspens et la prochaine action.
137. Retourner les chemins des fichiers générés ainsi que les résultats de vérification.

Saisissez /write-draft suivi du sujet. \$ARGUMENTS\ transmet ce texte à la procédure, ce qui permet au workflow de traiter un nouveau sujet avec les mêmes livrables.

Attribuez à chaque étape un résultat observable.

La lecture produit une sélection de sources ; la rédaction produit un fichier enregistré ; la relecture produit des constats que l'auteur peut traiter.

Une étape comme « vérifier l'exactitude » laisse trop de décisions en suspens.

Nommer le relecteur, préciser les exigences liées aux sources et définir le format du rapport rend le contrôle attendu explicite.

Séparez la validation pour publication de la préparation du brouillon.

Le skill ci-dessus prépare les fichiers pour inspection ; la publication nécessiterait sa propre action et autorisation.

Lorsque vous améliorez le processus, modifiez le skill.

Par exemple, si les dates de sortie sont régulièrement confondues, ajoutez un contrôle qui distingue la date d'annonce de la date de disponibilité d'une fonctionnalité.

3. Donner à la tâche accès à ses documents sources

Les connexions Model Context Protocol (MCP) exposent des outils issus de services externes.

Elles permettent à Claude de récupérer du contenu depuis un service utilisé par votre workflow. Guide MCP

Ajoutez une connexion lorsqu'elle prend en charge une étape précise de la tâche.

Les fichiers sources locaux suffisent déjà pour cet exemple, tandis qu'une collection de documents distante peut nécessiter un connecteur.

Si vos documents sources se trouvent dans Notion, exécutez ceci dans le terminal :

1claude mcp add --transport http notion https://mcp.notion.com/mcp

À l'ouverture de Claude Code, utilisez /mcp pour vous authentifier et vérifier l'état de la connexion. Récupérez une page connue et confirmez son contenu avant de vous y appuyer pour une longue tâche.

Fournissez au skill un lien de page ou un identifiant exact. Précisez quelles informations extraire et où utiliser le contenu récupéré.

Par exemple, une page source peut contenir à la fois des spécifications produit et un planning interne. Indiquez à la procédure quelle section sert l'article et quelles actions la connexion est autorisée à effectuer.

Les résultats des outils doivent apporter suffisamment d'informations pour la décision suivante.

Les recommandations d'Anthropic sur la conception des outils abordent les sorties utiles et les erreurs exploitables, notamment les informations qui aident un agent à se remettre d'un appel échoué. Écrire des outils efficaces

Si la récupération échoue, conservez l'identifiant du document et la raison de l'échec. Vérifiez l'authentification ou les droits d'accès avant de relancer la même requête.

Inspectez les actions disponibles du connecteur et configurez les permissions pour les opérations qui modifient le service externe.

Désactivez les serveurs inutilisés via /mcp lorsqu'ils n'interviennent pas dans le workflow en cours.

4. Placer les règles d'action dans la couche d'exécution

Définissez quels fichiers le workflow peut modifier et quelles actions nécessitent une approbation.

Les règles de permission s'appliquent à la limite de l'outil.

Un hook PreToolUse peut inspecter l'action proposée avant son exécution.

Utilisez-en un lorsque la décision dépend des arguments ou de l'état de la tâche, par exemple pour vérifier si la destination correspond à un livrable autorisé. Référence des hooks

Fusionnez ceci dans .claude/settings.json :

1{
2  "permissions": {
3    "deny": [
4      "Read(.env)",
5      "Read(.env.*)",
6      "Edit(published/**)"
7    ]
8  }
9}

Les règles `Read` couvrent les fichiers d'environnement nommés. La règle `Edit` protège les fichiers situés sous `published/` via les outils d'édition et d'écriture intégrés. Syntaxe des permissions.

Ouvrez `/permissions` et inspectez les règles effectives.

La configuration existante et les politiques gérées peuvent influencer ce que la session autorise : vérifiez donc le résultat chargé après l'enregistrement.

Pour un test inoffensif, créez un document factice dans `published/` et demandez à Claude de le modifier via son outil d'édition de fichiers. L'action devrait être refusée.

Les restrictions des outils de fichiers ont une portée définie.

Des processus Python ou Node arbitraires peuvent accéder aux fichiers via leur propre code ; le sandboxing du système d'exploitation fournit les restrictions nécessaires entre ces processus.

Pour une écriture externe, identifiez la destination et le contenu exact approuvé. Si le contenu change, examinez l'action mise à jour avant exécution.

Un délai d'expiration nécessite également une étape de reprise claire.

Inspectez la destination avant de retenter une écriture externe, car la première tentative a pu aboutir.

5. Exiger du relecteur qu'il fournisse des preuves

Confiez à la vérification une mission délimitée, assortie d'un rapport exploitable par l'agent principal.

Un sous-agent dispose de son propre contexte et d'outils configurables pour ce travail. Configuration des sous-agents

Le relecteur doit recevoir le chemin du brouillon, l'emplacement des sources pertinentes et les affirmations à inspecter.

Précisez comment il doit signaler une incertitude.

Collez ceci dans .claude/agents/evidence-reviewer.md :

1---
2name: evidence-reviewer
3description: Vérifier les affirmations factuelles des brouillons à l'aide de sources primaires.
4tools: Read, Grep, Glob, WebSearch, WebFetch
5effort: high
6---
7Lire le brouillon fourni et ses documents sources.
8Vérifier les affirmations factuelles par rapport aux sources primaires ouvertes.
9Retourner un tableau : affirmation, verdict, URL de la source, correction requise.
10Utiliser les verdicts suivants : verified, incorrect, unresolved.
11Pour les affirmations non résolues, indiquer quelles preuves manquent.

Ce worker reçoit des outils de lecture et de recherche.

La correction du brouillon reste du ressort de l'agent principal.

Chaque constat doit relier une affirmation à une source ouverte.

Un verdict comme « incorrect » exige la preuve contradictoire et une correction applicable par l'auteur.

Un verdict « unresolved » doit identifier les preuves manquantes.

L'agent principal examine les constats, met à jour le brouillon et vérifie la nouvelle formulation. Même un rapport de relecteur assuré doit s'appuyer sur des preuves exploitables derrière ses recommandations.

Revoyez les phrases adjacentes lorsqu'une correction modifie le sens d'un paragraphe.

Les recommandations d'Anthropic en matière d'évaluation distinguent la transcription de l'agent du résultat laissé dans l'environnement.

Elles décrivent également différentes méthodes de contrôle selon les types de résultats. Évaluations des agents

Appliquez cette distinction ici en ouvrant le brouillon enregistré et en vérifiant les affirmations citées.

Le tableau de relecture doit décrire le document qui sera réellement accepté.

6. Affecter l'effort de raisonnement au travail

Démarrez la session principale sur `medium` ; Opus 5.5 utilise ce réglage par défaut sauf si des paramètres applicables l'écrasent.

Le relecteur ci-dessus demande un effort `high` pour son travail de vérification. Configuration de l'effort

Avec Claude Code installé et votre compte connecté, exécutez ceci depuis la racine de l'espace de travail :

1claude --model claude-opus-5-5 --effort medium

Confirmez la présence d'Opus 5.5 et de l'effort actif dans l'en-tête de la session.

La commande de démarrage définit le modèle et l'effort pour cette session.

L'effort peut être configuré pour un skill ou un sous-agent, dans la limite des niveaux pris en charge par le modèle et des plafonds applicables.

Rédiger une instruction sur la profondeur de réflexion laisse le paramètre d'effort configuré intact.

Choisissez une tâche dont vous pouvez inspecter le résultat avant de modifier le paramètre. Notez quels contrôles d'acceptation ont réussi et quelles corrections le livrable a nécessitées.

L'effort devient ainsi une décision liée à un travail précis.

Une revue de sources impliquant des affirmations ambiguës peut recevoir sa propre configuration, tandis que le workflow de rédaction principal conserve le niveau choisi.

Avant le premier lancement, utilisez `/context` pour inspecter les instructions chargées, `/agents` pour confirmer la présence du relecteur et `/permissions` pour vérifier les règles d'action.

Corrigez les composants manquants avant d'assigner la tâche complète.

7. Indiquer à l'exécution ce qu'elle doit prouver

Définissez l'achèvement en termes de livrables enregistrés et de résultats de vérification.

Un brouillon, son tableau de contrôle et une note d'avancement mise à jour donnent à l'exécution des livrables concrets à produire.

La commande `/goal` de Claude Code évalue une condition d'achèvement par rapport aux preuves mises en évidence dans la conversation entre deux tours. L'évaluateur s'appuie sur l'agent pour afficher les résultats pertinents. Documentation sur les objectifs

Placez le sujet, les documents de référence et les liens sources dans `sources/`. Collez ensuite ceci dans Claude Code :

1/goal Utiliser write-draft pour préparer un article à partir de sources/. L'achèvement exige que drafts/article.md et drafts/checks.md existent, que les affirmations incorrectes soient corrigées, que les affirmations non résolues soient clairement marquées, et que les chemins des fichiers générés ainsi que les résultats de vérification apparaissent dans la conversation. Arrêter après 12 tours si la condition n'est toujours pas remplie et signaler le point de blocage.

La clause relative aux tours est évaluée par le modèle. Des limites strictes d'exécution ou de budget nécessitent des contrôles d'exécution, et `/goal clear` supprime un objectif actif.

À la fin de l'exécution, ouvrez les deux fichiers et inspectez quelques correspondances entre affirmations et sources.

Vérifiez que la note d'avancement correspond bien au travail enregistré dans l'espace de travail.

Réutilisez le même format de preuves pour la tâche suivante.

Un rapport cohérent vous permet d'identifier les affirmations non résolues et les contrôles manquants sans avoir à reconstruire toute la conversation.

Pour la reprise, `/rewind` peut restaurer les modifications de fichiers suivies. Les changements shell et la plupart des éditions des sous-agents nécessitent une reprise distincte, tandis que le contrôle de version préserve un historique durable des fichiers. Limites des points de contrôle

Exécuter le workflow complet une fois

Créez les dossiers sources et les quatre fichiers de configuration avant de démarrer la session => Placez un bref cahier des charges à côté des documents sources pour que le résultat attendu reste explicite.

Copiez ceci dans sources/task.md et complétez les détails :

1Sujet : [sujet précis]
2Lecteur : [qui a besoin de cette explication]
3Livrable : Un article avec des étapes pratiques et des sources officielles.
4Acceptation : Sujets requis traités ; affirmations factuelles vérifiées ;
5affirmations non résolues marquées ; brouillon et tableau de relecture enregistrés.
6Contraintes : [longueur, style, sujets exclus]

Démarrez Claude Code avec la commande de la couche six et inspectez la configuration chargée => Lancez l'objectif de la couche sept, puis vérifiez les livrables enregistrés.

Le résultat attendu comprend `drafts/article.md`, `drafts/checks.md` et `progress.md`.

Le tableau de contrôle doit indiquer ce qui a été vérifié et ce qui requiert encore votre attention.

Si le skill est introuvable, inspectez son chemin et son frontmatter.

Si le relecteur manque, vérifiez son `name` et sa `description`, puis confirmez sa disponibilité via `/agents`.

Pour les affirmations non résolues, inspectez la source fournie et les preuves demandées par le relecteur.

Comblez l'écart ou laissez-le visiblement marqué avant d'accepter le brouillon.

Vérifier ce que la session suivante pourra récupérer

Mettez à jour `progress.md` après chaque étape significative.

Notez-y les fichiers actuels, les contrôles terminés, les questions en suspens et la prochaine action.

Le fichier CLAUDE.md racine est relu après une compaction.

Les instructions ciblées se rechargent lorsque les fichiers concernés sont consultés. Compaction et mémoire

Utilisez cette structure concise pour la note d'avancement :

1Tâche : [sujet actuel]
2Livrables : [chemins du brouillon et de la relecture]
3Terminé : [étapes et contrôles achevés]
4Décisions : [choix confirmés et leurs sources]
5Points en suspens : [preuves manquantes ou blocages]
6Prochaine action : [une étape concrète pour continuer]

Démarrez une nouvelle session dans le même espace de travail et collez :

1Lire progress.md et inspecter le brouillon et les contrôles mentionnés.
2Reprendre à partir de la prochaine action enregistrée et mettre à jour la note d'avancement.

La session devrait identifier le travail enregistré et reprendre là où il avait été laissé. Si elle repart de zéro, inspectez la note et ajoutez la décision ou le chemin de fichier manquant.

Les recommandations d'Anthropic sur les agents de longue durée s'appuient sur des notes d'avancement persistantes pour soutenir le travail d'une session à l'autre.

Maintenez ces notes à jour à mesure que la tâche évolue, afin qu'une exécution reprise dispose d'informations actualisées. Harness pour agents de longue durée

Mesurer la configuration sur un travail accepté

Utilisez `/usage` pour inspecter la consommation signalée et `/context` pour voir ce qui occupe le contexte de travail. Incluez la relecture déléguée et les nouvelles tentatives dans le total de la tâche. Guide d'utilisation

Notez le temps passé à votre relecture et les corrections que le résultat a exigées.

Un livrable qui nécessite des retouches importantes modifie la valeur de toute l'exécution.

Gardez la tâche et les critères d'acceptation constants lorsque vous testez un changement de configuration.

Ajustez un seul composant, relancez la tâche, puis inspectez à la fois le résultat enregistré et ses preuves.

La réduction de 60 % des tokens évoquée dans le rapport des testeurs précoces d'Anthropic appartient à cette expérimentation spécifique.

Mesurez les économies réalisées par votre propre harness en vous basant sur des tâches réellement accomplies. Annonce d'Opus 5.5

Après la première exécution acceptée, réutilisez le skill avec un nouveau sujet et un nouveau jeu de sources. Conservez le même relecteur, les mêmes chemins de sortie et le même format d'achèvement, puis mettez à jour la procédure dès qu'une correction récurrente révèle une étape manquante.

Sauvegardez ceci pour ne pas le perdre

Suivez @beamnxw pour plus d'alpha :)

=> mon substack

=> mon canal telegram