kb abrir | retoma un expediente: trae la documentación, abre la sesión y deja las ramas de trabajo listas |
kb agents | genera AGENTS.md y los prompts de Copilot |
kb alcance | qué se toca y qué ramas se van a crear |
kb apps | inventario de apps; con un término, resuelve el nombre |
kb apps verificar [APP] [--aplicar] | el inventario contra el código: lo que cada componente consume de verdad, rutas, base de datos sin scripts y lo que le falta a cada ficha |
kb preparacion [APP…] [--refrescar] [--estado] | qué le falta a cada app del requerimiento para que el agente lea y no explore: diez chequeos (ficha, confirmación, huecos, clasificación, índice, inventario, herramientas, referencias, E2E, estándares) escritos por app en preparacion-<APP>.md, con los pasos en orden y quién da cada uno; vence por fecha, por el código o por la ficha, y la reutiliza el próximo requerimiento |
kb apps actualizar [--ver] | fichas e inventario al formato de esta versión (lo hacen solos kb update y kb instalar) |
kb aprendizaje | anota lo que el requerimiento enseñó para la base de conocimiento —una regla de código, un estándar, un módulo o un componente nuevo, un término— o lo resuelve: --en-la-base <archivo> o --no-va "<porqué>" |
kb aprendizajes | lo aprendido en el requerimiento, lo que kbspec detecta y nadie anotó, y lo que la base tiene sin publicar; kb finalizar no cierra con algo pendiente |
kb aprobar | una persona aprueba un punto de aprobación —el alcance, la solución— o un documento, después de revisarlo: con el agente, lo escribe ella en el chat —«aprobado alcance»— y kbspec lo registra; desde una terminal, lo confirma ahí; firma con la identidad de la sesión del sistema y queda atada a la versión aprobada. --estado y --diff solo miran: cómo está cada aprobación, y qué cambió desde la aprobada (la busca en el historial de git) |
kb aprobaciones | los puntos de aprobación del expediente y cuál espera; antes de aprobar, qué falta y quién lo resuelve; detalladas para aprobar de a un documento |
kb cambio | con la implementación abierta, el cambio en curso: qué documentos aprobados cambiaron y todo lo que falta para aprobarlos juntos. listo arregla lo mecánico —las filas del tablero, la verificación y los casos de las tareas nuevas—, revisa todo junto y, si no falta nada, deja pedir una sola frase: «aprobado cambio» |
kb ejecucion | cómo se implementan las tareas: en paralelo (de fábrica con un 04: «aprobado solución» lanza el lote) o secuencial, de a una |
kb aceptar | una persona acepta una brecha o un hallazgo con su motivo —«acepto RF-03: por qué»—: deja de frenar y queda en el rastro |
kb revision | la vista de revisión de un punto de aprobación, en HTML; con --hallazgo, el agente registra lo que encontró leyendo |
kb vigente | lo que vale hoy de la captura, calculado: decisiones vigentes, preguntas, supuestos e insumos |
kb impacto | qué revisar si cambia una decisión, una regla o un requisito |
kb arquitectura | compara la ficha de arquitectura contra el código; <APP> --ver, la página de su arquitectura —componentes, plataforma, lo decidido, lo que falta y sus épicas— |
kb auditoria | bitácora de auditoría del expediente: qué se corrió y quién |
kb informe [TICKET] | cómo se comportó kbspec en el requerimiento, en un .md para que lo analice una IA (no registra nada nuevo) |
kb ayuda | referencia rápida; —web abre la guía con diagramas; con imprime solo esa sección de AYUDA y CONVENCIONES |
kb bitacora | siembra en el 05 la entrada de una tarea con lo que git y el expediente ya saben (archivos, commits, evidencias) |
kb cerrar | publica el trabajo (expediente y código) y cierra la sesión |
kb check | verifica requisitos, instalación y puesta a punto de este repositorio |
kb init-repo --pipeline | escribe azure-pipelines-kb-pr.yml con las ramas de la estrategia (la de producción de ese repositorio y las de integración): el check kbspec/expediente como Build Validation |
kb apps nueva <NOMBRE> · --desde <captura> [--aplicar] | ¿de verdad es nueva? · dar de alta una aplicación, módulo o componente que todavía no existe: inventario por crear, ficha con lo decidido y portada de la guía funcional |
kb apps repo <COMP> [--crear] | el repositorio de un componente por crear: dónde va, su rama y el comando para el servidor; --crear, la carpeta con git y kbspec |
kb apps editar <CÓD> --estado activo | quitar la marca por crear cuando el código existe |
kb apps editar <APP> --rama-base <rama> | la rama de producción de un componente, si no es la de la estrategia (main de fábrica) |
kb diagnostico | adónde se fue el tiempo en las sesiones del agente, las herramientas que corrieron sin compuerta, las relecturas, cada gancho por dentro y —con --medir— cuánto tarda la máquina en arrancar cada cosa; termina con qué conviene |
kb punto · kb diff --desde · kb volver | puntos de restauración: una foto del código en cada aprobación y cada tarea; qué cambió desde ahí; volver (lo decide la persona) |
kb git <lo de git> | un git sin vuelta atrás (reset --hard, clean -f, push --force, --no-verify…), confirmado por la persona en la ventana de kbspec: el gancho se lo niega al agente y le propone esto |
kb check --ganchos | si las compuertas actúan en la máquina: cuánto tardan los ganchos, cuántos pasaron de 30 s, las veces que kbspec contestó por plazo, las sesiones que quedaron esperando a la persona y las herramientas que la compuerta no reconoce |
kb check --seguridad | lo que un auditor pregunta de la máquina: escapes puestos, permisos de las credenciales, a qué servidores irían, qué sale a internet — sin mostrar un valor |
kb check --voz | qué le falta a la máquina para dictarle a kbspec con el dictado de VS Code: versión, políticas, ajustes y el modelo. Hablarle a kbspec |
kb check --studio | si la máquina cumple con kbspec Studio: extensiones y si la política las deja, el perfil, las políticas de VS Code y las managed settings de Copilot, los ganchos de kbspec gestionados o sueltos, el plugin y el servidor MCP |
kb checklist | preguntas a responder según lo que el cambio toca |
kb configuracion | todo lo que kbspec tiene configurado, en un lugar |
kb configuracion --item <id> · --wiki | un ítem de la puesta a punto · la página del wiki |
kb configuracion descubrir [<carpeta>] [--app X] | lo que el código y git contestan de la puesta a punto —aplicaciones, partes, stack, pruebas, responsables, plataforma, prefijo, ramas—, con su certeza y las preguntas para una persona; no escribe nada (/kb-configurar lo conduce) |
kb configuracion --prefijo <PREFIJO> | el prefijo de los tickets, anotado en ~/.kb/config |
kb configuracion probar · diff <ARCHIVO> | lo que la configuración no dice como está escrita (defectos que no existen, filas descartadas, claves que no se leen) · qué mejoró el framework en una semilla |
kb estandares | los estándares de programación: base recomendada, lo que hace el código, el documento interno y su calidad |
kb estandares base|detectar|revisar|importar | la base de una tecnología (y --comparar con el código) · lo que el código ya hace · lo que le falta a cada regla · el documento de la casa, para citarlo |
kb ciclo | el ciclo que rige para el equipo: por fase, su nombre, el agente que la lleva, la compuerta y los pasos propios (aplicaciones/CICLO.md) |
kb lote | las tareas del plan en olas para correr en paralelo: qué va junto, qué lo impide y en qué estado está cada una |
kb lote preparar|correr|verificar|integrar|final | un árbol y una rama por tarea con su brief · los agentes con la CLI de Copilot · la verificación de cada tarea en su árbol · el merge a la rama de trabajo · todo junto |
kb lote revisar [--cerrar] | la revisión del conjunto integrado: el paquete, los choques entre tareas y, con --cerrar, una tarea de corrección con lo abierto |
kb lote autorizar --hasta <créditos> | una persona autoriza el lote sin supervisión, para este plan y hasta un tope de créditos —en el chat, «aprobado lote <créditos>», que aprueba también el plan—; sin eso kb lote correr no lanza nada |
kb lote informe | el veredicto de un lote: en paralelo o no, cuánto más rápido, verificado e integrado, qué modelo usó cada tarea y cuánto costó, según los registros de Copilot (ventana de agentes y chat) |
kb lote demo --modelo <id> | una prueba armada en una carpeta propia para validar en esta máquina que las tareas corren en paralelo con ese modelo, sin tocar la configuración real |
kb plugin empaquetar|probar|activar|desactivar | kbspec como plugin de agente (Agent Plugins 1.0), a pedido: el marketplace con lo que rige para el equipo, su revisión, y su activación en .github/copilot/settings.json — la instalación de siempre no cambia |
kb studio [perfil|plantillas] | kbspec Studio, sin fork de VS Code: el perfil de VS Code (kbspec.code-profile: extensiones del stack, los ajustes de kbspec y la tarea del árbol) y las políticas para TI —VS Code en sus tres formatos y las managed settings de GitHub, con su LEEME—. Solo genera archivos |
kb ciclo aprobar|correr|probar | una aprobación con --por (una persona) · el comando de un paso, con su evidencia · lo que no va a funcionar como está escrito |
kb configuracion fijar|verificar|personalizar | cambiar un valor · la confirmación de una persona · crear un archivo con su contenido de fábrica |
kb contexto | qué leer antes de tocar una app, y si sigue vigente |
kb investigar | una duda que solo responde el código, en cualquier fase: abre la nota investigaciones/I-NN con el plan de lectura |
kb investigacion | listo I-NN le muestra al developer el resumen y el archivo; decidir I-NN referencia|no-aplica|incorporar (de la persona); nueva (los tres caminos sin requerimiento), abrir/cerrar/convertir INV-…, traer <origen> |
kb investigaciones | las investigaciones del expediente, con su estado y su decisión |
kb contratos sembrar|buscar | los contratos de una API desde su OpenAPI —el que el código ya tiene, sin levantar el servicio—, o una operación sola |
kb deriva | compara el análisis con lo realmente modificado (las pruebas y la documentación no son deriva) |
kb desinstalar | quita el framework de esta máquina |
kb diario | el insumo del standup: quién tiene qué, qué se movió y qué está trabado |
kb elicitar | métodos de razonamiento para un segundo pase sobre un documento antes de aprobarlo (pre-mortem, inversión, red-team…) |
kb empaquetar | arma el paquete limpio para publicar o compartir |
kb epica | una iniciativa que se entrega en partes, no de una vez |
kb epica EP-NNNN partes --desde <json> [--aplicar] · revisar | varias partes de una vez · si está lista para arrancar (horizontales, L, cimiento) |
kb epica EP-NNNN fundamentos [--aprobar] · interfaz [--ver] | lo que hace falta para empezar a programar una app nueva, en el inventario · la guía visual de la app |
kb epica EP-NNNN requerimientos [--tickets …] [--temporales] [--aplicar] | un requerimiento por parte, ligado a la épica y por tomar (kb abrir) |
kb epica EP-NNNN tablero [--wid N | --crear] · prototipo | la épica en el tablero, con sus requerimientos debajo · el prototipo de cada parte |
kb camino | antes de kb init: si la app existe, está por crear o no está, si hay una épica con partes libres, el tamaño (o la épica) con su porqué y los pasos |
kb partir | un requerimiento que creció se vuelve épica: el de la sesión queda como su primera parte |
kb erd | diagrama de entidades desde las fichas EN (opcional) |
kb estadisticas | por sprint, mes o año: requerimientos, entregados, tokens, costo y devs |
kb estado | qué expediente está abierto, en qué punto va y a qué sprint pertenece (el de su work item) |
kb estrategia | estrategias de ramas: cuáles hay, cuál rige, cuál usar |
kb estructura [<APP>] | dónde va cada cosa nueva y qué ya hay ahí — antes de crear un archivo o carpeta |
kb bandeja | los requerimientos abiertos en esta máquina y lo que espera cada uno (—json) |
kb comentarios | lo que G-Bot, la revisión y DBA dicen del código, con archivo y línea (—json) |
kb expedientes | lista los requerimientos y su estado (—json) |
kb preguntar "<pregunta>" [--app X] [--tipo …] | contesta con las secciones que responden —guía funcional, reglas, ficha, inventario, glosario— y su fuente; --exportar <archivo.jsonl> lo deja todo para otro asistente |
kb funcional [<APP>] [sembrar [--completar]] · guia | la guía funcional de una aplicación: qué le falta · el esqueleto desde el inventario y las pantallas del código · el manual del formato |
kb buscar <texto…> | busca DENTRO de los documentos — «¿alguien ya resolvió esto?». Se piden todas las palabras, sin importar tildes; entre comillas, la frase exacta (--todo, --json) |
kb exportar | insumos curados para componer un exporte personalizado (presentación, resumen ejecutivo, modelo de datos) |
kb ficha sembrar|compactar|cosechar|guia | la ficha de arquitectura: sembrarla con la evidencia del código, dejarla en solo datos, proponer sus huecos desde las reglas del equipo, y su manual por sección |
kb finalizar | da el requerimiento por terminado: verifica, marca ENTREGADO y COMPLETADO, publica y cierra |
kb flujo | ritmo real de entrega: ítems cerrados por sprint (throughput) |
kb grafo | grafo navegable de la base de conocimiento (visor OKF) |
kb hoja | la hoja de aprobación de cada repositorio: qué evidencia se le exige y cómo salió |
kb hook | lo ejecuta VS Code al cerrar una fase (Agent Mode) |
kb html | genera expediente.html por demanda para leer y revisar — con el ciclo y el impacto ya dibujados; kb publicar no lo genera |
kb html --indice | todo el repositorio en dos páginas navegables con barra lateral y buscador: configuracion.html y requerimientos.html; rehace además el expediente.html de TODOS los requerimientos |
kb ids | los identificadores del expediente como símbolos de código: dónde se define cada uno (archivo, línea, texto), quién lo cita, con qué se relaciona y su brecha — lo que usa el editor para ir a la definición, ver las referencias y autocompletar |
kb uat importar | vuelca al 07 el archivo que devolvió el usuario |
kb init | crea el expediente de un requerimiento y abre la sesión |
kb instalar | deja la máquina lista y la vuelve a dejar lista: detecta, pregunta lo que falte, prepara cada repositorio (kb update hace lo mismo) |
kb init-docs | crea el repositorio central de DOCUMENTACIÓN |
kb init-repo | prepara un repositorio de CÓDIGO |
kb insumo | registra en entradas/ un documento del usuario; si trae tarjetas, cuentas IBAN o secretos entra enmascarado (o no entra) |
kb interfaz | ficha de interfaz de una app: la redacta leyendo el código |
kb libre | una persona habilita escribir código sin requerimiento abierto en este repositorio, por unas horas (--estado, --cerrar); sin eso, la compuerta lo niega con cualquier agente |
kb listo | ¿el expediente está listo para implementar? veredicto consolidado antes de la fase 5 |
kb mapa construir|buscar|similares|vecindario|estado|indice|receta | el mapa estructural de una app: qué archivo hace qué y qué está conectado con qué —del componente a la tabla, entre lenguajes—, con la confianza de cada vínculo y su vigencia contra tu copia, sin recorrer el repositorio |
kb mcp | servidor MCP: expone la base de conocimiento a cualquier agente; publica las herramientas de la fase del requerimiento abierto —kb mcp --herramientas dice cuáles—, y todas con KB_MCP_TODAS=1 |
kb metricas | cómo va el proceso: flujo, calidad y adopción |
kb modelo | qué clase de modelo conviene en cada fase, y por qué |
kb panel | todo lo que el panel de VS Code pinta, en un solo JSON |
kb paralelo | prepara una carpeta aparte (git worktree) para trabajar OTRO requerimiento en paralelo, con su propia rama |
kb pase | fija o cambia el pase (PN) del expediente — mueve la fila entre pases/*.md |
kb perfil | perfiles de documentación: cuánto se escribe en cada fase |
kb plan-uat | genera el plan de pruebas EN BLANCO para el usuario final — después de kb pr aprobado |
kb prueba-ciclo [--app portal|simple] [--escenarios …] [--presupuesto USD] [--motor claude|copilot] [--hasta <fase>] [--continuar] [--limpiar] | la prueba del ciclo completo, sola: arma una carpeta propia —de fábrica, un portal Angular con módulos federados y tres APIs .NET— y lleva un requerimiento de la solicitud al borrador del PR con el agente de siempre; kbspec hace de persona, corre escenarios del ambiente (APIs caídas o con errores, un módulo sin servir, todo ya levantado) y deja un diagnóstico (tiempos por fase, comandos lentos, compuertas, escenarios, costo) en <carpeta>/diagnostico/ |
kb plantillas | plantillas del expediente: personalizarlas sin bifurcar el framework, ver si el framework las adelantó, y abrir desde ellas el documento de cada fase (abrir, completar) |
kb pr | arma el Pull Request con las ramas, el work item y los revisores ya resueltos — en el proyecto del código, con enlace a cada evidencia y las capturas incrustadas |
kb pr estado --publicar | el check kbspec/expediente en el PR del código: verde si el expediente lo respalda (trazabilidad, tareas, P0, rastro), rojo con los motivos; una política de rama lo puede exigir |
kb pr plantilla [--escribir] | la plantilla del equipo para este PR, resuelta (aplicaciones/pull-requests/) |
kb pr --hacia <rama> · --repositorio <URL> | el PR de otro salto de la cadena · la URL del repositorio cuando el remoto no la dice |
kb pr gbot leer --esperar [--de ARCHIVO] | trae del PR la revisión de G-Bot apenas la publica —o, con --de, la importa de un archivo guardado a mano— —solo los issues: las sugerencias de mejora se cuentan y no se implementan—, con el número con que G-Bot va a contar cada uno |
kb pr gbot decidir <#> --aplica|--no-aplica --porque "…" | la decisión de cada issue; un «no aplica» exige la justificación técnica |
kb pr gbot responder [--publicar] | arma la respuesta con todos los issues —en la forma que lee el seguimiento de G-Bot, una sola sección—, la verifica como la va a leer G-Bot y la muestra; con --publicar la publica la persona, exactamente lo que se mostró |
kb pr gbot cerrar | sin issues en la última revisión de G-Bot: escribe la evidencia E08 desde los datos de cada ronda |
kb pr hilos leer · decidir <#> --aplica|--no-aplica --porque "…" | los comentarios del revisor en el PR, uno por uno, con el mismo ciclo que G-Bot |
kb pr cambios --hilos | una tarea T-R por cada comentario del revisor que aplica (lo confirma la persona) |
kb pr hilos responder [--publicar] | responde cada hilo —con la tarea y el commit— y lo marca Resuelto o No se corregirá; lo publica la persona |
kb vb | el visto bueno de los scripts de base de datos con el equipo de DBA, después del PR aprobado: dónde está el trámite |
kb vb preparar [--adjuntos N] | reparte los scripts del ticket en partes —ningún objeto partido, en orden de dependencias, y recién entonces el tope de adjuntos— y escribe el documento de cada una con la plantilla del equipo (aplicaciones/VISTO-BUENO.md) |
kb vb solicitar | una tarea por parte en el tablero de DBA (vb_proyecto) con los scripts adjuntos —cada uno enlazado desde el orden de ejecución—, el pase como etiqueta y la iteración vigente de ese tablero; lo confirma la persona |
kb vb leer · analizar [#…] · decidir <#> --aplica|--no-aplica --porque "…" [--segun "…"] | las observaciones de los DBA (texto de un tercero: se señala lo que da órdenes y no se ejecuta nada) y el estado de cada tarea; la ficha de cada una contra el 02, el 03 y el estándar de BD; la decisión con su respaldo —lo que aplica abre la ronda de corrección (T-C)— |
kb vb responder [--publicar] · cerrar | la respuesta de cada tarea, que publica la persona después de leerla (los scripts que cambiaron reemplazan al adjunto anterior y el comentario lo dice); con todas las partes aprobadas, la evidencia, el 00, el 08 y el work item del requerimiento |
kb sqlproj [--requerimiento PN-X] | el proyecto SQL de Visual Studio (.sqlproj) sincronizado desde los scripts del ticket —solo los objetos que ellos tocan, nunca la base compartida—: la vista previa con el diff |
kb sqlproj --aplicar [--aprobar-eliminaciones] | escribe lo del plan y lo incluye en el .sqlproj; los DROP solo con aprobación; si la compilación falla, restaura todo. Sin commit ni PR |
kb sqlproj descubrir <carpetas…> --config <archivo> | qué .sln, .sqlproj y carpetas de scripts hay, y el borrador de aplicaciones/<APP>/sqlproj.json |
kb precios | tarifas por modelo; —actualizar las trae de GitHub |
kb pronostico | cuántos ítems por sprint, o cuántos sprints para N — Monte Carlo |
kb prototipo | vista previa del diseño de pantallas (opcional) |
kb prototipo --explorar | El prototipo antes de que haya qué especificar: tres variantes que discuten la estructura, para un módulo nuevo |
kb prototipo --comportamiento | Para cuando la pregunta es cómo se comporta y no cómo se ve: un flujo que se aprieta, con recorridos guiados |
kb prototipo --decidir | Cierra la ronda: qué variante ganó, qué preguntas contestó y cuáles abrió, de vuelta en el expediente |
kb prototipo --capturar <URL> | abre la pantalla con ventana, deja elegir un elemento con el mouse y guarda su HTML, estilos computados y un recorte — para cuando no hay prototipo contra el cual medir |
kb pruebas | corre los comandos de la ficha y guarda la evidencia |
kb publicar | commitea y sube el expediente para que otros lo vean |
kb publicar-base | publica solo los cambios compartidos (inventario, plantillas, estándares, skills) sin un requerimiento |
kb ramas | deja la rama de trabajo lista en cada repo del expediente |
kb uat reabrir | hallazgos en staging: abre la ronda de corrección (tareas nuevas, fase atrás, otro PR) |
kb recursos | la base de conocimiento como documentos adjuntables |
kb refinamiento | el acta ítem por ítem: nueva, sesion, verificar (ticket y pase), ejecutar (de la persona: comenta o crea el ticket), pendientes, ticket, tomar (crea el expediente y exige el pase), y consumo |
kb renombrar | el ticket temporal pasa al real: carpeta, documentos, pase, índices y sesión, con el renombre en el rastro |
kb voz | el paquete del modelo del dictado de VS Code: TI lo publica (publicar), cada developer lo trae verificado (instalar) |
kb traslado | exporta un requerimiento —documentos y código— en un paquete, y lo importa en otro ambiente de kbspec |
kb reparar-docs | deja en orden el repositorio de documentación si una publicación lo dejó a medias (conflictos, rebase, stash): lo que kbspec rehace solo se arregla solo, lo que escribió una persona se nombra y no se toca |
kb reporte-pruebas | exporta unitarias + E2E (con capturas) + plan: html/docx/pdf |
kb solicitud | trae al 01 lo que la tarea del tablero ya dice (descripción, criterios de aceptación, área, solicitante), sus comentarios y sus adjuntos (a entradas/); lo que no se puede bajar se dice para registrarlo a mano — kb init lo hace solo |
kb retro | crea la retrospectiva de una épica (qué se entregó, qué se aprendió, qué se promueve a la base de conocimiento) |
kb revisar | dependencias vulnerables del requerimiento |
kb revisar --paquete | deja el diff a revisar en un archivo por componente, para pasarle la ruta a cada lente en vez del contenido |
kb revisar --cruzada [--modelo X] · --cruzada --registrar | a pedido, apagada de fábrica: revisar con un modelo de otra familia que la que escribió el código (y que la clasificación del dato permita); --registrar deja la E09 con quién revisó |
kb revisar --hallazgo "…" · --hallazgos · --cerrar R-NN · --descartar R-NN | anota los hallazgos de la revisión de código en el 05 (antes vivían solo en el chat). Un hallazgo Alta abierto frena kb pr; descartar exige el motivo |
kb skills | las skills del equipo —del framework, propias y modificadas— y lo que hay que decidir después de un update |
kb skills nueva|modificar|habilitar|deshabilitar <nombre> | el administrador las cambia en el repositorio de documentación; llega a todos con kb update y un update del framework no lo pisa |
kb skills reglas | las reglas duras de cada skill, con su porqué |
kb spec | ¿el 02 dice lo suficiente y de forma verificable? Requisito por requisito: criterio de aceptación, ejemplo de cada regla con fórmula, y nada apoyado en un adjetivo sin cuantificar |
kb skills probar --emitir | los escenarios de presión que ponen a prueba esas reglas; --resultado <json> dice cuáles aguantaron |
kb skills probar --correr [--modelo <id>] [--veces N] | los mismos escenarios, corridos solos con la CLI de Copilot en una carpeta limpia y con la skill como instrucciones; aguanta si todas las corridas eligen bien |
kb sistemas | qué componentes toca el expediente (los que ramifica kb ramas): los fija en todos sus documentos |
kb tablero | verifica el tablero (Azure DevOps) y descubre sus estados |
kb tarea | inicia, cierra (--hecho, con la compuerta) o reabre tareas del plan |
kb tokens | cuánto consumió el requerimiento, por fase |
kb chat | el chat exportado por VS Code, guardado en el expediente |
kb uat | resultados de la validación del usuario |
kb update | actualiza el framework |
kb usuarios | usuarios de prueba de una app (para elegir con cuál correr) |
kb lectura | las copias de lectura de los requerimientos: cuánto ocupan; limpiar borra las olvidadas |
kb validar | audita el expediente; código ≠ 0 si hay brechas |
kb ventana | el requerimiento abierto en su ventana: arma su workspace y lo abre, si conviene |
kb version | muestra la versión |
kb wiki | la URL del wiki que enlazan los PR: detectarla, escribirla o publicar el wiki |
kbspec es un producto de Kabata Soft contacto@kabatasoft.com © 2026 Kabata Soft S.A. Todos los derechos reservados.