Work Plan

Skill: Planificar trabajo

Guía general para planificar trabajo produciendo documentos de especificación —no código ni pruebas— de distintos tipos. Cada tipo de plan tiene su propia definición (flujos, plantillas, validaciones) en references/. El cuerpo de este SKILL.md contiene únicamente lo transversal a todos los tipos; el detalle de cada tipo se carga solo cuando se necesita.

Qué no hace este skill (cualquier tipo): no implementa código, no ejecuta pruebas, no crea ADRs. Lo que no está acordado va a Observaciones o se pregunta al usuario — nunca se inventa.

Regla de handoff (transversal)

Todo paso a otra fase del ciclo se realiza invocando el skill correspondiente, nunca ejecutando ese trabajo directamente desde este skill. El ciclo es work-define → work-plan → work-implement → work-integrate (con pr-create como alternativa de cierre).

• Si el usuario pide implementar (escribir código, crear/ejecutar pruebas, "impleméntalo", "hazlo", "desarróllalo") mientras se está en work-plan: invocar /work-implement pasándole el contexto del artefacto. Este skill no escribe código ni ejecuta pruebas bajo ninguna circunstancia.
• Solo se implementa trabajo en Estado: Ready. Si el artefacto sigue en Draft (stub o incompleto), no hacer handoff a implementación: completarlo primero en este skill.
• Si el conflicto es funcional (contradice el README.md de una US), escalar a work-define; este skill no modifica la US.
• Si una TK/WI menciona elementos técnicos sin especificación (un modelo, API o flujo citado que no existe en docs/specs/technical-docs/) y el usuario pide más detalle sobre alguno de ellos, delegar mediante subagente a /design-define: ese skill hace el grilling técnico, crea/actualiza el documento de la capability y devuelve las referencias (ruta + ancla) para agregarlas a la sección Referencias de la TK/WI. Este skill no crea ni edita documentos en technical-docs/.

No sustituir una invocación de skill por "hacer el trabajo aquí". El handoff es explícito y por skill en cada frontera del ciclo.

Subagente

Si el proyecto define el subagente docs-specialist, ejecutar este skill bajo ese subagente, sea cual sea el tipo de plan. Si no existe, ejecutar el flujo normalmente.

Política de planificación

Antes de ejecutar este skill, DEBES leer ${PLUGIN_ROOT}/reference/planning.md.

Las reglas de planning.md son obligatorias y determinan, vía specification.testCases.mode, si al dejar las tareas del alcance en Ready se pregunta si definir los casos de prueba (ask, comportamiento por defecto), se invoca /test-define automáticamente sin preguntar (always), o nunca se sugiere ni se invoca (never). La otra clave del objeto, askDetails, no la consume este skill: la lee test-define.

No continúes hasta haber leído y aplicado planning.md.

Excepción deliberada: los TC-XXX cuelgan del artefacto padre (la US, o el propio WI), no de una TK. Antes de ofrecer o invocar nada, comprobar si ese padre ya tiene test-cases/ con al menos un TC-XXX: si los tiene —work-define pudo crearlos en su propio cierre—, no repetir la oferta ni la invocación, ni siquiera con always.

Cómo preguntar al usuario

Mecanismo, ritmo y fallback compartidos: ${PLUGIN_ROOT}/reference/asking.md.

Cada vez que este skill o sus referencias digan preguntar, pedir, confirmar, validar o sugerir algo al usuario, asume ese mecanismo; no se repite allí.

Entrada libre solo donde no haya opciones razonables que enumerar (p. ej. el objetivo breve de un stub).

Rutas de las referencias compartidas

${PLUGIN_ROOT} es la raíz del plugin instalado (la carpeta que contiene skills/, agents/ y reference/), y toda referencia compartida de este skill se escribe como ${PLUGIN_ROOT}/reference/<archivo>.md. Resolverla así, en este orden: (1) en Claude Code, ${PLUGIN_ROOT} es ${CLAUDE_PLUGIN_ROOT} — comprobar con echo "$CLAUDE_PLUGIN_ROOT" y usar ese valor; (2) en cualquier otro cliente, o si la variable está vacía, la carpeta desde la que se cargó este archivo, dos niveles arriba. El destino de cada enlace markdown (../../reference/…) existe solo para navegar el repositorio en GitHub o en un editor: no resolverlo desde el directorio de trabajo. Nunca buscar reference/ en el proyecto: un <proyecto>/reference/language.md que no existe no es un archivo que falte, es una ruta mal resuelta — corregir la raíz y volver a leer, sin preguntar al usuario ni saltarse la lectura.

Resolución de idioma

Antes de ejecutar este skill, DEBES leer ${PLUGIN_ROOT}/reference/language.md.

Las reglas de language.md son obligatorias y tienen prioridad para determinar el idioma de todos los artefactos y mensajes generados por este skill.

No continúes hasta haber leído y aplicado language.md.

Selección del tipo de plan

Antes de cualquier otra cosa, identificar qué tipo de plan corresponde y cargar su definición. No mezclar tipos en una misma ejecución.

La señal que distingue los tipos es si el trabajo tiene una historia de usuario asociada o no.

Reglas de selección:

• Hay historia asociada → tarea de historia de usuario. No la hay → mantenimiento. Leer la referencia correspondiente y seguir únicamente su flujo.
• Una US archivada sigue siendo una US. Antes de concluir que «no hay historia asociada», buscarla también bajo docs/archive/user-stories/: work-integrate y pr-create mueven ahí la carpeta al cerrar el trabajo. Si aparece ahí, el tipo es tarea de historia de usuario y su referencia dirá que hay que parar por estar archivada — degradarla a WI-XXX por no encontrarla en la ruta activa crearía un artefacto nuevo para trabajo que ya existe. Ver work-integrate/references/archive.md.
• Si no está claro si existe o no una historia asociada (p. ej. una referencia ambigua que podría apuntar a una US), preguntar al usuario antes de continuar; no asumir la existencia de una US ni inventarla.
• Si el tipo seleccionado aún no tiene su flujo definido, la propia referencia indica cómo proceder (p. ej. confirmar con el usuario en lugar de inventar estructura).

Resolución de la integración con el gestor de proyectos

Antes de ejecutar este skill, DEBES leer ${PLUGIN_ROOT}/reference/project-management.md.

Las reglas de project-management.md son obligatorias y tienen prioridad para determinar si hay integración con un gestor de proyectos, con qué proveedor y con qué datos de conexión.

No continúes hasta haber leído y aplicado project-management.md.

Delta de este skill: la integración solo aplica a los tipos de plan que crean work items.

• Desactivada → continuar con el flujo del tipo de plan usando ID secuencial local; no leer ninguna referencia de proveedor.
• Activada → además de la referencia compartida del proveedor, cargar references/<proveedor>.md de este skill (p. ej. references/azure-devops.md) y seguir únicamente sus pasos antes de crear cualquier archivo local. Si este skill no tiene referencia para ese proveedor, informar al usuario y continuar con ID secuencial local.

Todo el detalle propio de cada proveedor (herramienta MCP, campos, tipos de work item, límites de formato) vive exclusivamente en esos archivos — nunca aquí ni en las referencias de tipo de plan.

Regla de fidelidad (transversal a cualquier sistema): toda la información del documento local debe quedar representada en el work item externo — en un campo dedicado si el sistema lo expone (p. ej. un campo de criterios de aceptación), o dentro de la descripción si no lo expone. Ninguna sección del .md puede omitirse al sincronizar; el objetivo es poder reconstruir el documento completo a partir del work item si el archivo local se perdiera. Qué campo usa cada sistema para qué sección es detalle de su archivo de referencia.

Mensaje al usuario

Solo resultados y lo que el usuario debe saber o decidir. No incluir razonamiento interno, cadenas de pensamiento ni narración del trabajo en curso («leí la US», «creé el archivo»). Si hay pendientes o aclaraciones, listarlos en viñetas agrupadas por artefacto.

Mapa de referencias

Referencias compartidas del plugin

Reglas transversales del catálogo; viven en la raíz del plugin, no en este skill.

• ${PLUGIN_ROOT}/reference/language.md: Idioma — resolución obligatoria del idioma de artefactos y mensajes. Lectura obligatoria antes de ejecutar el skill.
• ${PLUGIN_ROOT}/reference/asking.md: Preguntas — mecanismo estructurado, ritmo, fallback. Antes de la primera pregunta.
• ${PLUGIN_ROOT}/reference/artifacts.md: Artefactos — rutas del harness, identificadores, archivado. Al resolver una ruta o calcular un ID.
• ${PLUGIN_ROOT}/reference/planning.md: Política de planificación — si se pregunta, se invoca automáticamente o nunca se sugiere test-define al dejar las tareas en Ready. Lectura obligatoria antes de ejecutar el skill.
• ${PLUGIN_ROOT}/reference/project-management.md: Gestor de proyectos — si la integración está activa, proveedor y datos de conexión. Lectura obligatoria antes de ejecutar el skill.
• ${PLUGIN_ROOT}/reference/project-managers/azure-devops.md: Azure DevOps — MCP, URL, límites, sincronización. Solo si el provider resuelto es azure-devops.