← Tous les Skills · Automatisation
Automatisation PremiumLaunch Plan Compiler
Transforme les données d'un lancement en une liste de vérification datée, avec responsables et portes de go/no-go : les tâches se divisent en avant le lancement, le jour du lancement et après, chacune datée à partir du jour du lancement, et un verdict — GO, NOT READY ou NO-GO — à partir des portes que vous listez.
Fonctionne avec : Claude Code, Codex, Cursor, Muse · Version 1.0.0 · Il vous faut : Vos données de lancement : launch.txt (lignes Launch et Date, puis une ligne Task par travail — phase | title | owner | when — et une ligne Gate par contrôle de go/no-go — name | criterion | status).
Aperçu

Exemple de résultat
Un exemple de ce que produit ce Skill. Contenu d'échantillon, montré à titre d'illustration.
Launch Plan Compiler report — sample Tasks: 6 | Gates: 2 | Verdict: GO | Gaps: 0 | Errors: 0 | Warnings: 0 Launch day: Dec 1, 2026. Before launch: freeze the feature list (Nov 24, Priya) and draft the announcement post (Nov 28, Sam). Launch day: flip the feature flag and post the announcement (Dec 1). After launch: reply to launch-day feedback (Dec 3, Sam) and publish the week-one recap (Dec 8, Priya). Gates: pricing page live and support inbox staffed, both passed — verdict GO. Gaps: None.
Ce que vous obtenez
- Un verdict de go/no-go à partir de vos portes, en premier sur la page
- Une liste de vérification datée divisée en avant le lancement, le jour et après
- Un responsable pour chaque tâche — une tâche sans responsable reste Unassigned, jamais inventée
- Toutes les lacunes, erreurs et avertissements d'entrée signalés dans le rapport
À propos de ce Skill
Lit un fichier en texte brut que vous écrivez — launch.txt, avec une ligne Launch et une ligne Date (jour du lancement, AAAA-MM-JJ), plus des lignes Task (phase | title | owner | when) et des lignes Gate (name | criterion | status) — et produit launch-plan.md : d'abord le verdict de go/no-go, puis la liste divisée en Avant le lancement / Jour du lancement / Après le lancement, chaque tâche datée et triée, et enfin le tableau des portes. Une valeur when est un décalage D (D-7, D+0, D+3) ou une date absolue, résolue par rapport au jour du lancement ; une tâche dont la phase ne correspond pas à sa date est écartée et signalée. Uniquement local, uniquement la bibliothèque standard ; une tâche sans responsable reste Unassigned, une porte sans statut reste pending, et un lancement sans tâche ou sans porte le dit tel quel — le plan est un document, il ne publie ni n'envoie rien.
Essayez-le
Transformez ces données de lancement en une liste de vérification datée, avec responsables et portes de go/no-go — que se passe-t-il avant, pendant et après le jour du lancement, et sommes-nous GO ?
Idéal pour
- Planifier un lancement dont les tâches s'étalent sur la semaine précédente, le jour même et la semaine suivante
- Décider GO ou NO-GO à partir d'une courte liste de contrôles avec des critères nommés
- Vérifier une liste de lancement à moitié écrite pour voir exactement ce qui manque
Pas pour
- Publier ou envoyer quoi que ce soit — le plan est un document, le lancement lui-même est à vous
- Vérifier une porte à votre place — pass signifie que vous l'avez vérifiée, pas que le lancement réussira
- Déplacer vos dates — une tâche dont la phase ne correspond pas à sa date est écartée, jamais rephasée en silence
Comment l'installer
- Copiez l'invite d'installation dans votre agent :
Read https://skillu.dev/install/agent.md, then install the Launch Plan Compiler skill (launch-plan-compiler). - Ou téléchargez le paquet du Skill depuis cette page après le lancement et placez son dossier dans le répertoire de skills de votre agent.
- Appelez-le avec une commande barre oblique, p. ex.
/launch-plan-compiler, et décrivez ce que vous voulez en mots simples.
Questions fréquentes
Comment la date d'une tâche est-elle calculée ?
À partir du jour du lancement : un décalage D compte les jours depuis celui-ci — D-7, c'est sept jours avant, D+0, c'est le jour du lancement, D+3, c'est trois jours après. Une date absolue est utilisée telle qu'elle est écrite. La phase doit correspondre à la date résolue : before, c'est avant le jour du lancement, launch-day, c'est le même jour, after, c'est après ; un écart écarte la tâche et la signale dans les erreurs.
Comment le verdict est-il décidé ?
À partir de vos portes, dans cet ordre : NO DATE quand aucune date de lancement valide n'a été donnée, NO GATES quand aucune porte n'a été listée, NO-GO quand au moins une porte a échoué, NOT READY quand aucune n'a échoué mais au moins une est encore pending, GO quand toutes ont réussi. Une porte sans statut compte comme pending.