--- name: work-plan description: "Planifica trabajo sin generar código ni pruebas. Tipos de plan: (1) tareas técnicas (TK-XXX) bajo una historia existente; (2) tareas de mantenimiento (WI-XXX) sin historia — bug-fix, refactor, deuda técnica, dependencias, tareas operativas y spikes (experimento con timebox, entrega un informe); (3) incidentes (BUG-XXX): registro de un hallazgo con evidencia, sin plan de corrección; único documento que produce con implementation.scope: tests. Activar al pedir planificar implementación, descomponer trabajo, definir alcance técnico, planificar mantenimiento o registrar un bug o hallazgo, aunque no nombre TK, WI o BUG. Ante una sola referencia a una historia («planifica US-007»), proponer la descomposición por repositorio cubriendo los AC-XXX. Carga la definición del tipo desde references/. Con gestor activo, `sync #id` trae un Task como TK/WI o un Bug como BUG-XXX, creando o actualizando el documento local. Archiva WI y BUG con `archive`, mostrando el estado y pidiendo confirmación." license: MIT --- # 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. > **Repositorio solo de pruebas (`implementation.scope: tests`).** Aquí **no hay trabajo de implementación que planificar**: este skill produce **exclusivamente incidentes `BUG-XXX`** — el reporte de un hallazgo detectado por un `TC-XXX` contra el sistema bajo prueba, con `assets/incident-tests-template.md` (ver [`references/incidents.md § Variante modo pruebas`](references/incidents.md#variante-modo-pruebas-implementationscope-tests)). **No se crean tareas `TK-XXX` de historias ni `WI-XXX` de ningún tipo** (`bug-fix`, `refactor`, `spike`, `test-improvement`…); si el usuario pide planificar la corrección, remitirlo al repositorio de la aplicación. Tampoco se delega a `design-define` por «elementos técnicos sin especificación»: lo que haga falta saber del sistema bajo prueba se **solicita al usuario** y se documenta tal cual. Contrato en [`${PLUGIN_ROOT}/references/implementation.md`](../../references/implementation.md#modo-pruebas-implementationscope-tests--contrato-para-el-catálogo). --- ## 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/architecture/`) 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 `architecture/`. 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}/references/planning.md`](../../references/planning.md). Las reglas de `planning.md` son obligatorias y determinan, vía `specification.testCases.createMode`, 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`). **No aplica a los incidentes `BUG-XXX` ni a los `WI` de tipo `spike`**: no tienen `AC-XXX` que cubrir. La otra clave del objeto, `createDetailsMode`, **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}/references/asking.md`](../../references/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 `references/`), y toda referencia compartida de este skill se escribe como `${PLUGIN_ROOT}/references/.md`. Para resolverla: la raíz es la **carpeta desde la que se cargó este archivo**, dos niveles arriba (`/skills//SKILL.md`) — el cliente anuncia esa ubicación al invocar el skill (p. ej. «Base directory for this skill: …»). Si esa ubicación no está disponible, localizar la instalación buscando el manifiesto del plugin: `PLUGIN_ROOT="$(dirname "$(grep -rl '\"name\": *\"sdd-devkit\"' "$HOME/.claude/plugins" --include=plugin.json 2>/dev/null | head -1)")"`. En ambos casos, **verificar antes de usarla** que `$PLUGIN_ROOT/references/language.md` existe. El destino de cada enlace markdown (`../../references/…`) existe solo para navegar el repositorio en GitHub o en un editor: **no** resolverlo desde el directorio de trabajo. **Nunca buscar `references/` en el proyecto**: un `/references/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}/references/language.md`](../../references/language.md). Las reglas de `language.md` son obligatorias y tienen prioridad para determinar el idioma de todos los artefactos, documentos y mensajes generados por este skill. No continúes hasta haber leído y aplicado `language.md`. **Enlaces a archivos del proyecto:** DEBES leer y aplicar [`${PLUGIN_ROOT}/references/linking.md`](../../references/linking.md) — todo archivo o carpeta existente del proyecto que este skill mencione en un artefacto, documento o mensaje (identificadores como `US-XXX` o `WF-XXX`, rutas, índices) se escribe como enlace Markdown que lo abre. --- ## 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 primera señal es **si lo que se pide es registrar un hallazgo o planificar trabajo**; la segunda, **si el trabajo tiene una historia de usuario asociada o no**. | Tipo de plan | Cómo se identifica | Definición a leer | |--------------|--------------------|-------------------| | **Incidente** | Se pide **registrar un hallazgo**, no planificar su corrección: un defecto observado, una prueba en rojo fiel a su `TC-XXX`, «registra el bug», «abre un incidente», un *handoff* de `work-implement` o `work-research` con lo observado, o la edición de un `BUG-XXX` existente. Con `implementation.scope: tests` es el **único** tipo posible. | `references/incidents.md` — **leer antes de redactar.** | | **Tarea técnica de historia de usuario** | El trabajo **referencia una historia de usuario**: prefijo de historia `US-XXX` (p. ej. «planifica US-007», «tareas para esta historia»), una historia ubicada bajo el árbol de user-stories del repo, o la edición de una `TK-XXX` que cuelga de una US. | `references/user-story-tasks.md` — **leer antes de redactar.** | | **Tarea de mantenimiento** | El trabajo **no tiene una historia de usuario asociada** (corrección de un bug —`bug-fix`—, refactor, deuda técnica, actualización de dependencias, tarea operativa, spike), o el usuario pide explícitamente «plan/tarea de mantenimiento». Un **spike** es siempre de este tipo aunque lo motive una US: el experimento no es una tarea de la historia, es lo que permite planificarla (la US va en `Origen`). | `references/maintenance-tasks.md` — **leer antes de redactar.** | Reglas de selección: - **¿Registrar qué está mal, o planificar qué hacer?** Lo primero es un incidente (`BUG-XXX`), aunque el usuario diga «bug» o «work item»; lo segundo, una TK o un WI. «Corrige el bug» / «planifica la corrección del BUG-004» es un WI de tipo `bug-fix`; «registra el bug» / «la prueba falla y quiero dejarlo documentado» es un incidente. Ante la duda, preguntar. - **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 `/user-stories/`: el usuario puede haberla archivado con `/work-define US-XXX archive`. 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 [`${PLUGIN_ROOT}/references/archive.md`](../../references/archive.md#contrato-para-el-resto-del-catálogo). - 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). --- ## Modificador `sync` (sincronizar desde el gestor de proyectos) Solo con la integración con el gestor de proyectos **activada** (ver [Resolución de la integración](#resolución-de-la-integración-con-el-gestor-de-proyectos)) y el modificador **explícito**. El usuario puede nombrarlo en español («importa», «trae de Azure», «sincroniza con ADO»). Mismo contrato que `work-define sync` y `test-define sync` («Dirección de la sincronización» en la base común del proveedor): **por defecto baja** —tracker → repo: crea el documento local si no existe y lo actualiza si ya existe, sin escribir nada en el tracker— y **solo con `push` sube** —repo → tracker— a petición explícita. | Invocación | Efecto | |------------|--------| | `sync <#id \| URL \| WI-XXX \| BUG-XXX \| TK-XXX> [<#id> …]` | **Bajada.** Lee cada work item vía MCP y lo materializa **según su tipo** (tabla de abajo). Varios a la vez → una sola tanda de preguntas y de confirmación. Un cambio local que el tracker no tiene se conserva y se señala en el diff; no se sube. | | `sync […] push` (o «sube», «publica en ADO») | **Subida.** Diff inverso por sección, confirmación, y escritura de lo confirmado en el work item con el mismo mapeo que la creación («Qué se crea» de `references/.md`). Sin `Work Item ()` en la cabecera, ofrece crearlo (`Task` para TK/WI, `Bug` para un incidente) conservando el número local. Nunca cambia `id`, tipo, padre ni estado. | **Qué se crea según el tipo del work item** (los nombres exactos por proceso los define `references/.md`): | Tipo en el tracker | Documento local | Tipo de plan cuya referencia se aplica | |--------------------|-----------------|----------------------------------------| | **Bug** | **Incidente `BUG--[slug]/README.md`** en `/incidents/` — **nunca un `WI`**: el tipo `bug` no existe en los work items | `references/incidents.md` (plantilla `incident-template.md`; en `implementation.scope: tests`, `incident-tests-template.md`) | | **Task** con padre historia que existe localmente (`US--*` o `Work Item (): [#]`) | `TK--[slug].md` dentro de esa US | `references/user-story-tasks.md` | | **Task** cuyo padre historia **no** existe localmente | Preguntar: `[Sincronizar primero la historia (/work-define sync #)]` / `[Crear como WI-]`. Nunca crear la carpeta de la US desde aquí | — | | **Task** sin padre historia (o con `implementation.scope: tests`, donde no hay TK ni WI) | `WI--[slug]/README.md` en `/work-items/`, con `Tipo` inferido del título/tags y confirmado; en modo pruebas, **parar**: solo se sincronizan `Bug` | `references/maintenance-tasks.md` | | **User Story** / PBI / Requirement / Feature / Epic | No es de este skill: remitir a `/work-define sync #` | — | | **Test Case** | Remitir a `/test-define sync #` | — | | Otro | Preguntar al usuario qué espera antes de hacer nada | — | **Esqueleto del flujo** (el mapeo de campos vive en `references/.md` → «Lectura (`sync`)»): 1. **Resolver la entrada** a uno o varios `id` numéricos (`#4821`, `4821`, URL, o un `WI-`/`BUG-`/`TK-` local con `Work Item ()`). Lo que no se resuelva, se pregunta. 2. **Leer cada work item** vía MCP y clasificarlo con la tabla anterior. Sin MCP, degradar como la base común: pedir al usuario que pegue el contenido; el número local es el `id` que indicó. 3. **Localizar el documento local** por `--*` y por cabecera `Work Item (): [#]`, en la ruta activa **y** en ``. Archivado → parar y avisar (desarchivar lo decide el usuario). No existe → **crear**; existe → **actualizar**. 4. **Mapear** los campos a la plantilla del tipo de plan resuelto, **sin inventar** lo que el work item no diga: lo que la plantilla exige y el tracker no trae es una laguna en Observaciones. Los `AC-XXX` de un `Task` se codifican como en `work-define sync` (verbatim si ya traen identificador; `AC-001…` en orden si no, anotándolo). Para un `Bug`, los pasos de reproducción se copian **uno a uno** y los adjuntos se descargan a `assets/` como `EV-XX` si el MCP lo permite (si no, se listan como «No adjuntado — en el tracker»). 5. **Preguntar solo lo que el tracker no tiene**, en una tanda para todo el lote: `Repositorio` (si no es inferible), `Tipo` del WI cuando el título no lo determina, y en un `Bug` la **Severidad** si el campo no existe en el proceso. 6. **Crear** el documento con el `id` del tracker como número (sin padding), `Work Item (): [#]()` en la cabecera y `Estado` según el checklist de Ready del tipo de plan (el estado del tracker solo orienta). Un incidente nace con `Resolución: Open` salvo que el `Bug` esté cerrado en el tracker: entonces se avisa y, si el usuario confirma, `Resolución: Fixed ()` o `Discarded — cerrado en `. 7. **Actualizar** (documento ya existente): presentar **un diff por sección** en una sola tanda y aplicar únicamente lo confirmado; identificadores (`AC-XXX`, `IT-XX`, `EV-XX`) inmutables; un criterio eliminado en el tracker se marca `Obsolete`, no se borra; en un incidente, un `Bug` cerrado propone actualizar `Resolución`, nunca borrar evidencia. 8. **Cerrar** con el mensaje explícito — «Sincronizado BUG- desde (#): creado → » / «…: actualizadas » / «Subido WI-XXX a (#): » — y el handoff habitual del tipo de plan (un incidente ofrece **[Planificar la corrección]** / **[Solo registrar]**; una TK/WI en `Ready`, `test-define` según `createMode` y `work-implement`). > **Un `#id` o una URL sin modificador nunca dispara una sincronización ni sirve de número para un documento nuevo.** Si la entrada trae un identificador del tracker o palabras como «importa», «trae», «sincroniza», **preguntar** (herramienta estructurada): [Sincronizar # desde ] / [Crear uno nuevo (el número es solo contexto)]. Con integración desactivada, `sync` no está disponible: informar que el repo no está vinculado (`projectManagement` en `.sdd-devkit/settings.json`) y no leer ninguna referencia de proveedor. --- ## Modificador `archive` (archivar tareas de mantenimiento `WI-XXX` e incidentes `BUG-XXX`) **Archiva este skill, no los de cierre.** `work-integrate` y `pr-create` no archivan: siempre hay una revisión humana antes, y el usuario lo pide aquí cuando decide. Procedimiento, destinos, reglas de confirmación y contrato para el resto del catálogo: [`${PLUGIN_ROOT}/references/archive.md`](../../references/archive.md) — leerlo antes de mover nada. | Invocación | Alcance | |------------|---------| | `/work-plan archive WI-XXX` · `/work-plan BUG-XXX archive` (uno o varios IDs de ambos prefijos; el orden es indiferente) | Los artefactos indicados, **estén como estén**. | | `/work-plan archive` (sin ID) | **Todos** los `WI-XXX` de `/work-items/` y los `BUG-XXX` de `/incidents/` que ya estén **completos**; los incompletos se listan aparte con su estado y no se mueven. | Reglas que este skill aplica al archivar: - **El estado no restringe, pero se informa.** Antes de preguntar, componer el parte de estado: `Estado` del `README.md`; `progress.md`; `criteria-coverage.md`; en un `BUG-XXX`, solo `Estado` y la línea `Resolución:` (`Open`/`Fixing (…)` cuentan como incompleto; no tiene `progress.md` ni cobertura); en un `WI` de tipo `spike`, la línea `Resolución:` y la presencia de `spike-report.md` (sin informe o con `Resolución: Open` cuenta como incompleto; su rama `spike/` nunca se integra, así que no es señal). Con algo incompleto, la pregunta lo dice explícitamente y el usuario decide. - **Siempre se confirma** (herramienta estructurada, una sola tanda para todo el lote), mostrando origen → destino de cada carpeta y las investigaciones sueltas que quedarían huérfanas. Sin canal de respuesta, no se archiva. - **Destino:** `/work-items/-/` para un WI y `/incidents/-/` para un incidente, con `` = `specification.archivedPath` de `.sdd-devkit/settings.json` (por defecto `docs/specs/archived/`) y la subcarpeta espejo de ``. `git mv`, guard de destino, reparación de enlaces y cierre con un commit directo `docs(specs): archivar `, tal como describe la referencia. - Un artefacto ya bajo `` se informa y no se toca; un ID suelto **sin** `archive` nunca archiva. - Solo se archivan `WI-XXX` y `BUG-XXX`; las `TK-XXX` viajan con su historia (`/work-define US-XXX archive`). --- ## Resolución de la integración con el gestor de proyectos Antes de ejecutar este skill, DEBES leer [`${PLUGIN_ROOT}/references/project-management.md`](../../references/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 aplica a los tres tipos de plan en **dos direcciones**: al redactar, todos crean work items (un incidente se crea como `Bug`; todo lo demás como `Task`); con el modificador `sync`, se **lee** un work item existente y se materializa localmente (ver [Modificador `sync`](#modificador-sync-sincronizar-desde-el-gestor-de-proyectos)). - **Desactivada** → continuar con el flujo del tipo de plan usando **ID secuencial local**; no leer ninguna referencia de proveedor; `sync` no está disponible. - **Activada** → además de la referencia compartida del proveedor, cargar `references/.md` de este skill (p. ej. [`references/azure-devops.md`](references/azure-devops.md)) y seguir **únicamente** sus pasos antes de crear cualquier archivo local (sección «Qué se crea» al redactar; sección «Lectura (`sync`)» al sincronizar). 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 | Archivo | Cuándo leerlo | |---------|---------------| | `references/user-story-tasks.md` | Tipo de plan = tarea técnica de historia de usuario. Contiene modos de invocación, ubicaciones, flujos (stub, TK completa, actualizar, planificar desde US), checklist, ejemplos y anti-patrones. | | `references/maintenance-tasks.md` | Tipo de plan = tarea de mantenimiento. | | `references/incidents.md` | Tipo de plan = incidente (`BUG-XXX`): registro de un hallazgo con evidencia, ubicación, `Resolución`, variante modo pruebas, handoffs. | | `references/.md` (p. ej. `azure-devops.md`) | Solo si `project-management.md` resolvió la integración como activada; el archivo concreto depende del `provider` resuelto. Cubre la creación de work items al redactar y la lectura con `sync`. | | `assets/task-template.md` | Plantilla canónica de una tarea de historia de usuario (`TK-XXX`). Leer antes de redactar el documento. | | `assets/work-item-template.md` | Plantilla canónica de una tarea de mantenimiento (`WI-XXX`). Leer antes de redactar el documento. | | `assets/incident-template.md` | Plantilla canónica de un incidente (`BUG-XXX`): esperado/observado, pasos para reproducir, evidencia `EV-XX`, impacto y `Resolución`; sin plan. Leer antes de redactar el documento. | | `assets/incident-tests-template.md` | Plantilla del incidente en un repositorio con `implementation.scope: tests`: con forma de caso de prueba (pasos del `TC-XXX` con lo observado y comentarios para reproducir, hallazgos `H-XX` y evidencias de la suite adjuntas). **Sustituye** a la anterior en ese modo. | | `assets/work-item-spike-template.md` | Plantilla del `WI-XXX` de `Tipo: spike`: pregunta de investigación, hipótesis, `Q-XX` con criterios de éxito/fallo, timebox, enfoque del experimento. **Sustituye** a `work-item-template.md` para ese tipo. | | `assets/spike-report-template.md` | Informe final del spike (`spike-report.md`), con marca oculta `spike:verdict`. **La redacta `work-implement`** al cerrar el experimento; este skill la lee al crear el WI definitivo a partir del informe. | ### Referencias compartidas del plugin Reglas transversales del catálogo; viven en la raíz del plugin, no en este skill. - [`${PLUGIN_ROOT}/references/language.md`](../../references/language.md): **Idioma** — resolución obligatoria del idioma de artefactos, documentos y mensajes. *Lectura obligatoria antes de ejecutar el skill.* - [`${PLUGIN_ROOT}/references/linking.md`](../../references/linking.md): **Enlaces** — toda referencia a un archivo del proyecto se escribe como enlace que lo abre. *Lectura obligatoria antes de ejecutar el skill.* - [`${PLUGIN_ROOT}/references/asking.md`](../../references/asking.md): **Preguntas** — mecanismo estructurado, ritmo, fallback. *Antes de la primera pregunta.* - [`${PLUGIN_ROOT}/references/artifacts.md`](../../references/artifacts.md): **Artefactos** — rutas del harness, identificadores, archivado. *Al resolver una ruta o calcular un ID.* - [`${PLUGIN_ROOT}/references/planning.md`](../../references/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}/references/project-management.md`](../../references/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}/references/project-managers/azure-devops.md`](../../references/project-managers/azure-devops.md): **Azure DevOps** — MCP, URL, límites, sincronización. *Solo si el `provider` resuelto es `azure-devops`.*