From B Pipeline
Convierte el HISTORIAL de la conversacion (o un plan/PRD/doc) en uno o varios GitHub issues bien scopeados, sliceados en VERTICAL (tracer-bullet), con dependencias y un epic de tracking — listos para drenar con b10-ship --epic. Es el paso GENESIS del pipeline, antes de b1-triage. Usar cuando el usuario diga "crea el/los issue(s) de esto", "convierte esto en issues/tareas", "arma las tareas en github", "saca los issues de lo que hablamos", "abre los tickets de esta conversacion", "turn this into issues", "create issues from this conversation/plan", "break this into tickets", "split this into vertical slices". Tambien cuando una sesion de diseño/brainstorm/planificacion converge en trabajo concreto que hay que registrar. Antes de crear NADA verifica con el usuario lo que REALMENTE pide (gate humano). NO implementa codigo, NO triagea, NO abre PRs — solo produce la estructura de issues que el resto del pipeline procesa.
How this skill is triggered — by the user, by Claude, or both
Slash command
/b-pipeline:b0-conversation-to-issuesopusThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Paso **b0**: el genesis del pipeline. Toma lo discutido en la sesion y lo deja como **issues de GitHub bien formados**, **sliceados en vertical**, **ordenados por dependencia** y agrupados bajo un **epic** — exactamente la forma que `b10-ship --epic=<N>` sabe drenar. No construye nada: produce el input del resto del pipeline (b1 → … → b10).
Paso b0: el genesis del pipeline. Toma lo discutido en la sesion y lo deja como issues de GitHub bien formados, sliceados en vertical, ordenados por dependencia y agrupados bajo un epic — exactamente la forma que b10-ship --epic=<N> sabe drenar. No construye nada: produce el input del resto del pipeline (b1 → … → b10).
En este proyecto "tarea" = issue de GitHub. Trato ambos como sinonimos.
context: fork — a propositoEste skill corre en el main loop, NO en fork. Es deliberado y critico: la fuente de verdad es el historial de la conversacion actual, y un fork solo ve el cuerpo de este SKILL.md (no la sesion). Forkear este skill lo dejaria ciego a lo unico que necesita leer. Tambien necesita AskUserQuestion con el usuario presente para el gate de verificacion.
El trabajo de razonamiento (destilar la necesidad, slicear, ordenar olas, el gate) se queda en el main loop por la misma razon. Lo que SI se delega a subagentes —siempre trabajo acotado y read-only o mecanico, posterior a las decisiones— es: el grounding en el codebase (Paso 2, opcionalmente en paralelo) y la redaccion de bodies ya aprobados (Paso 6, en paralelo para breakdowns grandes). Ningun subagente decide el slicing.
[--from=<archivo>] leer ADEMAS un plan/PRD/spec/doc como fuente (se combina con la conversacion)
[--scope=<area>] hint de scope para labels y rama (ej. productos, ventas, auth)
[--epic-title="..."] titulo explicito del epic; si falta, se deriva del tema
[--no-epic] no crear epic de tracking (issues sueltos; usar solo con 1-2 issues independientes)
[--lang=es|en] idioma de los issues; default autodetectado de la conversacion
[--cluster-hint] marcar slices secuenciales del mismo scope como cluster sugerido para b8-swarm
[--yes] saltar el gate de confirmacion (power users); por default el gate es OBLIGATORIO
[--dry-run] llegar hasta el preview y NO crear nada en GitHub
Argumentos recibidos en esta invocacion:
$ARGUMENTS
El placeholder
$ARGUMENTSes la via por la que llegan los flags tipeados — el harness lo sustituye. Si aparece vacio, usar defaults (fuente = conversacion, epic on, lang autodetectado).
Esta es la decision de diseño central del skill — y donde mas se equivoca un modelo. Cada issue debe ser una rebanada vertical end-to-end: algo que un usuario puede usar al mergearse, atravesando todo el stack (Drizzle → remote function → pantalla). NO una capa tecnica.
| Slice VERTICAL (correcto) | Capa HORIZONTAL (incorrecto) |
|---|---|
"Listar productos en /productos" (DB + get_products + +page.svelte) | "Crear el schema Drizzle de todo el modulo" |
| "Crear/editar producto con formulario upsert" | "Escribir todas las remote functions" |
| "Eliminar producto con confirmacion" | "Maquetar todos los componentes UI" |
| "Filtrar y buscar en el listado" | "Conectar el front al back" |
Por que vertical: cada slice = un PR de b7 = entrega valor verificable en el browser por si solo. Las capas horizontales no se pueden revisar visualmente, no cierran nada util, y rompen el modelo screen-first del plugin (b2/b7 construyen y revisan por pantalla, no por capa).
El primer slice es el tracer bullet: el camino mas delgado que ejerce todo el stack de punta a punta (tipicamente "listar X read-only" — una query, una pantalla, auth). Prueba que la arquitectura cierra. Los slices siguientes agregan una capacidad encima (crear, editar, borrar, filtrar, exportar…), cada uno dependiente del tracer.
Cada slice debe caber en un PR de b7: simple (3-5 archivos) o medium (5-8). Si un slice pinta complex (8-15+), partirlo en mas slices — el bot no construye complex sin gate, y un issue gigante no es un buen slice. Mejor 4 slices simples que 1 complex.
Antes de crear nada en GitHub, confirmar con el usuario. Esto es ADN del plugin (igual que b1-triage entiende antes de construir, y b9 nunca mergea sin un humano): registrar mal una conversacion propaga el error por todo el pipeline. Un issue mal scopeado se construye, se revisa y casi se mergea antes de que alguien note que no era lo pedido.
El gate distingue lo que se dijo literalmente de el objetivo real. La gente describe soluciones ("agrega un boton que…") cuando el problema es otro ("no puedo encontrar mis pedidos atrasados"). El slicing debe atacar el objetivo, no transcribir frases.
Mecanica del gate (Paso 5): presentar en texto el entendimiento + el breakdown propuesto (epic + slices + orden de olas), y recien ahi usar AskUserQuestion para confirmar / ajustar / corregir. No crear issues hasta tener el OK. Con --yes se omite (power users que confian en el breakdown), pero el default SIEMPRE confirma.
Releer la conversacion de esta sesion (y --from=<archivo> si se paso) y destilar:
Regla dura: no agregar requisitos que no esten en la conversacion o el doc. Si algo falta para slicear bien, es material del gate (preguntarlo), no para rellenar de oficio.
Para que los issues nombren rutas/entidades REALES (no inventadas), un grounding breve — mismo espiritu acotado que b1-triage (grounding, no exploracion exhaustiva):
rg -l "<entidad>" src/routes src/lib/server/db/schema.scope:<area>).Para entidades multiples o un codebase desconocido, delegar el grounding a Agent(subagent_type=Explore) para no gastar el contexto principal — y paralelizar cuando hay varias entidades:
Agent(Explore) acotado ("ubica las rutas y tablas de X, Y, Z; reporta paths exactos").Agent(Explore) en paralelo (todos en un mismo mensaje, un agente por entidad o par de entidades cohesivas), cada uno con encargo cerrado: "¿existe src/routes/<area>? ¿que tabla Drizzle la respalda? reporta paths exactos o 'no existe'". Read-only y disjuntos → seguro en paralelo, y corta el wall-clock de N busquedas secuenciales. Cap razonable: ~6 agentes.El grounding es read-only: no decide nada, solo devuelve paths reales para que el slicing nombre rutas/tablas que existen (o confirme que son nuevas). Consolidás los reportes en el main loop antes de slicear.
Si
.codegraph/existe en el proyecto, preferircodegraph_searchpara ubicar entidades/rutas — mas rapido que grep, y suele evitar el fan-out (una consulta cubre varias entidades). Pasarle a cada Explore la instruccion de usar codegraph.
Aplicar el principio de arriba. Para CADA slice definir:
s1-list, s2-upsert) — interno, lo usa el plan para deps.feat(scope): …, fix(scope): …).feature|bug|enhancement + scope:<area> (+ simple|medium como hint; b1-triage reconfirma).Detalle del cuerpo del issue: ver references/slicing-guide.md (template + ejemplo completo). Leer ese archivo solo al momento de redactar los bodies.
Asignar blocked_by (lista de slice-ids) a cada slice:
Esto se materializa como la seccion ## Blocked by en cada body (el script la inyecta resolviendo ids → #numeros reales). Es la MISMA convencion que epic-graph.sh de b10 parsea para calcular olas y el closing_slice.
Cluster (opcional): si ≥2 slices son secuenciales, del mismo scope, simple|medium, y conviene un PR combinado, marcarlo como cluster (con --cluster-hint) para sugerir luego b10-ship --epic --cluster (que invoca b8-swarm). Slices de scopes distintos NUNCA van al mismo cluster.
Presentar al usuario, en texto:
Luego AskUserQuestion con opciones del tipo:
Iterar hasta el OK. Con --yes, saltar este paso. Nunca crear antes del OK.
Escribir el plan JSON a un scratch (ej. "$(mktemp -t b0-plan.XXXX).json") con el schema que documenta scripts/create-epic.sh:
{
"lang": "es",
"epic": { "title": "Epic: <tema>", "labels": ["scope:<area>"], "closing_slice": "epic" },
"issues": [
{ "id": "s1-list", "title": "feat(<area>): …", "body": "<markdown SIN ## Blocked by>",
"labels": ["feature", "scope:<area>", "simple"], "blocked_by": [] },
{ "id": "s2-upsert", "title": "feat(<area>): …", "body": "…",
"labels": ["feature", "scope:<area>", "medium"], "blocked_by": ["s1-list"] }
]
}
Las deps van SOLO en
blocked_by(ids), no escribir## Blocked byni#numerosen elbody— esos issues aun no existen; el script inyecta la seccion resolviendo ids → numeros reales.closing_slice: "epic"hace que el epic dependa de TODOS los subs y se vuelva el slice de cierre de b10 (build ultimo, tras epic-review). Util cuando el cierre del epic incluye limpieza/swap. Si no aplica,null. Con--no-epic: omitir la claveepic(issues sueltos, sin linkeo).
El cuerpo de cada slice es independiente: distinto archivo, distinta pantalla. El slicing (objetivo, deps, olas) es la parte dificil y ya quedo fijado y aprobado en el gate; redactar los markdown es trabajo mecanico que sigue el template de references/slicing-guide.md.
Workflow — un agent() (haiku/sonnet) por slice. Cada agente recibe lo MISMO para no divergir: (a) el template del slicing-guide, (b) la lista completa de slices (titulo + alcance de cada uno) para que su seccion ## Alcance referencie bien lo que queda para OTROS slices, (c) los grounding facts (rutas/tablas reales del Paso 2), (d) el idioma. Devuelve {id, body}. El main loop ensambla los bodies devueltos en el array issues del plan JSON. Cap de paralelismo razonable: ~8.export const meta = {
name: 'b0-draft-bodies',
description: 'Redaccion paralela de los bodies de slices ya aprobados en el gate',
phases: [{ title: 'draft', detail: 'un agent() por slice, read-only sobre la conversacion ya destilada' }],
}
const A = (typeof args === 'string') ? JSON.parse(args) : (args || {})
const BODY = { type: 'object', required: ['id', 'body'],
properties: { id: { type: 'string' }, body: { type: 'string' } } }
phase('draft')
const bodies = (await parallel(A.slices.map(s => () =>
agent(
`Redacta SOLO el body markdown del slice "${s.id}" (${s.title}). ` +
`Segui EXACTO el template de references/slicing-guide.md. Idioma: ${A.lang}. ` +
`Grounding (rutas/tablas reales): ${A.grounding}. ` +
`Para la seccion "## Alcance (slice vertical)", estos son los OTROS slices del epic ` +
`(lo que queda para cada uno): ${JSON.stringify(A.slices)}. ` +
`PROHIBIDO escribir "## Blocked by" o #numeros — las deps las inyecta el script. ` +
`Devolve {id:"${s.id}", body:"<markdown>"}.`,
{ label: `body:${s.id}`, phase: 'draft', schema: BODY }
)
))).filter(Boolean)
return { bodies }
Invocacion: Workflow({ script:<lo de arriba>, args:{ slices:[{id,title,scope}], lang:'es', grounding:'<resumen Paso 2>' } }). Tras recibir {bodies}, mapear id → body y completar cada issue del plan. El slicing NO se delega — los agentes solo escriben prosa de slices que vos ya decidiste; no inventan slices nuevos ni cambian deps.
Correr el preview (no toca GitHub):
PLUGIN_ROOT="${CLAUDE_PLUGIN_ROOT:-$HOME/.claude/skills/b-pipeline}"
B0="$PLUGIN_ROOT/skills/b0-conversation-to-issues/scripts/create-epic.sh"
bash "$B0" "$PLAN_JSON" --dry-run
Mostrar el arbol de olas. Si --dry-run global: parar aca, reportar el path del plan para inspeccion, emitir B0_DONE … mode=dry-run.
bash "$B0" "$PLAN_JSON"
El script: asegura labels, crea cada sub-issue resolviendo deps, crea el epic (rollup) y vincula los sub-issues nativos via epic-link.sh. Es idempotente-lite (titulo identico abierto → reusa, no duplica). Parsear su ultima linea:
B0_DONE epic=<N|none> issues=<n1,n2,...> waves=<k> mode=created
Resumen corto en terminal:
/b-pipeline:b10-ship --epic=<N> (drena el grafo respetando olas y gates)./b-pipeline:b10-ship --epic=<N> --cluster./b-pipeline:b7-issue-to-pr <n1> (suele ser el tracer bullet)./b-pipeline:b10-ship --epic=<N> --dry-run.Ultima linea SIEMPRE (machine-readable, por si otro orquestador la consume):
B0_DONE epic=<N|none> issues=<csv> waves=<k> mode=<created|dry-run>
## Blocked by con #N en el body → epic-graph.sh la parsea para las olas.epic-link.sh → el epic muestra progreso nativo y b10 --epic los enumera (con fallback a los #N del rollup si el linkeo falla).## Blocked by sobre todos los subs (≥80% del grafo) → b10 lo construye ultimo, tras el gate de epic-review.scope, simple|medium → candidatos a b8-swarm (1 PR combinado).--yes lo salta.## Blocked by/#numeros en los bodies del plan. Deps van en blocked_by (ids); el script los resuelve.gh issue create a mano para esto — usar create-epic.sh (resuelve deps, linkea el epic, evita duplicados).references/slicing-guide.md — vertical vs horizontal, metodo tracer-bullet, ejemplo completo con grafo de deps y plan JSON, y el template de cuerpo de issue. Leer al redactar los bodies (Paso 3).scripts/create-epic.sh — creacion deterministica: labels + sub-issues + deps + epic + linkeo nativo. Soporta --dry-run.../b10-ship/scripts/epic-graph.sh — lo que b10 usa para leer este grafo (referencia del contrato de deps/olas).Provides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.
npx claudepluginhub jporre/sveltekit-verticalslices --plugin b-pipeline