Skill: Integración de trabajo

Guía para cerrar e integrar el trabajo ya implementado —una historia de usuario US-XXX o una tarea de mantenimiento WI-XXX— verificando que su progress.md tenga todas las unidades del trabajo en Done, que pasen las puertas de calidad de cierre (quality-check, code-review y coverage-verify, en ese orden), y luego hacer merge de la rama actual hacia la rama desde la que se creó.

Alcance del submit: El skill cierra localmente lo ya implementado. Verifica condiciones y ejecuta git merge --no-ff. No archiva el artefacto: archivar es una decisión posterior a la revisión humana y la hace el skill que produjo el artefacto (/work-define US-XXX archive, /work-plan WI-XXX archive; ver ${PLUGIN_ROOT}/references/archive.md). No hace push, no borra ramas, no crea MRs/PRs, no modifica el contenido de progress.md, y no resuelve conflictos —con la única salida declarada del modify/delete sobre los dos informes de docs/audits/, que se resuelve por el lado del borrado (ver references/flows.md). Lo que no esté en Done bloquea el merge — el usuario decide cómo proceder, nunca se fuerza.

Encaja al final de los ciclos work-define → work-plan → work-implement (historias y tareas de mantenimiento). Ver Handoffs del ciclo en references/examples.md.

Cómo preguntar al usuario

Mecanismo, ritmo y fallback compartidos: ${PLUGIN_ROOT}/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í.

La tanda inicial va antes de cualquier operación git y cubre: trabajo asociado a la rama, carpeta ambigua y rama base. No empezar a mover, mergear ni archivar con lagunas abiertas.

Excepción al ritmo: el cierre del trabajo (paso 11, Done) va por fuerza después del merge — hasta entonces no se sabe si el trabajo llega a integrarse.