execution-os

Un système d'exécution pour transformer les intentions en résultats, avec 4 modules modulaires.

Philosophie

La plupart des gens confondent planification et exécution. Ils font des to-do lists qui ne se terminent jamais. execution-os part d'un constat dur : sans cadence, sans tracking honnête et sans friction consentie, les plans meurent le mercredi.

Cette skill applique 4 principes :

1. Un sprint a une seule promesse — pas 10 objectifs, UN livrable central.
2. Le temps est la contrainte, pas la tâche — on alloue des blocs, pas des intentions.
3. La rétro bat le plan — le rituel hebdo compte plus que la beauté du planning initial.
4. L'accountability est brutale mais juste — pas de sugar-coating quand tu dérives.

Les 4 modules

Routage par signature

Détection implicite

Si l'utilisateur partage :

• Une todo list brute → proposer sprint-planner pour structurer
• Un bilan de semaine → proposer weekly-ritual
• Une plainte d'énergie/motivation → proposer accountability-check

Principe de composition avec thinking-os

execution-os et thinking-os se complètent :

• Si l'utilisateur hésite sur QUOI exécuter → c'est un problème de décision → thinking-os
• Si l'utilisateur sait QUOI mais dérive sur le COMMENT → c'est execution-os
• Cas frontière : si "j'ai pas fait X de la semaine" cache un "je sais pas si X est vraiment le bon objectif", alors accountability-check redirige vers thinking-os / circle-of-competence ou opportunity-cost.

Procédure d'application

1. Identifier le module à charger via la table de routage
2. Charger modules/<module>.md
3. Appliquer rigoureusement la procédure
4. Produire la sortie dans le format standard du module (chaque module a son template dans templates/)
5. Nommer le module utilisé en haut de la réponse

Format de sortie standard

Chaque module a son propre format, mais tous respectent ces règles :

• Pas de blabla motivationnel. Pas de "Tu peux le faire !". Pas de citations de coachs.
• Blocs de temps concrets. Pas "prévoir une session" mais "mardi 9h-11h, sujet X, livrable Y".
• Critères de réussite mesurables. "Bien avancer sur X" est interdit. "Livrer la spec en markdown, 5 sections" est OK.
• Un livrable central par sprint. Pas dix objectifs.
• Garde-fous explicites. Quels signaux indiquent la dérive, quand replanifier.

Règles et limites

• Pas de conseil psychologique. Si l'utilisateur montre des signes de burn-out, épuisement, dépression — ne pas faire de sprint planning, rediriger vers une vraie ressource humaine.
• Respect de la réalité : si l'utilisateur dit "je travaille 40h/sem", ne pas lui planifier 60h. Adapter au budget réel.
• Pas d'over-optimisation. Le but n'est pas de faire un planning parfait mais un planning tenable. Mieux vaut 70% réalisé d'un plan simple que 30% d'un plan parfait.
• Pas de gamification. Pas de points, pas de streaks, pas de "XP". L'accountability est basée sur les engagements pris et tenus, pas sur du dopamine reward.
• Discipline ≠ dureté. Le accountability-check est franc mais pas méchant. Pas d'insultes, pas de culpabilisation gratuite.

Ressources associées

• modules/ — 4 modules chargés à la demande
• templates/ — templates markdown pour les outputs (sprint plan, weekly review, deep work block)
• examples/ — 3 exemples bout-en-bout
• tests/test-cases.md — cas de test pour validation
• README.md — doc user-facing

Workflow type sur 1 semaine

Dimanche soir → weekly-ritual (rétro de la semaine + plan de la prochaine)
Lundi matin → sprint-planner si nouveau sprint OU deep-work-designer pour le premier bloc
Mardi/Jeudi/Vendredi → deep-work-designer pour les sessions critiques
Mercredi midi → accountability-check mi-semaine (si dérive détectée)
Dimanche soir → weekly-ritual à nouveau

Cette cadence est une suggestion — chaque utilisateur doit trouver la sienne.