Communitygithub.com

JetBrains/thinkrail

Vibe code with pi dans un IDE réel et léger - Le Vibe Qu'il Vous Faut

Qu'est-ce que thinkrail ?

Cette compétence fournit un planificateur de tâches collaboratif et en direct pour les sessions de chat dans un IDE (tel que JetBrains). Elle permet à l'agent IA et à l'utilisateur de gérer une liste de tâches structurée en groupes (tâches) et éléments (étapes), où chaque groupe représente une demande utilisateur et chaque élément une étape vérifiable et de taille commit. L'utilisateur peut modifier la liste en temps réel, ajoutant ou supprimant des tâches, et l'agent doit constamment se resynchroniser en relisant la source de vérité. La compétence est utile pour décomposer des demandes complexes en étapes gérables, suivre la progression sans lire l'historique du chat, et permettre à l'utilisateur de prioriser son travail. Elle prend en charge les outils `todo_write`, `todo_add`, `todo_update`, `todo_remove` et `todo_list` pour une gestion granulaire des tâches, tout en respectant des invariants stricts (ne jamais supprimer les éléments terminés, ne jamais réécrire la liste pour une simple modification).

Compatible avec~Claude Code~Codex CLI~Cursor
npx skills add JetBrains/thinkrail

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

Documentation

Plan TODO de chat

Ce que c'est

  • Un plan limité à ce chat — vos tâches pour la conversation. Affiché à l'utilisateur dans le panneau Todo ; vit avec la session (n'est pas commité dans le dépôt).
  • Groupe = tâche, élément = étape. Une demande utilisateur = un groupe ; son titre est le résultat ("Corriger la redirection de connexion"), pas le processus. Les étapes à l'intérieur sont les éléments — chacun a un titre, un statut (pending → in_progress → done) et une note facultative (placez le critère de validation là, par ex. "test e2e de connexion vert"). Le statut d'une tâche n'est jamais stocké — il découle de ses étapes.
  • Les éléments libres sont la voie de l'utilisateur — et ils se trouvent à la FIN du plan. Ils contiennent ce que l'utilisateur ajoute depuis l'interface ; vous les traitez, mais ne les regroupez, réécrivez ou supprimez jamais. todo_list les affiche en dernier, après chaque groupe, intentionnellement : une requête que l'utilisateur ajoute en cours de tâche se place après votre travail actuel. Donc terminez (ou reprenez) la tâche en cours avant de prendre un élément libre — ne sautez pas sur un élément fraîchement ajouté par l'utilisateur en abandonnant une étape que vous aviez en cours. Vous n'êtes pas l'auteur des éléments libres (les outils nécessitent un group ou un ancrage after); une petite demande est un petit groupe (1–2 étapes convient), ou pas de liste du tout.
  • C'est partagé et en direct : vous le maintenez, et l'utilisateur le modifie pendant que vous travaillez — ajoutant des tâches, supprimant celles qu'il abandonne. La liste stockée est la source de vérité ; ce que vous retenez n'est qu'un instantané. Relisez-la (todo_list) pour rester synchronisé, ne faites pas confiance à votre mémoire.
  • C'est la fenêtre de statut de l'utilisateur — comment il suit ce qui se passe d'un coup d'œil sans lire le chat. Titres d'étapes courts et concrets ; statuts toujours à jour.

Granularité

Taille de la demandeForme dans le plan
Trivial (une réponse, une modification)pas de liste du tout
1–7 étapesun groupe (une petite demande = un groupe de 1–2 étapes, ça va)
plus de ~10 étapesce ne sont pas des étapes, ce sont des tâches — diviser en plusieurs groupes

Les étapes sont vérifiables et de taille de commit : "faciles à cocher au fur et à mesure", pas "phase 1".

Travailler avec

  1. Proposez le plan d'abord — c'est le but de la liste. Dès que vous comprenez une demande qui prend plus de quelques étapes, votre première action est todo_write avec votre plan proposé — un groupe par tâche, étapes à l'intérieur — avant de poser des questions de clarification et avant de commencer le travail. Ensuite, affinez-le sur place à mesure que vous en apprenez plus. (Une réponse ponctuelle n'a pas besoin de liste.)
  2. Travaillez les tâches strictement dans l'ordre, une étape à la fois :
    • Passez une étape à in_progress quand vous commencez, done quand vous terminez. Commencer une nouvelle étape remet automatiquement toute autre étape in_progress à pending — donc terminez (marquez done) avant de passer à autre chose, sinon l'étape précédente revient visiblement à ouverte.
    • Ne commencez pas le groupe suivant tant que le groupe actuel a des étapes ouvertes. La seule exception : une tâche réellement bloquée — enregistrez la raison dans la note de l'étape, dites-le à l'utilisateur, et passez au groupe suivant.
    • Avant chaque étape suivante, todo_list à nouveau. L'utilisateur a peut-être modifié en cours de travail : notez tout nouveau (il est ajouté dans la voie de l'utilisateur à la fin — traitez-le après l'étape en cours, ne préemptez pas le travail en cours), et si un élément que vous aviez planifié a disparu, l'utilisateur l'a supprimé — passez-le, ne le réajoutez pas.
    • Les résultats des outils vous aident : après un done, ils nomment la prochaine étape de la tâche ; quand rien n'est in_progress, ils vous rappellent de basculer l'étape en cours. Suivez ces incitations.
  3. Une nouvelle demande en cours de session = un nouveau groupe ajouté (todo_add avec group:, une par étape — ou détaillez les étapes de la nouvelle tâche avec plusieurs appels todo_add). Ne mélangez jamais les étapes d'une nouvelle demande dans le groupe actuel. Une étape découverte en cours de tâche s'insère avec todo_add after: <id de l'étape actuelle> (ancrez à l'une de vos étapes — ancrer à l'un des éléments de l'utilisateur est rejeté, car vos éléments ne vivent jamais dans leur voie) — ne reconstruisez pas le plan avec todo_write pour cela.
  4. Réconciliez avant de terminer. À la fin d'un tour, todo_list une fois de plus. Si des étapes ouvertes restent (y compris les éléments que l'utilisateur vient d'ajouter), soit faites-les, soit dites clairement ce qu'il reste et pourquoi — ne restez pas inactif en laissant silencieusement des éléments frais non touchés.

Invariants

  • Terminé reste. Terminer une étape = todo_update → done. Ne supprimez jamais un élément done — c'est l'historique de l'utilisateur. todo_remove est uniquement pour quand l'utilisateur demande explicitement d'abandonner quelque chose.
  • Modifiez chirurgicalement. Après le premier plan, utilisez todo_update / todo_add (ils touchent un élément). Ne faites jamais todo_write pour ajuster une liste existante — cela remplace tout ; todo_write est uniquement pour élaborer un plan frais.
  • Respectez les modifications de l'utilisateur. La liste est partagée ; traitez leurs ajouts comme de nouvelles requêtes et leurs suppressions comme des annulations. Les éléments libres sont les leurs — traitez-les, mais ne les réécrivez pas et ne les supprimez pas lorsque vous replanifiez. (todo_write préserve les éléments utilisateur et les éléments done pour vous, mais ne vous y fiez pas — utilisez todo_add/todo_update pour modifier, et gardez todo_write pour un plan vraiment frais.)

Outils

  • todo_list — lire le plan actuel (la source de vérité ; relire pour capter les modifications de l'utilisateur).
  • todo_add — ajouter une étape (dans un group, ou after une étape existante ; laisse le reste intact).
  • todo_update — progresser une étape (in_progress au début, done quand terminé ; done reste).
  • todo_remove — supprimer un élément (uniquement quand l'utilisateur le demande).
  • todo_write — élaborer un plan frais (groupes seulement — un par tâche ; remplace vos éléments ouverts ; utilisez une fois, au début).

Skills associés