Déclencheurs

examen du plan CEO
réviser la stratégie
réviser ce plan
penser plus grand
élargir le périmètre
est-ce assez ambitieux
repenser cela
révision stratégique
remettre en question le plan
multiplier par 10 le plan
est-ce que je pense assez grand

Révision du plan — mode CEO

Vue d'ensemble

La plupart des plans sont trop limités. Le travail consiste à repenser le problème, trouver le produit à 10 étoiles, remettre en question les prémisses et élargir le périmètre quand la version plus grande crée un produit matériellement meilleur — pas juste plus long.

C'est la première révision du pipeline autoplan (CEO → design → eng). Elle s'exécute en amont de l'architecture, donc sa sortie doit être « c'est la version qu'on devrait vraiment construire », pas « voici comment construire la version qu'on avait déjà ».

Ne refaites pas la révision de design ou d'ingénierie ici. Arrêtez-vous à « qu'est-ce qu'on devrait construire et pourquoi ». Transmettez au design / eng pour la prochaine passe.

Les quatre modes de périmètre

En choisir exactement un. Annoncer le mode avant de faire la révision.

1. ÉLARGISSEMENT DU PÉRIMÈTRE — rêver grand

À utiliser quand le plan est clairement trop peu ambitieux par rapport aux capacités réelles de l'agent, au levier de l'utilisateur ou à l'appétit du marché. Exemples : « créer une landing page pour X » alors que l'agent peut aussi auto-déployer, auto-lancer et auto-promouvoir → le plan devrait inclure cela.

Sortie : une version plus grande du plan, chaque expansion justifiée (« l'expansion-A permet la composition parce que… »).

2. ÉLARGISSEMENT SÉLECTIF — figer le périmètre, sélectionner les gains

Mode par défaut pour la plupart des plans. Garder le périmètre central verrouillé, mais identifier les 1–3 expansions qui créent un upside disproportionné par rapport à leur coût. Rejeter le reste avec des commentaires d'une ligne.

3. FIGER LE PÉRIMÈTRE — rigueur maximale

À utiliser quand le périmètre est juste mais l'exécution est bâclée. Ne pas élargir ; relever plutôt le niveau sur le plan existant : meilleurs critères d'acceptation, utilisateur cible plus précis, définition de « fini » plus stricte.

4. RÉDUCTION DU PÉRIMÈTRE — réduire à l'essentiel

À utiliser quand le plan essaie d'en faire trop. Identifier la tranche minimale viable qui livre quand même la valeur centrale. Couper tout le reste et marquer « plus tard ».

Six dimensions à noter (0–10 chacune)

Pour chaque dimension, écrire une phrase sur ce qui ferait un 10, puis noter le plan tel qu'écrit.

Réalité de la demande — quelqu'un désire-t-il ardemment ceci ? Niveau de demande « sauterait une réunion pour l'avoir », pas « ce serait sympa ».
Spécificité de l'entrée — le point d'entrée utilisateur/cas d'usage est-il douloureusement spécifique ? « Stripe pour X pour Y » vaut mieux que « plateforme de paiements ».
Composition — livrer V1 rend-il V2 moins cher / mieux / inévitable ? Ou chaque version est-elle un démarrage neuf ?
Levier de distribution — l'agent a-t-il déjà un canal pour cet audience (compte X, commune agent, chat livestream, liste email) ? Sinon, qui le porte aux utilisateurs ?
Différenciation — qu'est-ce qui empêche un concurrent malin de cloner ceci en un weekend ? « Juste mieux » n'est pas une réponse.
Vérité de soi — cela correspond-il à l'identité et aux compétences réelles de l'agent, ou est-ce une nouvelle persona qu'il faudrait ajouter ?

Un plan avec un score inférieur à 6 sur une dimension doit être corrigé avant d'avancer vers la révision de design ou d'ingénierie. Note 0–4 ➜ mode 4 (RÉDUCTION) ou tuer ; 5–6 ➜ mode 3 (FIGER avec rigueur) ; 7–8 ➜ mode 2 (ÉLARGISSEMENT SÉLECTIF) ; 9–10 ➜ mode 1 (ÉLARGISSEMENT) seulement si l'équipe a vraiment de la bande passante.

Comment utiliser

Lire le plan (chemin, texte, ou goal_status de l'objectif actif).
Faire knowledge_search(scope="system") pour l'identité + guide de style afin que les décisions de périmètre correspondent à la nature réelle de l'agent.
Choisir un mode et l'annoncer.
Noter les six dimensions.
Retourner un plan révisé + une liste des décisions prises (lesquelles ont été auto-décidées vs lesquelles ont besoin de l'entrée du goût de l'utilisateur).

Quand appelé depuis plan_autoplan, retourner le JSON structuré attendu par cet outil (voir tools/planning/autoplan_tool.py pour le schéma). Quand appelé de manière interactive, narrative + plan final révisé c'est correct.

Ce que cette skill ne fait PAS

Choisir les architectures (travail de la révision eng).
Critiquer l'UI/UX (travail de la révision design).
Écrire du code ou implémenter.
Auto-approuver les changements de périmètre qui modifient la trajectoire du produit sans les surfacer — les changements majeurs de périmètre vont dans l'escalations[] du pipeline pour que l'utilisateur les voit.

Vérifier

Le livrable pour cette phase existe sous forme d'artefact concret (doc, ticket, board, repo) et sa localisation est partagée, pas décrite
Chaque engagement a un propriétaire nommé, une date d'échéance et une définition-de-fini que quelqu'un d'autre que l'auteur pourrait vérifier
Les risques sont listés avec probabilité/impact et une mitigation nommée, pas une puce « risques : TBD » générique
Les dépendances envers d'autres équipes/vendeurs/agents sont explicites ; un accusé de réception de chaque dépendance est enregistré ou marqué « en attente »
Les critères de succès pour la phase suivante sont numériques ou autrement objectivement testables
Un critère de rollback / kill-switch / « on arrêtera si X » est écrit avant que le travail commence

plan-review-ceo