Skill: Implementar trabajo

Guia general para ejecutar en codigo trabajo ya especificado, de distintos tipos. Cada tipo de implementacion tiene su propio flujo (ubicaciones, validaciones, unidad de confirmacion, cierre) en references/. El cuerpo de este SKILL.md contiene solo lo transversal a todos los tipos; el detalle de cada tipo se carga unicamente cuando se necesita.

Alcance (cualquier tipo): consume especificaciones ya redactadas por los skills de planificacion (work-define, work-plan). No reescribe ni reestructura la especificacion - solo la implementa. Correcciones menores acordadas con el usuario son la unica excepcion.

Solo implementacion: no modifica documentacion de producto (README de US, TK-XXX, WI-XXX, TC-XXX, FT-XXX, ADRs, technical-docs) - solo el progress.md. Excepcion de checkboxes: avanzar el estado de las subtareas del artefacto en ejecucion a medida que se trabajan —[ ] (pendiente) => [~] (en curso) => [x] (completada)— es la unica modificacion permitida en archivos de especificacion; no se toca ninguna otra seccion del artefacto. El archivo a editar depende del tipo: TK-XXX.md para tareas de historia de usuario, el README.md del WI para tareas de mantenimiento. En los tipos de automatizacion de pruebas (TC-XXX / FT-XXX) no aplica: los test cases no tienen subtareas y su especificacion no se toca en absoluto. Si se detecta un conflicto en la documentacion que pueda afectar el resultado, parar inmediatamente y notificar al usuario antes de continuar.

Ritmo - una unidad por confirmacion (confirmByUnit: always, valor por defecto): implementar una unidad, actualizar progress.md y la lista de tareas (to-dos) del agente, ejecutar lint/build, y esperar confirmacion explicita del usuario antes de arrancar la siguiente. La unidad depende del tipo (ver tabla de seleccion). El commit de la unidad terminada no se hace al completarla: queda pendiente durante la pausa de confirmacion, dejando una ventana para que el usuario revise el resultado, aplique correcciones manuales o le indique ajustes al agente antes de que el cambio quede commiteado. El commit se hace al confirmar el avance, como primer paso antes de arrancar la siguiente unidad (o, si el usuario detiene el flujo ahi, en el cierre — ver Paso 4 de cada referencia).

Modo de ejecucion paralela: si el alcance incluye mas de una unidad y la politica resuelta dice no pausar entre unidades — porque implementation.md resolvio confirmByUnit: never, o porque el usuario lo pide explicitamente en el turno (p. ej. "sin preguntar", "de corrido", "todas a la vez") —, se activa el modo de ejecucion paralela (ver seccion Ejecucion paralela con subagentes y worktrees), que corre las unidades independientes en subagentes con worktree y omite las pausas intermedias. Si falta cualquiera de las dos condiciones, se mantiene el modo secuencial.

Alcance de las pruebas - solo archivos afectados: este skill ejecuta las pruebas (y lint/typecheck/build) unicamente sobre los archivos o el paquete afectados por la unidad implementada — tanto por unidad (Paso 3) como en el cierre (Paso 4) y tras cada merge en modo paralelo. Nunca corre la bateria completa de pruebas del repositorio. Ejecutar toda la bateria de pruebas (regresion de todo el repo) es responsabilidad exclusiva de quality-check, que corre en work-integrate / pr-create antes de integrar o crear el PR; este skill no la sustituye ni la anticipa.

Como preguntar al usuario

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