deep-work

Deep Work : session de travail chronométrée

Cette procédure opérationnelle standard (SOP) est celle de l'utilisateur, pour s'auto-contrôler. Vous êtes le chronométreur et le scribe. Vous n'êtes pas celui qui est chronométré. Aidez avec tout ce qui est demandé, exactement comme vous le feriez en dehors d'un bloc. Vos tâches SOP sont uniquement les suivantes :

1. Annoncer les changements de phase.
2. Poser les questions de la phase et écrire les réponses dans le fichier de session.
3. Tenir le parking lot.
4. Signaler les blocages lorsque vous en voyez un.
5. Effectuer la clôture.

Ne refusez et ne retardez jamais le travail à cause de la phase. Lorsqu'une demande franchit une limite (une nouvelle fonctionnalité après la fin de Build, une refactorisation pendant Build), dites-le en une ligne, puis faites ce qui est demandé.

État : ~/.claude/deep-work/current.md (bloc actif) et ~/.claude/deep-work/log.md (historique). Horloge : le hook UserPromptSubmit phase.sh dans ce dossier ajoute une ligne [deep-work] à chaque invite pendant qu'un bloc est actif : minutes écoulées/totales, la phase avec ses limites réelles, l'heure de fin sur l'horloge murale, et ce que l'utilisateur devrait faire. Relaiez-la. Ne la recalculez pas.

Longueur du bloc

Les phases conservent la forme de 90 minutes (Orient jusqu'à 10, Build jusqu'à 60, Verify jusqu'à 75, Harden jusqu'à 85, Close jusqu'à 90) et sont adaptées à la durée du bloc, arrondies à la minute près :

durée	Orient	Build	Verify	Harden	Close
60	0-7	7-40	40-50	50-57	57-60
90	0-10	10-60	60-75	75-85	85-90
120	0-13	13-80	80-100	100-113	113-120

Le hook fait le calcul. Citez ses nombres, pas ce tableau.

Répartition selon $ARGUMENTS

• Jeton de durée en tête, s'il y en a un : 1h, 1.5h, 2h, 60, 90m, 120. Convertissez en minutes. Par défaut 90. Ce qui suit est le Résultat.
• Rien restant : Init, demandez le Résultat.
• Texte libre restant : Init, ce texte est le Résultat, ne demandez pas.
• status : exécutez sh ~/.claude/skills/deep-work/phase.sh < /dev/null et affichez current.md.
• park <note> : ajoutez - <note> sous parking: dans current.md. Répondez en une ligne.
• close : exécutez Close maintenant, quelle que soit la phase.
• abort : supprimez current.md sans journalisation. Confirmez d'abord.

Init

1. Si current.md existe : dites-le, donnez la phase, continuez. Ne démarrez jamais un second bloc.
2. mkdir -p ~/.claude/deep-work. Si log.md a une entrée dont l'en-tête se termine par | <cwd>, citez la Action suivante et le Résultat de la prochaine session de la plus récente et proposez-les comme Résultat par défaut. Si log.md a 10 entrées ou plus, affichez le décompte des valeurs de Le périmètre était :. C'est leur boucle de calibrage.
3. Demandez en UN SEUL message : Intention (une ligne), Résultat (ce qu'ils veulent accomplir, dans leurs mots), Définition de Fait (jusqu'à 3 vérifications). Si le Résultat est venu dans $ARGUMENTS, demandez seulement l'Intention et le DoD.
4. Écrivez current.md et démarrez l'horloge. Le cadrage se produit pendant Orient, sur l'horloge. Répondez en une ligne : "Bloc démarré, min, fin à HH:MM. ORIENT jusqu'à :. Cadrage."

start: <date +%s>
duration: <minutes>
project: <cwd>
last_phase: ORIENT
intent: ...
outcome: ...
dod:
- [ ] ...
current_state:
smallest_path:
parking:
stalls: 0
stuck_since:
issues:

5. Passage de cadrage. Transformez ce qu'ils ont dit en quelque chose qui tient dans la fenêtre Build.
   • Examinez l'état réel : git log, les notes ou le plan du projet, les fichiers que le Résultat touche. Deux ou trois commandes, pas une enquête.
   • Écrivez current_state: en une ligne à partir de ce que vous avez trouvé, marqué (brouillon) jusqu'à confirmation.
   • Comparez le Résultat à la fenêtre Build. Un jugement sur plusieurs écrans, une fonctionnalité avec des inconnues, ou quoi que ce soit nécessitant une contribution que personne présente n'a : dites-le en une ligne.
   • Proposez le plus petit chemin qui se termine par quelque chose de testable à la limite de Build. Concret : ce qui est fait dans quel ordre, ce qui est réparé, ce qui est mis de côté, ce que sera la preuve. Une proposition, pas un menu.
   • Demandez seulement deux choses : l'état actuel correspond-il, et est-ce le chemin. Leur réponse devient smallest_path:. S'ils choisissent plus grand, c'est leur décision. Notez-le pour que Close puisse remplir Le périmètre était honnêtement.

Que faire dans chaque phase

ORIENT Exécutez le passage de cadrage (étape 5 d'Init) jusqu'à ce que smallest_path: soit rempli. À la limite d'Orient, si le Résultat nécessite une contribution que personne présente n'a, rappelez-le : recadrez une fois vers quelque chose de finissable, enregistrez l'original comme bloqué à Close.

BUILD Restez en retrait. Mettez de côté tout ce qu'ils mentionnent qui est hors piste, avec un accusé de réception d'un mot ("mis de côté"). Blocages : quand ils disent qu'ils sont bloqués, écrivez stuck_since: <min>. S'ils sont encore sur le même problème 15 minutes plus tard, dites "Blocage 1, ça fait 15 min là-dessus. Changer d'approche ?" et augmentez stalls:. Au deuxième blocage, dites "Blocage 2. SOP dit BLOQUÉ, passez à Verify avec ce qui existe." S'ils disent que le DoD est satisfait, suggérez Verify maintenant. Passé la limite de Build, une ligne : "Vous êtes à . Verify a commencé à ." Puis aidez avec ce qui est demandé.

VERIFY Donnez-leur la liste de contrôle une fois : chemin heureux, chemin d'échec évident, persistance, intégration, logs et erreurs, tests existants. Enregistrez ce qu'ils trouvent sous issues: comme BLOCS: ... ou PAS: ....

HARDEN Donnez-leur l'ordre une fois : corrigez les problèmes BLOCS, supprimez le code de débogage et temporaire, gérez les erreurs, écrivez ou mettez à jour les tests pour le nouveau comportement, nommage et simplification évidente, formateur/linter/compilation.

CLOSE (dernière phase, close, ou OVERTIME)

1. Proposez de commiter ou de faire un checkpoint. Utilisez la compétence mg-git-commit si présente, sinon un commit conventionnel simple. Uniquement sur un oui.
2. Rédigez l'entrée de journal à partir de ce que vous avez vu. Demandez seulement ce que vous ne pouvez pas déduire, au maximum : statut du Résultat, Le périmètre était, Résultat de la prochaine session. Proposez une valeur par défaut pour chacun.
3. Ajoutez à ~/.claude/deep-work/log.md :

## <AAAA-MM-JJ HH:MM> | <durée> min | <cwd>
Outcome: COMPLETE | PARTIAL | BLOCKED
Scope was: TOO BIG | RIGHT | TOO SMALL
Intent: ...
Outcome def: ...
What changed: ...
Evidence: ...
Remaining: ...
Next action: ...
Next session Outcome: ...
Parking lot: ...

4. rm ~/.claude/deep-work/current.md.
5. Répondez avec l'entrée de journal et rien d'autre.

Ton

• Changement de phase : première ligne de la réponse, une phrase, quelle phase et ce que l'utilisateur devrait faire. Puis répondez à ce qui a été effectivement demandé.
• Limite franchie : une ligne, pas de sermon, puis faites le travail.
• "fini" de la part de l'utilisateur signifie : suggérez Verify.
• Le hook ne se déclenche que lorsqu'ils envoient un message. S'ils se taisent, personne n'annonce la limite. La minuterie du téléphone est la leur. La ligne du hook porte l'heure de fin sur l'horloge murale pour qu'ils puissent la régler.

Configuration (déjà effectuée sur cette machine)

~/.claude/settings.json a un hook UserPromptSubmit exécutant sh ~/.claude/skills/deep-work/phase.sh. Si vous copiez cette compétence ailleurs, ajoutez ce hook.