qbarev/para-plugin

Travaille avec la boîte de réception du coffre PARA, qui se trouve dans la boîte de réception de l'application de tâches — capture une pensée brute, liste ce qui est en attente de traitement, ou traite les captures une par une dans leur dossier PARA approprié. À utiliser quand l'utilisateur souhaite capturer une note, mentionne sa boîte de réception (Todoist «Входящие», par exemple), ou dit «capture ça», «ajoute à la boîte de réception», «qu'est-ce qu'il y a dans la boîte de réception», «traite la boîte de réception», «запиши», «закинь в инбокс», «что в инбоксе», «покажи инбокс», «разбери инбокс», «разгреби инбокс».

Qu'est-ce que para-plugin ?

Ce skill permet de gérer la boîte de réception (inbox) d'un coffre PARA, en utilisant l'API de tâches comme backend de capture plutôt qu'un simple dossier. Il propose trois sous-commandes : `add` pour capturer rapidement une pensée sans friction, `list` pour afficher les captures non traitées (avec gestion des fichiers orphelins), et `process` pour router interactivement chaque capture une par une vers le dossier PARA approprié (action, tâche de projet, projet, domaine, ressource, ou corbeille). Le skill respecte la méthodologie PARA complète, en s'appuyant sur des fichiers de règles partagées (paths.md, tasks.md, note-format.md, confirm.md, move.md) et offre un support bilingue via des fichiers de langue. Il évite le traitement par lots, privilégiant un processus réfléchi capture par capture, et ne supprime jamais les entrées de manière irréversible sans confirmation. Utilisé avec des agents comme Claude Code, il permet d'augmenter rapidement son coffre de notes et de tâches sans quitter le flux de travail en ligne de commande.

Compatible avec~Claude Code~Codex CLI~Cursor

npx skills add https://github.com/qbarev/para-plugin/tree/HEAD/skills/inbox

Documentation

Boîte de réception

Le buffer de capture du coffre est la boîte de réception du backend de tâches, pas un dossier — paths.md établit cette règle et définit ce que Inbox/ sur le disque signifie. Une capture quitte le buffer pour un dossier PARA approprié une fois qu'il est clair de quoi il s'agit, ou reste dans le backend s'il s'agit simplement d'une action.

Sous TASKS = files, la boîte de réception est le dossier Inbox/ (paths.md explique ce que cela signifie, y compris les fichiers orphelins) ; les étapes ci-dessous sont inchangées, à l'exception de la gestion des orphelins.

Chaque appel de tâche est une opération provenant de tasks.md, exécutée selon l'adaptateur pour TASKS. Si le backend est indisponible, tasks.md « Backend manquant » s'applique.

Couche de base

À lire avant d'agir, chacun en tant que ../../para/<fichier>.md relatif au répertoire de base de ce skill — ces fichiers contiennent les règles partagées, ne les restituez pas de mémoire :

../../para/paths.md — toujours, y compris « Langue » : les chaînes ci-dessous proviennent de lang/<LANG>.md
../../para/tasks.md — toujours : les opérations ; pour process, également ce qu'est une tâche, les domaines, projets
../../para/note-format.md — pour process
../../para/confirm.md — pour process
../../para/move.md — pour process, lorsqu'il achemine un fichier orphelin hors de Inbox/

Sous-commandes

Le premier mot de $ARGUMENTS choisit la sous-commande. Tout ce qui n'est pas list ou process est traité comme le texte d'un add, donc /inbox une pensée sur le sommeil capture cette pensée — le mot-clé add est facultatif. $ARGUMENTS vide → affiche les trois sous-commandes et demande.

`add <texte>` — capturer

inbox.add avec un title et une description facultative. Un texte court est le titre tel quel. Un texte long reçoit un titre court dérivé dans LANG (6 mots ou moins) et le texte complet textuellement comme description.
Ne définissez rien d'autre — ni date, priorité ou étiquettes, sauf si l'utilisateur les a mentionnées. C'est un buffer, pas un endroit pour mettre en forme la pensée de l'utilisateur.
Signalez en une ligne ce qui a été créé, afin que l'utilisateur puisse renommer s'il n'est pas d'accord.

Si la capture appartient manifestement à un endroit spécifique, mentionnez-le dans le rapport et proposez /inbox process — ne l'acheminez pas sans qu'on vous le demande.

`list` — afficher ce qui n'est pas traité

Lecture seule.

inbox.list — chaque capture ouverte.
Affichez une liste numérotée, de la plus ancienne à la plus récente, précédée de la chaîne inbox.header ({n} captures, {days} l'âge de la plus ancienne). Titres uniquement, pas de descriptions.
Orphelins. Pas sous TASKS = files (paths.md). Listez les fichiers *.md dans Inbox/ (noms de fichiers uniquement, ne les ouvrez pas). S'il en existe, ajoutez une ligne, la chaîne inbox.strays ({k} fichiers).
Une boîte de réception vide est une réponse valable et bonne : dites-le clairement.

`process` — acheminer les captures

La valve du buffer. Interactif, une capture à la fois — ne videz jamais toute la boîte de réception avec des destinations proposées en demandant à l'utilisateur d'approuver en bloc.

Listez la boîte de réception comme ci-dessus — d'abord les captures du backend (les plus anciennes), puis les orphelins de Inbox/ (sous TASKS = files, inbox.list les inclut tous, paths.md). Dites combien il y en a et commencez par la première.

Pour chaque capture : affichez le titre et le contenu (la description, ou le corps du fichier pour un orphelin) — brièvement si c'est long. Donnez ensuite votre interprétation de ce que c'est, et proposez les routes. Les noms des routes sont les chaînes inbox.route.* de lang/<LANG>.md ; la colonne de gauche ci-dessous est la clé :

Route	Ce qui se passe
`inbox.route.action`	une tâche hors de tout projet → le libellé vérifié selon `tasks.md` « Ce qu'est une tâche » et une reformulation proposée et acceptée d'abord, puis `task.move` avec le `area` choisi par l'utilisateur (les noms sont ceux donnés par `tasks.md` pour `area`) et le `title` convenu
`inbox.route.project_task`	une étape d'un projet existant → le projet trouvé selon `find-target.md`, le libellé proposé selon `tasks.md` « Ce qu'est une tâche », puis `task.move` avec cette `project_ref` et le nouveau `title` ; la tâche reste ouverte, rien n'est créé ni fermé. Sous `TASKS = files`, un nom de base déjà pris est une collision : `note-format.md` « Collisions de noms »
`inbox.route.project`	un effort avec un état final → confier à `/projects create`
`inbox.route.area`	responsabilité continue → `/areas create`, ou ajouter à un Domaine existant
`inbox.route.resource`	connaissance qui vaut la peine d'être conservée → `/resources create`
`inbox.route.keep`	pas encore mûre — reste dans la boîte de réception, sans honte
`inbox.route.delete`	déchet → la fermer (voir ci-dessous)

Recommandez-en une, avec une raison en une phrase. L'utilisateur décide.

Exécutez la route, en transmettant le texte de la capture au skill propriétaire de la destination — il construit la note à partir de son propre modèle. N'écrivez jamais de note ici.
Fermez la capture une fois sa route exécutée :
- Capture du backend — acheminée dans le coffre, ou déchet → inbox.close — réversible (tasks.md), donc Niveau 1 (confirm.md). inbox.route.action et inbox.route.project_task déplacent la tâche elle-même (task.move) et la laissent ouverte ; inbox.route.keep la laisse là où elle est.
- Fichier orphelin dans Inbox/ — après que /projects create, /areas create ou /resources create a pris son contenu, supprimez le fichier via /remove ; pour inbox.route.delete, confiez-le directement à /remove. inbox.route.action le transforme en tâche avec task.add et area, puis supprime le fichier de la même manière.
Passez ensuite à la capture suivante. Ne regroupez pas les fermetures à la fin.
Arrêtez quand l'utilisateur dit stop, et signalez combien ont été traitées et combien restent. Vider toute la boîte de réception en une seule session n'est pas l'objectif.

Remarques

La boîte de réception est délibérément à faible friction : add ne pose jamais une question qu'il peut éviter. process est l'endroit où la réflexion a lieu.
Tout est dans LANG, y compris les tâches.