tderoussel/triage-boîte-réception

Trie une boîte de réception — classe ce qui nécessite une réponse, rédige les brouillons, signale ce qui nécessite une décision, et met en avant ce qui peut être ignoré ou désabonné. À utiliser lorsque l'utilisateur dit « trie ma boîte », « fais mes emails », « qu'est-ce qu'il y a dans ma boîte » ou « nettoie mes emails ».

Qu'est-ce que triage-boîte-réception ?

Cette compétence transforme une boîte de réception en une courte liste de décisions accompagnée d'une pile de brouillons. Elle ne envoie jamais rien. Idéale pour les développeurs et utilisateurs d'agents IA qui souhaitent gagner du temps sur le traitement des emails sans risquer d'envoyer accidentellement un message. Elle prend en charge toute intégration de messagerie (Gmail, Outlook via MCP, API client, ou pont CLI comme Composio) et respecte une règle stricte : brouillon uniquement, jamais d'envoi, d'archivage, de suppression ou de désabonnement. Le processus extrait les emails récents, les classe en quatre catégories, rédige les brouillons pour les réponses courantes dans le style de l'utilisateur, et génère un rapport structuré. Enfin, il détecte les motifs répétitifs pour suggérer des automatisations complémentaires.

Compatible avec~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/tderoussel/agent-skills/tree/main/skills/inbox-triage

Installed? Explore more Productivité et collaboration skills: steipete/gemini, steipete/gh-issues, steipete/skill-creator · View all 6 →

Demander à votre IA préférée

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

Documentation

Triage de la boîte de réception

Transforme une boîte de réception en une courte liste de décisions accompagnée d'une pile de brouillons. N'envoie jamais rien.

Règle stricte

Brouillon uniquement. Ne jamais envoyer, ne jamais archiver, ne jamais supprimer, ne jamais désabonner. Chaque action qui quitte la machine attend l'utilisateur. Ce n'est pas négociable et ne se relâche pas avec la familiarité.

La règle s'applique même lorsque l'email lui-même demande une réponse immédiate, et même si l'utilisateur a déjà approuvé des envois similaires auparavant. L'approbation se fait par lot.

Configuration

Toute intégration de messagerie fonctionne — un serveur MCP Gmail/Outlook, un client API, ou un pont CLI comme Composio :

composio search "fetch emails" --toolkits gmail
composio link gmail

Si l'utilisateur possède plusieurs comptes de messagerie, la plupart des intégrations prennent en charge plusieurs connexions par fournisseur. Choisissez-en un explicitement, et demandez lequel si c'est ambigu — trier la mauvaise boîte aux lettres gaspille toute l'exécution.

Étapes

1. Récupération

Récupérez les emails non lus et récents. Par défaut, les dernières 24 heures sauf indication contraire ; si cela fait plus longtemps, demandez la fenêtre plutôt que de deviner.

2. Tri en quatre catégories

CatégorieSignification
Vous concerneUne vraie décision, un engagement, de l'argent, ou une relation que seul l'utilisateur peut gérer
Brouillon prêtRéponse courante — rédigez-la, ne l'envoyez pas
Pour infoBon à savoir, aucune action
BruitNewsletters, reçus, notifications, propositions non sollicitées

Décisions subjectives, par ordre d'importance :

  • Tout ce qui vient d'un client payant, d'un investisseur, d'un conseiller ou d'un collaborateur proche nommé va dans Vous concerne même si la réponse semble courante. Conservez cette liste dans la propre copie de cette compétence par projet.
  • Tout ce qui implique de l'argent, un risque juridique ou un engagement va dans Vous concerne.
  • Les démarchages non sollicités sont du Bruit sauf s'ils sont vraiment pertinents pour quelque chose d'actif.
  • En cas d'hésitation entre Vous concerne et Brouillon prêt, choisissez Vous concerne.

3. Rédiger les brouillons

Pour tout ce qui est dans Brouillon prêt, rédigez la réponse dans la voix de l'utilisateur — référencez un document de ton de marque ou de style d'écriture si le projet en a un. Court, direct, sans remplissage. Adaptez le registre du fil : une question d'une ligne obtient une réponse d'une ligne.

Enregistrez-les comme brouillons dans le client de messagerie afin qu'ils soient prêts là où l'utilisateur travaille déjà, et affichez-les également dans le résumé.

4. Rapport

## Boîte de réception — <date>, <N> messages

### Vous concerne (<n>)
- **<expéditeur>** — <ce qu'ils veulent> → <quelle est la décision>

### Brouillon rédigé (<n>)
- **<expéditeur>** — <sujet> → <résumé d'une ligne de la réponse>

### Pour info (<n>)
- <une ligne chacun>

### Bruit (<n>)
<comptage par type. Nommez tout expéditeur méritant un désabonnement — ne vous désabonnez pas.>

Gardez-le lisible. Si Vous concerne est vide, dites-le en une ligne et arrêtez — ne rajoutez pas de contenu inutile.

5. Surveiller les motifs

Si le même genre d'email arrive régulièrement et reçoit la même réponse, signalez-le. C'est le signe qu'il faut une compétence dédiée, un filtre ou une réponse type — et c'est plus précieux que le tri lui-même.

Exécution planifiée

Bon candidat pour deux ou trois fois par jour. Les brouillons s'accumulent, l'utilisateur les révise par lots, rien ne part sans lui.

Individual skills in this repo

This repo contains 8 individual skills — each has its own dedicated page.

tderoussel/codebase-audit

Runs a ranked, evidence-backed audit of a product, codebase, or subsystem, ending in a verify list that separates proven findings from inferred ones. Use when the user asks for an audit, a gap analysis, a deep read, a bug hunt, a readiness check, a re-audit, a state reconciliation, or asks what they are not seeing. Trigger phrases include "audit", "gap analysis", "what am I missing", "deep audit", "readiness", "bug hunt", "review the whole thing". Produces findings and a verify list; does not fix.

tderoussel/competitive-teardown

Researches a competing product against your own and produces a ranked build-or-ignore verdict, plus optional comparison-page copy. Use when the user names a competitor or asks how their product stacks up against one. Trigger phrases include "vs us", "competitor", "what does X have", "should we copy", "competitive gap", "teardown", "are we behind". Produces a ranked verdict with effort estimates and an explicit not-worth-copying list.

tderoussel/decision-council

Run a structured multi-perspective review of a decision instead of getting one agreeable answer. Use when the user says run a council, get me perspectives on this, should I do X, stress-test this decision, or is this a good idea.

tderoussel/fleet-brief

Authors a workstream brief for dispatching multiple parallel build agents across one codebase, with per-lane file ownership, shared-ground warnings, and a derived DO-NOT list. Use whenever work is about to be split across concurrent agents, workers, lanes, or waves — even if the user does not say "write a brief". Trigger phrases include "fan out", "parallel agents", "orchestrate this", "split into lanes", "workstreams", "run these in parallel", "review-gated build". Produces the brief; does not dispatch.

tderoussel/overnight-build

Composes an autonomous unattended Claude Code build prompt that survives usage-limit resets via BUILD_LOG.md checkpointing, plus the launcher that restarts it. Use when the user asks for an overnight build, an autonomous build, a build to run while they sleep, an unattended or unsupervised session, or any long build they will not be monitoring. Trigger phrases include "overnight build", "run overnight", "build while I sleep", "autonomous build", "let it run", "unattended". Produces a single copyable prompt; does not run the build.

tderoussel/session-log

Write a durable record of a work session — what was built, root-caused, or shipped — into the project's notes. Use when the user says log this session, write a session log, record this, or when a substantial piece of work has just finished and needs to be handed off to a future session.

tderoussel/ship-gate

Verification gate for a Next.js-on-Vercel + Supabase + GitHub Actions stack, to run before claiming anything is shipped, deployed, live, merged, passing, or done. Use before saying a change is in production, before merging a PR, before reporting CI green, and before writing any status into a document — even if the user does not ask for verification. Trigger phrases include "is it live", "did it deploy", "ship it", "merge it", "is CI green", "confirm prod", "did that work". Encodes traps where the obvious check returns a false pass.

tderoussel/vault-doctor

Audits and repairs an Obsidian vault's structural health — broken [[wikilinks]], ambiguous duplicate filenames, missing or malformed frontmatter, stale status markers, and hub notes whose state sections have gone cold. Use when the user asks about vault health, broken links, vault cleanup, dead links, orphan notes, tag consistency, or says the vault feels messy or out of date. Trigger phrases include "vault health", "broken links", "clean up the vault", "audit the vault", "is the vault current". Read-only by default; every repair is proposed before it is made.

Skills associés