Vector es un tablero de proyecto para un solo desarrollador. Lleva el registro de las specs que construís con Claude Code y las muestra en un kanban, donde cada idea es una tarjeta que avanza de estado conforme avanza el trabajo. No es una herramienta de equipo y no intenta reemplazar a Jira. Vive al lado del tracker que tu equipo ya usa.

Se enlaza con Jira, no compite con Jira
Una tarjeta puede llevar la referencia a su ticket externo. Corrés /vector:link con algo como ACME-142, acme/shop#231 o una URL completa, y Vector la interpreta, deduce el proveedor (Jira, Linear o GitHub Issues) y guarda el enlace en la tarjeta. La referencia aparece en el tablero y dentro de la spec.
Esa separación es justamente el punto. Jira sigue siendo la fuente de verdad del equipo: asignaciones, sprints, los campos de los que depende tu proceso. Vector es tu vista privada de tu propio trabajo, la capa desde donde de verdad manejás a los agentes. La referencia al ticket es el hilo entre los dos, así que tu tablero y el del equipo apuntan a lo mismo sin que ninguno sea dueño del otro.
Un solo estado JSON, dibujado en vivo
Vector se distribuye como un único binario de Go que incluye el CLI y un tablero web embebido. No hay toolchain de Node que instalar, ni base de datos que levantar, ni un servicio aparte que correr.
El estado es un solo registro JSON y el dueño es el CLI. El tablero es una proyección de ese registro, que se sirve al navegador y se actualiza en vivo por SSE. No existe una segunda copia de la verdad en un caché del frontend ni en una fila de base de datos, así que lo que muestra el tablero siempre coincide con lo que está en disco. El CLI escribe el estado; la vista web solo lo lee.
Una tarjeta es una spec
Cada tarjeta guarda una spec, no solo un título. /vector:raw <idea> convierte una idea en bruto en una spec estructurada (objetivo, contexto, alcance, flujo de usuario, etc.) y la registra como draft. De ahí la tarjeta pasa por open, in-progress, needs-attention, review y closed. Cada tarjeta lleva una marca de prioridad y el comando exacto que toca correr después, así que retomar el trabajo es copiar y pegar.

/vector:apply elige la siguiente tarjeta según estado y prioridad, y la implementa. Los comandos son archivos markdown que se siembran en tu repo bajo .claude, así que corren dentro de Claude Code como comandos del proyecto y viven al lado del código sobre el que actúan. Vector detecta una sola vez, durante vector init, tus comandos de build, test y lint, y los guarda, así que no depende de tu stack.
Enrutamiento de tokens
Vector trata el costo en tokens como una propiedad del flujo de trabajo, no como una limpieza para después. Cada comando corre en el modelo más barato que pueda hacer el trabajo. Un agente con Haiku escribe el resumen del standup y otros resúmenes triviales; un agente con Opus se encarga del diseño y la implementación. El tablero tiene una pestaña de Tokens para que el costo acumulado de cada spec se vea al lado del trabajo.
El standup sale del estado, no de la memoria
Como cada cambio queda registrado contra el estado JSON, Vector puede proyectar un standup en vez de pedirte que lo escribás. /vector:standup lee la actividad desde la última corrida y produce un resumen: qué se movió, qué salió, qué quedó marcado. Un agente barato convierte esa proyección en prosa.

Probalo
Vector es un solo binario. Instalalo, apuntalo a un repo y enlazá las tarjetas con los tickets que ya tenés:
curl -fsSL https://raw.githubusercontent.com/mcampbellr/vector/main/scripts/install.sh | sh
El código y los releases están en GitHub.