Las skills de pstack para Cursor: todo el flujo de desarrollo

Hay dos formas de usar un agente de código. La primera es pedirle cosas y cruzar los dedos. La segunda es darle un método de trabajo tan estricto como el de un buen equipo de ingeniería y exigirle pruebas de todo lo que hace.

Esa segunda forma es la que propone pstack.

Es el plugin de skills que Lauren Tan (poteto en redes), del core team de React y parte del equipo de Cursor, ha publicado en el repositorio oficial de plugins de Cursor. Según su propio README, son “las mismas skills que uso cada día para enviar código de calidad en Cursor”. Y su lema lo deja claro desde la primera línea: if you want to go fast, go deep first. Si quieres ir rápido, primero ve a fondo.

Hay 47 carpetas de skills en el repo. Puestas en orden, dibujan un flujo completo de desarrollo: entender el código, diseñar el cambio, construirlo, limpiarlo, verificarlo y aprender de lo que ha pasado.

Eso es lo que vamos a recorrer hoy:

• Cómo se instala pstack y qué hace /setup-pstack con tus modelos
• Por qué /poteto-mode es la única skill que necesitas recordar
• Las skills de cada fase: /how, /why, /architect, /arena, /interrogate, /tdd, /swarm, /unslop, /no-comments, /reflect y compañía
• Los 23 principios que puedes usar como palabras clave para corregir al agente
• Dónde encaja (y dónde choca) pstack con el desarrollo guiado por especificaciones

Qué es pstack y qué problema quiere resolver ¶

Se trata de un plugin para Cursor que agrupa skills, subagentes y principios de ingeniería con un objetivo explícito: escribir menos código, pero de más calidad. La versión que he revisado es la 0.15.5, publicada bajo licencia MIT en cursor/plugins.

El autor lo plantea como respuesta al slop, ese código que la IA escupe en cantidad industrial y que nadie quiere mantener. En sus palabras: “no quiero enviar código como un equipo de veinte artistas del slop”. La velocidad sin calidad no es un objetivo.

Y no es una queja aislada. En la encuesta de Stack Overflow de 2025, el 84 % de los desarrolladores ya usa o planea usar herramientas de IA, pero el 46 % desconfía de la precisión de lo que generan. La frustración número uno que citan es la de las soluciones “casi correctas”. Esa es la grieta que ataca pstack: el agente no da nada por terminado sin enseñarte la prueba.

El contenido del plugin se organiza en cuatro bloques:

🔑 Lo que te da pstack es un proceso para lanzar varios agentes en paralelo y fiarte de lo que devuelven. Los atajos para escribir más rápido no son su guerra.

Esa es la promesa que el README llama fearless parallelism: si puedes confiar en un agente que va a fondo y verifica, puedes tener varios trabajando a la vez sin miedo.

Ojo a una ausencia deliberada: pstack no trae skills de planificación. Su autor cree que la mejor especificación es el código, y lo discutiremos más abajo. Si tú eres de los que prefieren fijar la intención por escrito antes de soltar al agente, el complemento natural es el desarrollo guiado por especificaciones.

Curso gratis · paso a paso

Pon la especificación que pstack deja fuera

El ciclo completo de SDD con OpenSpec sobre un proyecto de juguete: proposal, spec, diseño y tareas antes de que el agente toque el código, y luego apply y archivar.

Entra en el curso gratis →

Instalación y primer paso: /setup-pstack ¶

La instalación es un comando dentro de Cursor:

# Instala el plugin desde el marketplace de Cursor
/add-plugin pstack

Después viene la única configuración que merece la pena hacer: /setup-pstack. Esta skill detecta los modelos que tienes disponibles, te pregunta por un presupuesto de razonamiento y escribe una regla siempre activa en ~/.cursor/rules/pstack-models.mdc.

Los presupuestos son cuatro: unlimited (mantiene el máximo), large (xhigh), medium (high) y small (medium). Cuanto más bajo, menos gastas y menos piensa cada modelo.

La parte que me parece más valiosa es la asignación de modelos por rol. El plugin no usa un único modelo para todo. Por defecto reparte así:

# Fragmento de la regla que genera /setup-pstack
feature, refactoring: grok-4.7-xhigh-fast
bug-fix: grok-4.7-xhigh-fast
judgment and prose: claude-opus-5-5-max
hardest tasks: claude-opus-5-5-max
arena runners: claude-opus-5-5-max, gpt-5.6-sol-max, grok-4.7-xhigh-fast
interrogate reviewers: claude-opus-5-5-max, gpt-5.6-sol-max, grok-4.7-xhigh-fast

El código rutinario va a un modelo rápido. El juicio, la prosa y los cambios más delicados van al modelo más potente. Y las revisiones se hacen con un panel de tres familias distintas para que los sesgos de uno no pasen desapercibidos.

Si trabajas en modo Auto de Cursor, puedes poner auto o inherit-parent en cualquier rol y ese rol usará el modelo del chat principal.

⚠️ La skill solo escribe identificadores de modelo que ha podido comprobar que tienes disponibles. Si no detecta ninguno, te pide que los pegues tú. No inventa slugs.

Al terminar, te ofrece una cosa más: generar una skill de verificación para tu proyecto. Volveremos a ella en la fase de verificar, porque es de lo mejor del paquete.

Por qué /poteto-mode es la puerta de entrada ¶

Si solo vas a recordar un comando de pstack, que sea este. /poteto-mode lee tu petición, la empareja con uno de sus 23 playbooks, abre una lista de tareas con los pasos de ese playbook copiados al pie de la letra y va llamando al resto de skills cuando cada paso lo requiere.

La guía oficial lo resume con un ejemplo:

/poteto-mode the export writes duplicate rows when a retry lands mid-run. repro first, then fix and verify.

No nombras el playbook. No listas skills. “repro first” y un resultado comprobable bastan para que elija el playbook de corrección de bugs.

Los playbooks cubren casi todo lo que haces en una semana de trabajo: investigación de solo lectura, bug fix, rendimiento, nueva funcionalidad, refactorización, prototipos, paridad visual, cuidar una PR hasta que esté lista (babysit), enviar un stack de PRs, ejecuciones autónomas nocturnas, retomar el trabajo de otro agente o limpiar worktrees. Y todos terminan en el mismo sitio: el playbook de abrir una PR con commits pequeños y ordenados.

Además es un modo pegajoso. Una vez lo activas, se queda activo entre turnos. Se aplica cuando la tarea necesita rigor y se aparta cuando haces una pregunta casual. Si quieres salir, lo dices y listo.

Hay tres reglas de /poteto-mode que definen su carácter:

1. Si la respuesta a una duda se puede observar ejecutando algo, no se le pregunta al humano. Se hace un prototipo y el resultado decide.
2. Toda afirmación lleva su evidencia en la misma frase, etiquetada como medida, inferida o suposición.
3. “No” es una respuesta aceptable. Si le propones algo que no merece la pena, te lo dice. Franqueza antes que complacencia.

💡 Esa segunda regla es la que más cambia la experiencia. Dejas de leer “listo, ya funciona” y empiezas a leer “verificado ejecutando X, salida Y”.

Ahora vamos a abrir la caja y ver qué skills llama por debajo, fase a fase.

Fase 1: entender el código antes de tocarlo ¶

La primera fase del flujo es no escribir código. Parece obvio, pero es el paso que más se salta cuando trabajas con un agente impaciente. Para esto, pstack tiene cuatro skills y las dos más usadas son /how y /why.

/how: cómo funciona un subsistema ¶

/how responde a “cómo funciona X” con una explicación al nivel de un ingeniero senior que se incorpora a un subsistema. Suficiente para construir un modelo mental, sin convertirse en código fuente comentado.

Su truco está en cómo decide el esfuerzo:

• Pregunta simple (un módulo, una función): lanza un único subagente que explora y explica de una pasada.
• Pregunta compleja (un subsistema de varios ficheros o servicios): lanza de 2 a 4 exploradores en paralelo con un modelo rápido, cada uno con un ángulo distinto, y después un explicador con el modelo fuerte que sintetiza.

La salida sigue siempre la misma estructura: visión general, conceptos clave, cómo funciona, dónde vive cada cosa y trampas conocidas.

/how do we cancel runs? do we have an n+1 when we look up every run to cancel?

/why: por qué está hecho así ¶

/why es el complemento. /how explica qué hace el código; /why investiga qué fuerzas le dieron esa forma.

Empieza anclando la investigación en código real con git blame, git log --follow y los números de PR de los merges. Después descubre qué servidores MCP tienes conectados y lanza un investigador por cada categoría de evidencia: control de versiones, gestor de incidencias, documentación larga, chat del equipo, observabilidad, seguimiento de errores y analítica de producto.

Hay un detalle de postura que me encanta: la skill obliga a distinguir entre lo que sabe y lo que infiere. Y “no encontré nada en el tracker” también cuenta como hallazgo. Se documenta el vacío, no se salta la búsqueda.

/recall y /teach ¶

/recall reconstruye tu contexto de trabajo reciente leyendo tu propio historial de chats de Cursor (por defecto, los últimos 7 días) y cruzándolo con el registro compartido: PRs, incidencias, errores en producción. Devuelve un resumen con un límite estricto: cinco puntos de estado, una línea por hilo con su etiqueta ([merged #N], [open PR #N]…), los problemas recurrentes y el siguiente paso.

/teach combina /how y /why en una única explicación construida diagrama a diagrama, para cuando quieres entender de verdad un cambio y no solo tener un resumen.

🔑 El orden importa: primero /how para saber qué hay, después /why si vas a cambiar la forma de algo. Cambiar código cuyo porqué desconoces es la receta clásica para reintroducir un bug que alguien ya arregló.

Fase 2: diseñar antes de que el código fije la forma ¶

Aquí es donde pstack se separa de la mayoría de colecciones de skills. En lugar de dejar que el agente se lance a implementar la primera idea, te obliga a explorar varias.

/architect: tipos y firmas primero ¶

/architect diseña antes de implementar. Esboza tipos, firmas de funciones y límites de módulos con cuerpos not implemented y pseudocódigo. Solo después rellena el código contra ese esquema.

Trabaja en cinco fases:

1. Ground: ejecuta /how sobre los sistemas afectados (y /why si el diseño cambia responsabilidades).
2. Sketch: lanza varios diseños en paralelo con modelos distintos. Exige al menos dos candidatos con estructuras diferentes, aunque el primero parezca suficiente.
3. Agree: por defecto pasa directo a implementar. Solo se para a pedirte visto bueno si se lo pides.
4. Implement: el esquema es el contrato. Si una función necesita un parámetro que el esquema no previó, eso es una señal que se reporta, no fricción que se absorbe en silencio.
5. Scrap: si la implementación genera siempre el mismo tipo de parche, se tira el esquema y se rediseña.

La fase de descarte tiene una lista de señales muy reconocible: el mismo workaround repetido en código que no tiene relación, tipos que necesitan any o casts para compilar, o el reflejo de “necesitamos un lock” cuando el diseño decía que el estado no era compartido.

Antes de sintetizar, cada candidato pasa un filtro de red flags de diseño: módulos poco profundos, fugas de información, descomposición temporal y métodos que solo pasan la llamada. Si te suena a A Philosophy of Software Design de Ousterhout, no es casualidad.

/arena: varios intentos, un ganador y los mejores injertos ¶

/arena es la skill que usa /architect por debajo, pero también funciona sola. Lanza N intentos en paralelo de la misma tarea, elige una base y le injerta lo mejor de los perdedores.

Su proceso tiene seis fases (enmarcar, lanzar, juicio cruzado, elegir, injertar y verificar) y dos decisiones que la hacen fiable:

• La rúbrica se escribe antes de lanzar nada, con 3 a 6 criterios concretos. Los candidatos no la ven; solo quien elige.
• Un juez independiente de otra familia de modelos puntúa a los candidatos por separado. Si coincide con tu elección, confirma. Si no coincide, uno de los dos tiene un sesgo o la rúbrica era ambigua.

Y un criterio de desempate que vale oro: se elige la base que un futuro mantenedor pueda extender con más facilidad sin romper invariantes.

💡 Si los N candidatos convergen en la misma forma, esa es una señal fuerte de acuerdo y no hace falta injertar nada. Si divergen muchísimo, el problema estaba mal planteado: se replantea en lugar de promediar.

/interrogate: que varios modelos intenten romperlo ¶

/interrogate lanza un revisor por cada modelo configurado contra tu diff. Todos reciben el mismo prompt y la misma rúbrica, más una lente estricta de calidad de código. La diversidad adversarial sale de usar modelos distintos, no de asignarles personajes.

Lo que devuelve es un veredicto, no cambios aplicados. Los hallazgos que dos o más modelos detectan por su cuenta tienen la máxima prioridad. Y luego tú, como revisor principal, clasificas cada uno en cuatro cubos: actuar, considerar, anotado o descartado (con su motivo).

/interrogate review this pr.

¿Y si no crees en planificar? ¶

El README de pstack tiene una sección titulada “why are there no planning skills?” y la respuesta es tajante: “personalmente, no creo en planificar. La mejor especificación es el código”.

Cursor ya tiene un modo Plan (lo repasamos en cómo trabajar con agentes en Cursor), y /poteto-mode incluye un playbook de plan multifase si lo necesitas, pero no es el camino por defecto. El diseño en pstack ocurre en forma de tipos y firmas (/architect), no de documentos.

Es una postura legítima y viene de alguien con mucho kilometraje. Pero no es la única que funciona. En proyectos con varias personas, requisitos que cambian o agentes que pierden el hilo entre sesiones, tener la intención escrita en un spec vivo ahorra muchas vueltas. Esa es la idea del desarrollo guiado por especificaciones (SDD), y las dos aproximaciones pueden convivir: el spec fija el qué, y /architect fija el cómo en el código.

Fase 3: construir con disciplina ¶

Con el diseño cerrado toca escribir código. En pstack esta fase la conducen los playbooks de /poteto-mode (feature, bug fix, refactoring, perf) y dos skills muy concretas.

/tdd: el test que falla, primero ¶

/tdd aplica a corrección de bugs cuando hay un camino de test barato y local. El flujo es clásico:

1. Entender el bug: comportamiento esperado, comportamiento actual, reproducción mínima.
2. Elegir el check ejecutable más estrecho, reutilizando el tipo de test que ya existe para ese código.
3. Escribir el test que falla.
4. Ejecutarlo antes de arreglar y comprobar que falla por el motivo correcto.
5. Hacer el cambio más pequeño que resuelve el bug.
6. Volver a ejecutar el test y confirmar que pasa.

Lo que me gusta de esta skill es su sección de cuándo no usarla. Si el test requiere montar un arnés enorme, mocks frágiles, infraestructura lenta o estado de producción, no se fuerza. La frase literal es: “mejor ningún test nuevo que un test malo”. Y define test malo como uno que prueba sobre todo mocks, codifica detalles de implementación o se borraría justo después de probar el arreglo.

/swarm: trabajo en paralelo con un solo informe ¶

/swarm lanza N trabajadores en la nube, espera a que terminen y te devuelve un único informe consolidado. Tiene tres formas:

• Particiones: cada trabajador cubre una porción distinta (un paquete, un servicio, una carpeta).
• Carreras: N trabajadores con el mismo encargo, y una regla de selección declarada antes de lanzar (el primero que pase, ordenar todos o quedarse con el mejor).
• Mixta: una combinación de ambas.

Cada trabajador reporta PASS, ISSUES o BLOCKED con evidencia. Si un resultado no registra los commits exactos y el método de medición que pedía su encargo, se descarta y se relanza una vez. Tras un segundo fallo, queda como hueco. Y un hueco nunca cuenta como aprobado.

/swarm check every package under packages/ against its check.sh. one worker per package. one report.

Conviene no confundirla con /arena. /arena busca el mejor artefacto combinando intentos. /swarm busca cobertura o una carrera y devuelve un informe.

Fase 4: limpiar el código y la prosa ¶

Esta fase es la que más se nota al leer el diff final. Y en la mayoría de equipos se hace a mano, cuando se hace.

/unslop: fuera los tics de IA ¶

/unslop es la skill de limpieza de texto. Su descripción es de dos frases: “Cut AI tells from any writing. Must always apply”. Y /poteto-mode la aplica a cualquier superficie de prosa, incluidas sus propias respuestas.

Tiene una lista numerada de patrones que detecta: vocabulario típico de IA (“delve”, “crucial”, “pivotal”, “tapestry”), el “no solo X, sino Y”, la regla de tres forzada, el abuso de negritas, los emojis decorativos en títulos, las frases de chatbot (“¡espero que te ayude!”), la jerga metafórica (“north star”, “flywheel”, “paradigm”) y la voz pasiva sin actor.

Mi regla favorita es la 27: di lo que hace, no cómo se siente. Una frase como “SQL que puedes leer” se cambia por algo comprobable como “.toSQL() devuelve el string exacto que se envía a la base de datos”. Y un test rápido: si la frase podría aparecer sin cambios en la documentación de otro proyecto, no dice nada sobre este.

⚠️ /unslop está pensada para inglés técnico y es muy estricta: prohíbe del todo los guiones largos y los dos puntos como conector a mitad de frase. Si escribes en español o tienes un estilo propio, adáptala antes de aplicarla a ciegas.

/no-comments y Comment Sicko ¶

/no-comments lanza un subagente de solo lectura llamado Comment Sicko (sí, así se llama) que revisa los comentarios de tu diff contra la rama base. La idea de fondo está en la sección de comentarios de /poteto-mode: un comentario solo sobrevive si explica un porqué no evidente que el código no puede mostrar.

La parte más interesante es qué hace con los comentarios de restricción, esos del tipo “no borrar” o “habla con X antes de cambiar esto”. En lugar de dejarlos, la skill ofrece codificar esa restricción en algo que se cumpla solo: un tipo, una comprobación en tiempo de ejecución, un test o una regla de lint. Si aceptas, se codifica y se borra el comentario.

Es el principio de encode lessons in structure aplicado a pequeña escala. Un comentario que dice “no borrar” lo puede saltar cualquiera con prisa. Un test que falla, no tanto.

Fase 5: verificar sobre la aplicación real ¶

Si pstack tuviera un solo mandamiento, sería este: demuestra que funciona. El principio prove-it-works lo formula así: verifica contra el artefacto real (ejecuta la funcionalidad, lee el valor, inspecciona el diff), no contra un proxy, un autoinforme o un “compila”.

Para que eso sea posible, el agente necesita una forma de manejar tu aplicación como lo haría un usuario. De eso se encarga /create-verification-skill.

/create-verification-skill: tu propio arnés de pruebas ¶

Esta skill entrevista al repositorio, no a ti. Averigua qué superficie toca el usuario (web, CLI, app de escritorio, API), cómo se arranca en local, cómo puede manejarla un agente (Playwright, scripts, endpoints, un puerto de depuración) y qué evidencias se pueden capturar.

Con eso genera una skill local en .cursor/skills/verify-<app>/ con secciones de arranque, diagnóstico, manejo y evidencias, todas con comandos y selectores reales de tu proyecto. Nada de ejemplos genéricos.

Y fija estándares de prueba bastante exigentes: usar el camino real del usuario y no setters internos, capturar la acción y el estado resultante, verificar efectos secundarios (ficheros escritos, filas insertadas, mensajes enviados) y desconfiar de los modos dry-run, que a veces tocan la red de todos modos.

Su hermana, /maintain-verification-skill, se encarga de mantener ese mapa de funcionalidades al día cuando la aplicación cambia.

🛡️ Sin una skill de verificación, “lo he probado” significa “he leído el código y creo que funciona”. Con ella, significa “lo he ejecutado y aquí tienes la captura”.

El cierre: abrir la PR y llevarla a verde ¶

Todos los playbooks terminan en Opening a PR: commits pequeños y ordenados, título con Conventional Commits y una descripción en formato informe. Después entran en juego los playbooks de babysit (conflictos, hilos de revisión, CI) y shipping (verificar cada PR de forma independiente antes de fusionar el stack de abajo arriba).

La frase del playbook de shipping resume la filosofía: “verde no es seguro”. Nada se activa antes de un veredicto independiente por PR.

Tu IA puede mentirte

Verifica lo que programa tu agente, uses pstack o no

La misma obsesión por la evidencia, aplicada a cualquier agente: pruebas en navegador con Playwright, casos Gherkin, evaluación de skills y adversarial review entre modelos.

Quiero ver la masterclass →

Métodos en directo + casos Gherkin

Fase 6: aprender de lo que ha pasado ¶

Lo que distingue a un equipo que mejora de uno que repite errores es que las lecciones se quedan escritas en algún sitio. Para cerrar ese círculo, pstack tiene dos skills.

/reflect: convertir una sesión en una mejora de skill ¶

Cuando una tarea larga ha terminado, /reflect lanza tres revisores en paralelo sobre la transcripción de la conversación, cada uno con una lente:

Un sintetizador junta los hallazgos en tres listas: aceptados, rechazados y backlog. Antes de aplicar, la skill hace una comprobación estructural: si algo se haría cumplir mejor con una regla de lint, un script o un flag, pasa a backlog en lugar de convertirse en más texto.

Y un punto clave: no aplica nada sin tu aprobación explícita. Los cambios en skills afectan a todos los agentes futuros de la organización, así que eliges qué subconjunto entra.

/automate-me: tu propio modo ¶

poteto-mode es el estilo de poteto. Puede que no sea el tuyo. /automate-me minea tus transcripciones recientes de Cursor (en tres tramos, de 2 a 4 semanas), cruza los patrones que se repiten en al menos dos tramos, te hace un par de preguntas cerradas y redacta una skill <tu-nombre>-mode.

Busca señales como tus preferencias de respuesta, tus hábitos de delegación, lo que para ti significa “terminado”, tus convenciones de commits y PRs o tu forma de revisar. El resultado mantiene pstack como base y añade tu propia skill de enrutado al lado de poteto-mode.

💡 Si ya escribes skills para Claude Code, el enfoque de minar tu propio historial es aplicable fuera de Cursor. Tienes más ideas sobre esto en buenas prácticas para crear skills.

Los 23 principios como vocabulario de trabajo ¶

Además de las skills de flujo, pstack incluye 23 skills diminutas, cada una con un único principio. /poteto-mode las indexa y las lee al empezar una tarea, y en su respuesta debe citar qué principio cambió qué decisión.

La utilidad práctica es doble. El agente tiene criterio consistente. Y tú tienes un vocabulario corto para corregirlo a mitad de tarea: “aplica laziness protocol” o “esto viola boundary discipline” es mucho más preciso que “hazlo más simple”.

Estos son los que más vas a usar:

El test del laziness protocol merece copia literal: “si un desarrollador humano encontraría el código agotador de mantener, es una mala solución”.

Qué skills elegir según lo que tengas entre manos ¶

Con 47 carpetas es fácil perderse. El propio README dice que casi todas son situacionales y que /poteto-mode las usa por ti. Aun así, esta tabla te sirve para saber a cuál ir directo:

Limitaciones y lo que conviene saber antes de instalarlo ¶

Es un plugin serio, y tiene costes que conviene conocer antes de instalarlo.

Consume muchos tokens. Las skills de revisión y diseño lanzan paneles de tres modelos de los más caros, varios exploradores y un sintetizador. Si trabajas con una cuota ajustada, empieza con el presupuesto small en /setup-pstack o pon auto en los roles de panel.

Está pensado para Cursor. Usa la herramienta Task de Cursor, sus reglas .mdc, sus transcripciones en ~/.cursor/projects/ y el comando /loop. La filosofía se puede trasladar a otros agentes, pero la mecánica no es portable tal cual.

Faltan piezas en el propio plugin. El README avisa de que /deslop, control-cli y control-ui viven en otro plugin, cursor-team-kit, que conviene instalar al lado si quieres el set completo.

Es un estilo personal. Los guiones largos prohibidos, el rechazo a planificar o la postura de “no preguntes lo que puedas comprobar” son decisiones de una persona concreta. Funcionan muy bien para ella. Para ti puede que no todas, y para eso existe /automate-me.

🔑 Aunque no uses Cursor, lee sus SKILL.md. Entender por qué están escritas así te da ideas para robar y adaptar a tus propias skills.

TL;DR ¶

• 🧰 El plugin pstack, de Lauren Tan (poteto) para Cursor, trae 24 skills de flujo, 23 principios y 2 subagentes, con licencia MIT.
• 🚪 /poteto-mode es la puerta de entrada: elige entre 23 playbooks y llama al resto de skills por ti.
• 🔍 El flujo va de entender (/how, /why) a diseñar (/architect, /arena, /interrogate), construir (/tdd, /swarm), limpiar (/unslop, /no-comments), verificar y aprender (/reflect).
• ✅ Su obsesión es la evidencia: nada está terminado sin probarlo sobre la aplicación real.
• 💸 Usa paneles de varios modelos caros: ajusta el presupuesto con /setup-pstack si vas justo de cuota.

Preguntas frecuentes ¶

¿Qué es pstack en Cursor? ¶

Es un plugin de Cursor creado por Lauren Tan (poteto), miembro del core team de React y del equipo de Cursor. Incluye skills de flujo de trabajo, 23 principios de ingeniería y subagentes pensados para que el agente escriba menos código pero de más calidad, y verifique todo lo que entrega.

¿Cómo se instala pstack? ¶

Se instala con el comando /add-plugin pstack dentro de Cursor. Después conviene ejecutar /setup-pstack para elegir el presupuesto de razonamiento y qué modelo se usa en cada rol.

¿Qué hace /poteto-mode? ¶

Empareja tu petición con uno de sus 23 playbooks (bug fix, feature, refactoring, perf, prototipo, babysit, shipping…), copia sus pasos en una lista de tareas y llama al resto de skills cuando cada paso lo necesita. Se queda activo entre turnos hasta que le pides que se desactive.

¿Qué diferencia hay entre /how y /why? ¶

/how explica cómo funciona un subsistema: flujo, conceptos y dónde vive cada cosa. /why investiga por qué se construyó así, consultando historial de git, PRs y las fuentes que tengas conectadas por MCP, como el tracker, el chat o la observabilidad.

¿En qué se diferencian /arena y /swarm? ¶

/arena lanza varios intentos de la misma tarea, elige el mejor como base e injerta lo bueno de los demás para producir un único artefacto. /swarm reparte trabajo en paralelo (por porciones o en carrera) y devuelve un informe consolidado con PASS, ISSUES o BLOCKED.

¿pstack funciona con cualquier modelo? ¶

Sí. El README indica que puedes usar cualquier modelo. Por defecto reparte el código a Grok, el juicio y la prosa a Claude Opus y los paneles de revisión a tres familias distintas, pero /setup-pstack permite cambiar cada rol o usar auto para heredar el modelo del chat.

¿pstack incluye skills de planificación? ¶

No como camino por defecto. Su autor explica en el README que no cree en planificar y que la mejor especificación es el código. El diseño se hace con /architect en forma de tipos y firmas, y si necesitas un plan, /poteto-mode tiene un playbook de plan multifase.

¿Qué es Comment Sicko? ¶

Es un subagente de solo lectura incluido en pstack que revisa los comentarios de tu diff. Se invoca a través de /no-comments, que elimina los comentarios que no explican un porqué no evidente y propone convertir las restricciones en tipos, tests o reglas de lint.

¿Puedo usar las skills de pstack fuera de Cursor? ¶

Las ideas sí, la mecánica no tal cual. Las skills dependen de la herramienta Task de Cursor, de sus reglas .mdc y de la ruta de sus transcripciones. Puedes adaptar los SKILL.md a otros agentes, pero tendrás que reescribir esas partes.

¿pstack gasta muchos tokens? ¶

Puede gastar bastantes, porque skills como /interrogate, /arena o /architect lanzan varios modelos de gama alta en paralelo. /setup-pstack ofrece presupuestos más bajos (medium o small) que reducen el nivel de razonamiento de todos los roles.

Fuentes ¶

• pstack en el repositorio de plugins de Cursor
• Guía de pstack
• SKILL.md de poteto-mode
• Stack Overflow Developer Survey 2025: AI

🧨 Última oprtunidad para recibir la dinamita que mereces sobre programación con IA el próximo domingo: Suscríbete gratis a Web Reactiva en https://webreactiva.com/newsletter