Discusión

Construye Mods de Espacio de Trabajo para IDE de Claude Code

De Wikiprompt, la enciclopedia libre de prompts

Avid
Contribuido porAvidXFuente

4 oct 2026

Construye Mods de Espacio de Trabajo para IDE de Claude Code Un prompt integral para construir un conjunto de mods de Claude Code que transformen la terminal en un espacio de trabajo estilo IDE con explorador de archivos, navegador de espacio de trabajo y barras de estado. Incluye especificaciones detalladas, reglas de API, fases de flujo de trabajo y requisitos de prueba.

Contenido del PromptGuardar

🌐
Esto convertirá tu terminal en una aplicación de claude code ultrarrápida <role> Eres un ingeniero senior de TypeScript. Construyes mods de Claude Code. Escribes módulos pequeños, pruebas cada módulo y solo reportas resultados que hayas verificado. </role> <variables> AUTHOR_NAME = "Tu nombre público" MARKETPLACE = "nombre-de-tu-marketplace" LICENSE = "MIT" PANE_COLUMNS = 48 </variables> <context> Un mod es un plugin de Claude Code. El archivo hooks/hooks.json nombra un módulo de hooks. El módulo de hooks exporta register(on, options). Cada hook es on('event', matcher, async ($, e, next) => result). "$" es la API de mods. "e" es el evento. "next(e)" ejecuta los otros mods y luego Claude Code. Quiero un espacio de trabajo estilo IDE dentro de una sesión de terminal de Claude Code. Las personas leen archivos, buscan, ven diffs, ejecutan tareas y se mueven entre sesiones sin una segunda ventana. Otras personas instalarán estos mods desde un marketplace público, por lo que los mods deben cargarse en una máquina limpia y no deben fallar cuando una herramienta (git, rg, cargo) esté ausente. Documentación oficial (lee las páginas que necesites): - https://t.co/i4akoKobgO - https://t.co/WPCOsxEplS - https://t.co/IeRIo28W71 - https://t.co/bQM1hlDd5j - Código fuente del mod integrado: https://t.co/XYpFTigXbE (lee "diff" primero; es un panel con botones y su propio desplazamiento) </context> <source_of_truth> La API de mods cambia entre versiones. Usa este orden cuando dos fuentes discrepen: 1. Las declaraciones de tipos que Claude Code escribe en .claude-plugin/types/ de cada mod. Estas describen la versión instalada. 2. La salida de "claude plugin validate". 3. Las páginas de documentación. 4. Este prompt. Ejecuta /plugin-authoring antes de escribir código. Lee claude-code/index.d.ts antes de usar un evento, un método, un elemento o una prop. Busca el nombre en ese archivo. No uses un nombre que no esté en ese archivo. Si este prompt nombra algo que la versión instalada no tiene, no inventes un reemplazo. Construye la versión más cercana que la API soporte y registra la diferencia en LIMITS.md. </source_of_truth> <api_rules> Claude Code hace análisis estático en el módulo de hooks. Estas reglas mantienen la validación en verde: - Escribe cada llamada a la API completa: $.fs.read(...), $.ui.open(...). No asignes "$" ni un espacio de nombres a una variable. No desestructures "$". - Pasa "$" solo a una función declarada en el nivel superior del mismo archivo. No pases "$" a una función importada, a un método ni a una función definida dentro de un hook. - Escribe cada nombre de evento como un literal de cadena en on(...). No hagas un bucle sobre una lista de nombres de eventos. - No declares una segunda variable llamada "on" dentro de register. - Usa módulos ES. Usa declaraciones de import en la parte superior del archivo. Sin require. Sin import() dinámico. - Importa solo archivos dentro del directorio del plugin, por ruta relativa. El único import sin ruta es "claude-code". - No inicies un nombre de plugin con "claude-". Resultado: mantén cada llamada a "$" en el módulo de hooks. Pon la lógica pura (parsers, modelo de árbol, ranking de búsqueda, formateadores) en archivos separados que tomen datos simples y devuelvan datos simples. Prueba los archivos puros directamente. Límites para los que diseñar: - Un hook tiene 10 segundos de su propio tiempo de ejecución. - $.fs.read y $.fs.write: 4 MiB para un archivo. Una cadena Text y un elemento Code: 10,000 caracteres. Pagina archivos largos. - $.store: 4 MiB de JSON en total, compartidos por todas las sesiones en la máquina. Da a cada elemento su propia clave. Limita cada lista. - $.process.run: 30 segundos por defecto. - Redibujados: 30 por segundo para el panel visible, 10 para otros sitios. - Un panel que un mod abre por sí mismo aparece solo a 144 columnas o más. Un panel que un comando de usuario o una pulsación abre aparece a cualquier ancho. Abre paneles desde comandos y pulsaciones. Reglas de teclado: - Un mod no puede vincular Tab ni las teclas de flecha. Tab se mueve entre controles. Arriba y Abajo se mueven entre controles o desplazan. - Un atajo de Button es un dígito o una letra minúscula. Mientras un Input tiene el foco, cada tecla imprimible va al Input. - Da a cada control una clave única. Las pruebas presionan controles por clave. - Claude Code no tiene un elemento de pestañas. Dibuja las pestañas como una fila de botones simples. Estado: - Variable de módulo: se pierde en cada recarga. Úsala para valores que pueden perderse. - $.state: dura para la sesión y redibuja los sitios que leen el valor. Declara cada valor en types/index.d.ts y nombra ese archivo en el manifiesto. - $.store: dura entre sesiones. Úsalo para configuraciones, sesiones recientes y proyectos. </api_rules> <repository_layout> .claude-plugin/marketplace.json una entrada para cada plugin, nombre del marketplace = MARKETPLACE plugins/file-explorer/ plugins/workspace/ plugins/ide-usage/ plugins/ide-statusbar/ README.md LICENSE PROGRESS.md LIMITS.md tests.json Cada plugin: .claude-plugin/plugin.json nombre, versión 0.1.0, descripción, autor = AUTHOR_NAME, licencia = LICENSE, types cuando sea necesario hooks/hooks.json { "modules": ["./register.ts"] } hooks/register.ts el único archivo que llama a "$" hooks/lib/*.ts lógica pura types/index.d.ts PluginState y cualquier espacio de nombres que el mod añada tests/*.test.ts pruebas para "claude plugin test" </repository_layout> <mod name="file-explorer"> Comando: /explorer abre el panel (id "explorer", título "Explorer", focus true, columnas PANE_COLUMNS). Registra el comando con immediate: true para que funcione durante un turno. Un segundo /explorer cierra el panel. /explorer <ruta> abre esa ruta. Fila de encabezado: la palabra EXPLORER, luego Back, Forward, Up, Close. Back y Forward se mueven por el historial de carpetas y archivos abiertos. Un Input debajo del encabezado. Su propósito cambia con la pestaña: - Pestaña Files: placeholder "Find files". Enter busca nombres de archivos y rutas debajo de la raíz. La búsqueda ignora mayúsculas. Detente en 500 coincidencias y muestra: N files match "query" (first 500, scan stopped). Muestra las coincidencias como un árbol con sus carpetas padre. Marca el texto coincidente. Una consulta vacía restaura el árbol. - Pestaña Code: placeholder "Find in file, :line, or /regex/". El texto simple encuentra cada aparición. ":42" va a la línea 42. "/re/" usa una expresión regular. Muestra "match 2 of 5". Los botones n y p van a la siguiente y a la anterior coincidencia. Pestañas: Files, Code, Diff. Pestaña Files: - Línea raíz: el nombre de la carpeta raíz y la ruta completa. La primera raíz es la carpeta de trabajo de la sesión. Up mueve la raíz a la carpeta padre. - Fila de acciones: New File, New Folder, Refresh, Collapse, More. New File y New Folder piden un nombre con un Input y crean el elemento en la carpeta seleccionada. More contiene Rename, Delete, Copy path y Show hidden files. Delete pide confirmación con $.ui.ask. - Árbol: lee un nivel de carpeta cuando el usuario abre esa carpeta. Ordena primero las carpetas, luego los archivos, por nombre. Muestra un marcador para el estado de la carpeta, una etiqueta de tipo corta para tipos de archivo conocidos (json, md, ts, js, py, rs, go, sh) y "nombre → destino" para un enlace simbólico. Muestra "(empty)" en una carpeta vacía. Omite .git y node_modules a menos que los archivos ocultos estén activados. - Selección y paginación: una fila seleccionada. Los botones mueven la selección hacia arriba y hacia abajo, abren una carpeta, cierran una carpeta y abren un archivo. Muestra el rango, por ejemplo "7-49 of 329". Dibuja solo las filas que caben en e.props.scroll.bodyRows. Pestaña Code: - Migas de pan de la ruta, luego "N lines · size". - Números de línea y colores de sintaxis. Usa el elemento Code. Pagina el archivo para que ningún elemento sea más grande que 10,000 caracteres. - Para un archivo más grande que 4 MiB o un archivo binario, muestra el tamaño y un mensaje. No leas el archivo. - Resalta la coincidencia actual y la línea actual. Pestaña Diff: - Muestra el diff sin confirmar del archivo abierto (git diff para esa ruta). Usa el elemento Code en modo diff. - Muestra el conteo de líneas añadidas y eliminadas. - Cuando Claude edita un archivo con Edit, Write o MultiEdit, registra la ruta en el hook https://t.co/Lb6btDn0iW después de que next(e) regrese. Si el panel está abierto, selecciona ese archivo y muestra la pestaña Diff. No abras el panel por ti mismo. - Si la carpeta no es un repositorio git, dilo en una línea. Otros mods abren un archivo a través de un espacio de nombres que este mod añade a la API de mods: https://t.co/crzRXVIH3H({ path, line, tab }). Declara el espacio de nombres en types/index.d.ts. Lee el mod integrado "telemetry" para ver cómo un mod añade métodos para otros mods. </mod> <mod name="workspace"> Depende de file-explorer (inclúyelo bajo dependencies en plugin.json). Comando: /workspace abre el panel del navegador (id "workspace", título "Workspace", columnas PANE_COLUMNS). Ubicación del navegador: la posición documentada de un panel es un dock junto a la transcripción, y Claude Code da a cada panel abierto una pestaña con su título. Busca en los tipos un campo que coloque un panel en el lado izquierdo. Si existe, pon el navegador a la izquierda y las herramientas en el dock derecho. Si no existe, el navegador es un panel más en el dock. Registra el resultado en LIMITS.md. Contenido del navegador, de arriba a abajo: 1. Título CLAUDE CODE y un botón New chat. New chat ejecuta el comando integrado que inicia una nueva conversación. Encuentra el nombre del comando con $.command.list. 2. WORKSPACE: un botón para cada herramienta, en este orden: Files, Terminal, Browser, Source Control, Problems, Run Tasks, Outline, To-do Comments, Timeline, Usage, Model Router. Una pulsación abre ese panel de herramienta y le da el foco. Marca las herramientas que están abiertas. 3. RECENTS: las 5 sesiones más recientes, con "Show more". Cada fila muestra el título, el nombre del proyecto y la antigüedad (8m, 22h, 3d). El título es el primer prompt de la sesión, recortado para que quepa. Una pulsación en una fila muestra los prompts de esa sesión debajo de la fila. Marca la sesión actual. 4. PROJECTS: cada carpeta de proyecto con su conteo de sesiones. Una pulsación muestra las sesiones de ese proyecto. Índice de sesiones: en el hook prompt.submit, escribe { id, cwd, repo, title, prompts[], updatedAt } en $.store bajo la clave "session:<id>". Mantén los 50 prompts más recientes para cada sesión y las 200 sesiones más recientes. Vuelve a leer el store antes de cada escritura, porque otras sesiones escriben en el mismo store. No leas ni analices los archivos de transcripción propios de Claude Code. Abrir una sesión reciente: revisa los tipos para un método soportado para cambiar o reanudar una sesión. Si no existe, copia "claude --resume <id>" con $.ui.copy y muestra un toast que lo diga. Herramientas. Cada herramienta es un panel con su propio id, un título corto y un botón Refresh. Cada herramienta muestra una línea clara cuando no tiene datos o cuando su programa está ausente. 1. Files: llama a https://t.co/crzRXVIH3H con la carpeta de la sesión. No dibuja un segundo árbol. 2. Terminal: un Input que ejecuta un comando con $.process.spawn en la carpeta de la sesión. Transmite la salida al panel. Mantén las últimas 500 líneas. Muestra el código de salida. Mantén un historial de 50 comandos. Un botón Stop termina el proceso. Esto es un ejecutor de comandos, no un emulador de terminal; dilo en el README. 3. Browser: un Input para una URL. Obtén con $.http.fetch. Muestra el código de estado, el título de la página y el texto legible como Markdown, recortado al límite del elemento. Muestra los enlaces como botones que cargan el enlace. Un botón "Open in system browser" usa el comando open del sistema operativo. Permite solo http y https. 4. Source Control: rama, conteos de adelante y atrás, y los archivos modificados con estado y "+añadidas −eliminadas" de git. Una pulsación en un archivo llama a https://t.co/crzRXVIH3H con tab "diff". Botones: Stage, Unstage, Stage all. Un Input de commit confirma los archivos en stage después de una confirmación con $.ui.ask. No hagas push, pull, reset ni descartes cambios. 5. Problems: ejecuta el comando de verificación del proyecto y lista cada problema como "archivo:línea mensaje" con una marca de severidad. Detecta el comando: tsc --noEmit para tsconfig.json, cargo check para Cargo.toml, go vet para go.mod, ruff check para pyproject.toml cuando ruff esté instalado. Una configuración de usuario reemplaza el comando detectado. Una pulsación llama a https://t.co/crzRXVIH3H con la línea. Ejecuta solo en Refresh y después de que un turno termine, y no ejecutes dos verificaciones al mismo tiempo. 6. Run Tasks: muestra la carpeta de la sesión. Encuentra tareas en scripts de package.json, objetivos de Makefile, recetas de justfile, Cargo.toml (build, test, clippy), scripts de pyproject.toml y go.mod (build, test, vet). Si no se encuentra ninguna, muestra: No task found (package.json, Makefile, justfile, Cargo.toml, pyproject.toml, go.mod). Un botón para cada tarea. Un Input con el placeholder "Run a command, then Enter". Transmite la salida y muestra el código de salida y el tiempo. 7. Outline: los símbolos del archivo que está abierto en el explorador, con números de línea: funciones, clases, structs, interfaces, constantes y encabezados de Markdown. Usa una pequeña tabla de patrones para cada lenguaje (ts, js, py, rs, go, md). Indenta los símbolos anidados. Una pulsación llama a https://t.co/crzRXVIH3H con la línea. 8. To-do Comments: encuentra comentarios TODO, FIXME, HACK y NOTE en el proyecto. Usa rg cuando esté instalado. Si no, recorre el árbol con $.fs.list y omite .git, node_modules, target y dist. Agrupa por etiqueta. Muestra "archivo:línea texto". Limita a 300 elementos. Una pulsación llama a https://t.co/crzRXVIH3H con la línea. 9. Timeline: una fila para cada prompt, llamada de herramienta y fin de turno en esta sesión, de más reciente a más antiguo, con la hora del reloj. Para Edit y Write, muestra la ruta y los conteos de líneas. Una pulsación en una fila de edición llama a https://t.co/crzRXVIH3H con tab "diff". Mantén 300 filas. 10. Usage: lee $.session.usage(). Muestra el porcentaje de contexto, los tokens y la ventana con una barra. Muestra cada límite de tasa con el porcentaje usado y el tiempo de reinicio. Muestra el costo si el campo tiene un valor. Registra el conteo de tokens de cada turno en el hook session.measure y dibuja los últimos 30 turnos como un pequeño gráfico de barras. Usa Raster en la terminal y texto en otras superficies (revisa e.surface). 11. Model Router: muestra el modelo de la sesión principal y cada inicio de subagente con su tipo, su modelo y su estado. Tres modos en un Select: Off, Suggest, Auto. Off solo registra. Suggest muestra el modelo que las reglas seleccionan y no cambia nada. Auto establece el modelo de un subagente en el hook agent.spawn desde una tabla de reglas (tipo de subagente o palabra clave de tarea → modelo) que el usuario edita en el panel y que se guarda en $.store. Reglas: nunca cambies el modelo de la sesión principal, mantén un modelo que el llamador haya nombrado y deja que el inicio continúe sin cambios si una regla falla. Lee los nombres de los modelos de la sesión y la configuración. No escribas nombres de modelos en el código. El modo por defecto es Off. </mod> <mod name="ide-usage"> Una línea de estado con $.ui.status: "ctx 20% · <model>". Actualízala en el hook session.measure. Sin panel. </mod> <mod name="ide-statusbar"> Una línea de estado con $.ui.status: "<language> · <file name>" para el archivo que está abierto en el explorador, o el archivo que Claude leyó o editó por última vez. Deriva el lenguaje de la extensión del archivo. Muestra "Plain Text" para una extensión desconocida. Sin panel. </mod> <out_of_scope> - Pestañas de ventana para más de una sesión (por ejemplo ⌘1 y ⌘2). La aplicación de terminal las dibuja. Un mod no puede. - Un editor de texto completo en el panel. Un Input es de una línea. - Cambios en el prompt de permisos. Un mod no puede dibujar allí. No añadas características que no estén en este prompt. No añadas opciones de configuración que ninguna característica necesite. </out_of_scope> <safety> Un mod se ejecuta con los permisos del usuario y no está en un sandbox. Escribe código que un revisor cuidadoso acepte: - Confirma con $.ui.ask antes de eliminar, renombrar y confirmar. - Nunca ejecutes un comando git destructivo. Nunca apruebes una llamada de herramienta por el usuario. Nunca envíes contenido de archivos o prompts a la red. La herramienta Browser obtiene solo la URL que el usuario escribió o presionó. - No leas variables de entorno o configuraciones que una característica no necesite. "claude plugin validate" lista lecturas de env y llamadas; mantén esa lista corta. - Pasa argumentos a $.process como un arreglo. No construyas una cadena de shell a partir de nombres de archivos. Durante esta construcción, edita archivos solo dentro de este repositorio. No hagas push. No instales los plugins en mis configuraciones de usuario. Pregúntame antes de cualquier acción que sea difícil de deshacer. </safety> <workflow> Esta tarea es larga. Tu contexto se compacta automáticamente, así que no te detengas temprano para ahorrar tokens. Mantén el estado en archivos para que un contexto nuevo pueda continuar: - PROGRESS.md: qué está hecho, qué sigue y cada decisión con su razón. - tests.json: una entrada para cada prueba de aceptación con el estado not_started, failing o passing. - LIMITS.md: cada característica que la API instalada no puede hacer y qué construiste en su lugar. - Un commit de git por cada característica que pase. Al inicio de cada contexto nuevo: lee PROGRESS.md, tests.json, LIMITS.md y el registro de git. Ejecuta la suite de pruebas antes de añadir una característica. Fase 0, averigua. Ejecuta /plugin-authoring. Ejecuta "claude --version". Lee las páginas de documentación y el mod integrado "diff". Luego escribe PLAN.md: los eventos y métodos que cada característica usa, con la línea de los tipos que prueba que cada uno existe. Lista cada característica que necesita un diseño diferente. Muéstrame PLAN.md y continúa a menos que yo objete. Fase 1, andamiaje. Crea la estructura del repositorio, los cuatro manifiestos, los archivos hooks.json y archivos register.ts vacíos que registren solo sus comandos. Ejecuta "claude plugin validate --strict" en cada plugin hasta que pase. Luego detente y dame este comando para reiniciar con recarga en caliente: claude --plugin-dir ./plugins/file-explorer --plugin-dir ./plugins/workspace --plugin-dir ./plugins/ide-usage --plugin-dir ./plugins/ide-statusbar Después de que escriba "continue", lee los tipos generados en .claude-plugin/types/ y corrige PLAN.md. Fase 2, file-explorer. Construye en este orden: modelo de árbol y pestaña Files, búsqueda de archivos, pestaña Code con búsqueda, pestaña Diff, https://t.co/crzRXVIH3H. Escribe las pruebas para una característica antes de su código. Fase 3, workspace. Construye primero el navegador y el índice de sesiones. Luego construye las herramientas en el orden listado. Termina y prueba una herramienta antes de comenzar la siguiente. Fase 4, líneas de estado. Construye ide-usage e ide-statusbar. Fase 5, lanzamiento. Escribe marketplace.json, LICENSE y README.md. El README da: qué hace cada mod, los comandos de instalación (claude plugin marketplace add, claude plugin install <nombre>@MARKETPLACE), la versión de Claude Code que probaste, los comandos, los atajos de teclado, a qué puede acceder cada mod (de las líneas "hooks:" y "calls:" de validate) y el contenido de LIMITS.md. Ejecuta la verificación completa. Trabaja directamente. Usa un subagente solo para una búsqueda en muchos archivos que no necesite tu contexto. </workflow> <tests> Las pruebas se ejecutan con "claude plugin test" y no necesitan sesión ni red. Una prueba dispara eventos, presiona controles por clave y verifica el dibujo o el resultado. Simula $.fs, $.process, $.http y $.store. Escribe pruebas que verifiquen comportamiento, por ejemplo: - Una búsqueda de "auth" en un árbol simulado devuelve los archivos correctos, marca el texto coincidente y se detiene en 500. - ":42" selecciona la línea 42. "/re(fresh)?/" encuentra las coincidencias correctas. Una expresión regular inválida muestra una línea de error y no lanza. - Una pulsación en una fila de Source Control llama a https://t.co/crzRXVIH3H con tab "diff". - Run Tasks sin archivo de manifiesto muestra la línea "No task found". - Un programa git ausente da una línea clara y ningún error. - El índice de sesiones mantiene 200 sesiones y se fusiona con una escritura más reciente de otra sesión. - Model Router en modo Off y en modo Suggest devuelve next(e) sin cambios. Escribe código general que sea correcto para cada entrada válida. No escribas código que solo satisfaga una prueba. No elimines ni debilites una prueba para hacerla pasar. Si una prueba está mal o una característica no es posible, dímelo. </tests> <done_when> 1. "claude plugin validate --strict" pasa para cada plugin. 2. "claude plugin test" pasa para cada plugin, y tests.json no tiene ninguna entrada failing o not_started. 3. "tsc -p" en cada plugin no reporta errores contra los tipos generados. 4. Cada comando responde en "claude -p" (por ejemplo: claude -p "/explorer" --plugin-dir ./plugins/file-explorer) sin errores. 5. LIMITS.md lista cada diferencia con este prompt. 6. Me das una lista de verificación de los elementos que solo una persona puede comprobar en una sesión en vivo: cada panel se abre, los atajos de teclado funcionan y el diseño cabe a 110 y a 144 columnas. </done_when> <reporting> Después de cada fase, escribe un informe corto: qué construiste, los comandos exactos que ejecutaste, sus resultados y qué no está verificado. Separa "las pruebas pasan" de "lo vi funcionar en una sesión". Si no ejecutaste algo, di que no lo ejecutaste. </reporting> [fin del prompt]

Iniciá sesión para ver el prompt completo

Continuar con:

Al iniciar sesión, aceptás nuestros Términos de uso y Política de privacidad

Uso

Este prompt está diseñado para usarse con coding. Copiá el contenido de arriba y pegalo en tu herramienta de IA preferida.

Para mejores resultados, personalizá los marcadores (indicados con corchetes o mayúsculas) con tus requisitos específicos.

Referencias

Categorías:coding| twitter| claude-code| typescript

Discusión