tderoussel/inbox-triage

Clasifica la bandeja de entrada de correo electrónico: ordeña lo que necesita respuesta, redacta las respuestas, marca lo que requiere una decisión y destaca lo que puede ignorarse o darse de baja. Úsalo cuando el usuario diga 'triage my inbox', 'do my email', 'what's in my inbox' o 'clean up my email'.

¿Qué es inbox-triage?

Esta habilidad transforma una bandeja de entrada de correo electrónico en una lista de decisiones corta más un conjunto de borradores, sin enviar nunca nada. Es útil para desarrolladores y usuarios de agentes de IA que desean optimizar su flujo de trabajo de correo electrónico: separa mensajes que requieren atención personal, redacta respuestas rutinarias, identifica información para leer y descarta ruido (newsletters, notificaciones, etc.). Funciona con cualquier integración de correo (servidores MCP de Gmail/Outlook, API cliente o puentes CLI como Composio). El agente clasifica los mensajes en cuatro categorías ('Te necesita', 'Listo para borrador', 'Para tu información' y 'Ruido'), redacta respuestas en el tono del usuario y genera un resumen estructurado. Una regla estricta prohíbe enviar, archivar o eliminar cualquier cosa; solo se crean borradores para que el usuario los revise y apruebe por lotes. También detecta patrones repetitivos que podrían automatizarse con filtros o respuestas prediseñadas.

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

Installed? Explore more Productividad y colaboración skills: steipete/gemini, steipete/gh-issues, steipete/skill-creator · View all 6 →

Preguntar en tu IA favorita

Abre un nuevo chat con esta habilidad de agente ya precargada.

Documentación

Clasificación de bandeja de entrada

Convierte una bandeja de entrada en una lista de decisiones corta más un conjunto de borradores. Nunca envía nada.

Regla estricta

Solo borradores. Nunca enviar, nunca archivar, nunca eliminar, nunca cancelar suscripción. Cada acción que salga de la máquina espera al usuario. Esto no es negociable y no se relaja con la familiaridad.

La regla se mantiene incluso cuando el propio correo pide una respuesta inmediata, e incluso cuando el usuario ha aprobado envíos similares antes. La aprobación es por lote.

Configuración

Cualquier integración de correo funciona: un servidor MCP de Gmail/Outlook, un cliente API o un puente CLI como Composio:

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

Si el usuario tiene varias cuentas de correo, la mayoría de las integraciones admiten varias conexiones por proveedor. Elige una explícitamente y pregunta cuál quiere si es ambiguo: clasificar la bandeja equivocada desperdicia toda la ejecución.

Pasos

1. Extraer

Obtén los correos no leídos y recientes. Por defecto, de las últimas 24 horas a menos que se indique lo contrario; si ha pasado más tiempo, pregunta por el intervalo en lugar de adivinar.

2. Clasificar en cuatro cubos

CuboSignificado
Te necesitaUna decisión real, un compromiso, dinero o una relación que solo el usuario puede manejar
Listo para borradorRespuesta rutinaria: escríbela, no la envíes
Para tu informaciónVale la pena saberlo, sin acción
RuidoBoletines, recibos, notificaciones, contactos fríos

Decisiones de criterio, en orden de importancia:

  • Cualquier cosa de un cliente que paga, un inversor, un asesor o un colaborador cercano nombrado va a Te necesita, incluso si la respuesta parece rutinaria. Mantén esa lista en la copia propia de este skill del proyecto.
  • Cualquier cosa que involucre dinero, exposición legal o un compromiso va a Te necesita.
  • Los contactos fríos son Ruido a menos que sean genuinamente relevantes para algo activo.
  • Cuando dudes entre Te necesita y Listo para borrador, elige Te necesita.

3. Redactar las respuestas

Para todo lo que esté en Listo para borrador, escribe la respuesta en la voz del usuario: consulta un documento de tono de marca o estilo de escritura si el proyecto tiene uno. Corta, directa, sin relleno. Iguala el registro del hilo: una pregunta de una línea recibe una respuesta de una línea.

Guarda como borradores en el cliente de correo para que estén donde el usuario ya trabaja, y muéstralos también en el resumen.

4. Informar

## Bandeja de entrada — <fecha>, <N> mensajes

### Te necesita (<n>)
- **<remitente>** — <qué quieren> → <cuál es la decisión>

### Redactado (<n>)
- **<remitente>** — <asunto> → <resumen de una línea de la respuesta>

### Para tu información (<n>)
- <una línea cada uno>

### Ruido (<n>)
<recuento por tipo. Nombra cualquier remitente del que valga la pena darse de baja — no te des de baja.>

Que sea escaneable. Si Te necesita está vacío, dilo en una línea y para: no añadas relleno.

5. Detectar patrones

Si llega el mismo tipo de correo una y otra vez y recibe la misma respuesta, dilo. Eso es una señal para un skill dedicado, un filtro o una respuesta prediseñada, y es más valioso que la propia clasificación.

Ejecutar esto según un horario

Buen candidato para dos o tres veces al día. Los borradores se acumulan, el usuario los revisa por lotes, nada sale sin ellos.

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 relacionados