Edición en Markdown

AI-translated from English; not yet reviewed by a fluent editor.

# Lleva una función aprobada por Jira y un cambio verificado de Claude Code

> Convierte una función aprobada en una épica real de Jira, todas sus historias y subtareas con sentido. Comprueba cada cambio de Claude Code, verifica las actualizaciones y revisa la decisión sobre las instrucciones del proyecto.

By BIG CHANGE Editorial

Published: 2026-10-20T13:23:38.288Z
Updated: 2026-10-20T13:23:38.288Z
Canonical: https://bigchange.ai/blog/claude-code-jira-approved-feature-guide

![Conceptual charcoal illustration of a developer at a standing counter reviewing a generic two-column code diff on an arm-mounted display.](https://bigchange.ai/api/media/file/claude-code-jira-feature-review-hero-v2.png)
AI-generated conceptual illustration by BIG CHANGE.

Una función aprobada puede pasar por tres sistemas antes de terminar: un documento de requisitos, una jerarquía de incidencias en Jira y un repositorio. Claude Code puede ayudar a redactar e implementar el trabajo, pero las relaciones entre esos sistemas requieren aprobación humana y comprobaciones directas. Esta guía acompaña a un desarrollador o responsable de equipo por una función real, incluidas **todas las historias aprobadas**, sus pruebas originales, las actualizaciones autorizadas en Jira y una decisión revisada sobre las instrucciones del proyecto.

Este procedimiento se basa en documentación. BIG CHANGE no accedió a un proyecto de Jira, ejecutó Claude Code, modificó un repositorio ni midió el tiempo de entrega de una función. Los tipos de incidencia, campos, transiciones, comandos y costes concretos dependen de tu proyecto y tu cuenta.

## El gran cambio

- **Qué ha cambiado:** Es posible seguir una función desde el requisito aprobado, pasando por una incidencia principal real de Jira y todas las historias, hasta el código revisado, las comprobaciones originales y las actualizaciones autorizadas.
- **Por qué importa:** El mapa de incidencias, los registros de pruebas y las lecturas directas de Jira muestran qué trabajo aprobado está terminado y qué historia sigue abierta.
- **En qué fijarse:** Los campos y transiciones propios del proyecto, las escrituras de resultado incierto y las comprobaciones fallidas requieren una resolución humana; las instrucciones de Claude Code no autorizan el trabajo por sí solas.

## Antes de empezar

Elige una función con un encargo aprobado por su responsable, un repositorio que puedas editar y una comprobación de aceptación original que puedas ejecutar. Su trabajo real debe justificar una incidencia principal de nivel épica, sus historias aprobadas y al menos una subtarea significativa bajo una historia en el proyecto de Jira Cloud elegido. Si no existe una subtarea real, este resultado completo sigue pendiente; añadir una incidencia decorativa falsearía el plan. Registra al solicitante, la autoridad de aprobación, la revisión de origen, los datos permitidos, el commit inicial de Git, la vía de aislamiento o reversión y quién puede revisar el código y cambiar el estado en Jira.

Comprueba la [versión, autenticación y permisos de Claude Code](https://code.claude.com/docs/en/permissions) en tu instalación. Confirma que el archivo `CLAUDE.md` del repositorio aporta instrucciones del proyecto sin conceder permiso para editar, ejecutar comandos o enviar datos. Decide qué requisitos y código puede recibir Claude, qué comandos puede ejecutar y el límite de uso de esta función. El uso de Claude Code puede consumir la asignación de una suscripción o generar cargos del proveedor; [la guía de costes de Anthropic](https://code.claude.com/docs/en/costs) no determina tu factura de antemano.

Para Jira, consigue permiso para consultar y crear los tipos de incidencia pertinentes y, más adelante, comentar o cambiar su estado como usuario autorizado. Un script privado puede usar [el método de correo electrónico y token de API documentado por Atlassian](https://developer.atlassian.com/cloud/jira/platform/basic-auth-for-rest-apis); una integración podría necesitar OAuth. Guarda las credenciales en un almacén privado de secretos. Exclúyelas de los mensajes, el texto de las incidencias, `CLAUDE.md`, los registros y el control de versiones. Acuerda la visibilidad de las incidencias antes de enviar requisitos a Jira.

Conserva siete registros privados durante el proceso: `docs/feature-prd.md`, `ticket-plan.json`, un diario de escrituras de incidencias al que solo se añadan entradas, `ticket-map.json`, un justificante de implementación por historia, un diario de actualizaciones de Jira y una decisión retrospectiva. Son registros de tu función, no archivos proporcionados o ejecutados por BIG CHANGE.

## 1. Aprueba un PRD concreto

Entrega a Claude Code el encargo realmente aprobado de la función y pídele que identifique las preguntas pendientes antes de redactar `docs/feature-prd.md`. El documento necesita el solicitante y el responsable que aprueba, la revisión de entrada, el problema y usuario previsto, el alcance y las exclusiones, los identificadores numerados de requisitos, las comprobaciones de aceptación y sus fuentes de evidencia, las restricciones no funcionales, el proyecto de Jira y las preguntas abiertas. Una persona responsable debe comparar el borrador con el encargo original y aprobar una revisión exacta del contenido y su hash. Resuelve las dudas sustanciales antes de crear incidencias o editar código.

El hash proporciona una fuente precisa a los registros posteriores. Si cambia el PRD, revisa de nuevo el plan de incidencias y las comprobaciones afectadas; un fallo de implementación no justifica reescribir los criterios de aceptación para que el resultado pase.

## 2. Descubre la jerarquía y los campos de este proyecto de Jira

Con solicitudes autorizadas y **de solo lectura** a la API REST v3 de Jira, recorre las páginas de `GET /rest/api/3/issue/createmeta/{projectIdOrKey}/issuetypes`. Para cada tipo de incidencia propuesto, recorre las páginas de `GET /rest/api/3/issue/createmeta/{projectIdOrKey}/issuetypes/{issueTypeId}` para conocer los campos obligatorios de creación y los valores permitidos. Atlassian marca la operación amplia `GET /issue/createmeta` como obsoleta en su [referencia de la API de incidencias](https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issues/).

Confirma una incidencia principal real equivalente a una épica, incidencias hijas de nivel historia y subtareas compatibles con este proyecto. Atlassian describe [la jerarquía predeterminada y su configuración](https://support.atlassian.com/jira-cloud-administration/docs/configure-the-issue-type-hierarchy/); los nombres y los ID de los tipos no son universales. Examina cómo funciona el campo Parent del proyecto en cada nivel hijo y qué campos personalizados o ajustes de visibilidad exige la creación. Si el proyecto no puede representar el esquema aprobado, registra el tipo, campo o permiso que falta y suspende la creación. Un enlace genérico entre incidencias no establece una relación de padre e hijo.

## 3. Revisa todo el plan de incidencias antes de escribir

Relaciona cada requisito del PRD y cada comprobación de aceptación en `ticket-plan.json`. Registra su `planVersion`, el hash del PRD, el sitio y la clave del proyecto de Jira, un ID local de ejecución y quién aprobó el plan y cuándo. Para cada incidencia propuesta, registra un ID local único, el ID local de su padre previsto, el ID del tipo descubierto, los campos obligatorios del proyecto, resumen, descripción, ID de requisitos y aceptación, responsable y visibilidad permitida. El trabajo aprobado determina cuántas historias y subtareas habrá. Cada subtarea debe realizar trabajo real bajo su historia correspondiente.

La API REST v3 de Jira utiliza **Atlassian Document Format (ADF)**, un documento JSON estructurado, para descripciones y comentarios de varias líneas. Prepara esos documentos a partir del contenido aprobado y comprueba los metadatos de campos que devuelve el sitio antes de formar cada solicitud. La [API de incidencias](https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issues/) documenta la operación de creación; no puede proporcionar un objeto de campos listo para un proyecto desconocido. Una persona debe aprobar el esquema completo, la cobertura de todos los requisitos, las relaciones de parentesco y el destino exacto de escritura antes de cualquier `POST`.

## 4. Crea primero los padres y vuelve a leer cada incidencia

Crea la incidencia principal aprobada mediante `POST /rest/api/3/issue`, después sus historias y luego cada subtarea real. Antes de **cada** solicitud, añade una fila al diario privado con el ID de ejecución, el ID local de la incidencia, la clave del padre confirmado cuando corresponda, el destino, el hash de la solicitud exacta aprobada, la hora UTC del intento y el estado `pending`. No incluyas ningún token. Al recibir HTTP 201, registra el ID y la clave de incidencia devueltos por Jira y realiza directamente `GET /rest/api/3/issue/{issueIdOrKey}`. Compara proyecto, tipo, resumen, descripción o referencia al PRD y padre con el plan aprobado. Marca la fila como `confirmed` solo después de esa lectura. Un padre confirmado permite crear sus hijos.

Si una solicitud agota el tiempo o se pierde la respuesta, márcala como `unknown`. Busca en Jira por proyecto, hora, resumen aprobado y referencia del plan; abre directamente cualquier coincidencia probable y pide al responsable autorizado que resuelva su identidad. [Atlassian advierte de que la búsqueda puede tardar en reflejar una escritura](https://developer.atlassian.com/cloud/jira/platform/search-and-reconcile/). Que no aparezcan resultados no demuestra que la creación fallara. El ID de ejecución y el diario ayudan a conciliar, pero no hacen que el servidor rechace creaciones duplicadas. Nunca repitas a ciegas un `POST` cuyo resultado sea incierto.

Lee directamente el esquema terminado y regístralo en `ticket-map.json`: cada ID local, ID y clave reales de Jira, URL canónica de la incidencia, proyecto, tipo, clave del padre, ID del PRD y de aceptación, hora de lectura y referencia del diario. Compara **todas** las incidencias y los criterios aprobados con el PRD. Detén las escrituras si falta una incidencia o tiene un padre incorrecto; utiliza el proceso de corrección revisado del proyecto.

## 5. Implementa y revisa de forma independiente cada historia aprobada

Recorre las historias aprobadas según sus dependencias. Para cada una, registra su clave de Jira, commit inicial de Git y rama o árbol de trabajo, comando original de aceptación, rutas y comandos permitidos. Pide a Claude Code que use [Plan mode](https://code.claude.com/docs/en/common-workflows) para relacionar los criterios de esa historia con el repositorio. Un desarrollador comprueba el plan y autoriza una edición acotada. El límite de la historia mantiene revisable el cambio; no elimina las demás historias aprobadas de la función.

Tras editar, conserva el diff exacto, el comando de comprobación original con su salida completa y estado de salida, las pruebas específicas pertinentes y un veredicto por ID de requisito. Examina el código y los registros reales. Un plan escrito, los archivos generados o la afirmación de Claude de que las pruebas pasaron no demuestran que el cambio funcione. Suspende la historia ante una comprobación fallida, un secreto inesperado, un cambio de dependencias, una escritura externa o una refactorización amplia; corrige dentro del alcance aprobado y ejecuta de nuevo la comprobación original. Otro revisor de código decide si acepta el commit resultante o deja el diff pendiente. Registra esa decisión para cada historia. [Nuestra guía anterior sobre un cambio revisado de Claude Code](https://bigchange.ai/blog/superpowers-claude-code-plan-test-review-change-guide) cubre la etapa más limitada de revisión de código; el PRD y el esquema completo de Jira aportan aquí el límite más amplio de la función.

## 6. Verifica las actualizaciones autorizadas en Jira

Para cada historia revisada, lee su estado actual en Jira y solicita `GET /rest/api/3/issue/{key}/transitions?expand=transitions.fields`. Examina la transición realmente disponible para ese usuario, su destino, los campos obligatorios y los valores permitidos. Un responsable autorizado puede entonces enviar la transición elegida mediante `POST /rest/api/3/issue/{key}/transitions` con los valores de campos resueltos para ese proyecto. Vuelve a leer directamente la incidencia y confirma el nuevo estado. Superar una comprobación de código no autoriza por sí solo Done, una fusión ni un despliegue.

Registra en el diario de actualizaciones de Jira el estado previo a la escritura, la transición prevista, el usuario, la solicitud y la respuesta. Publica un comentario ADF de evidencia factual mediante `POST /rest/api/3/issue/{key}/comment`: commit aceptado o diff pendiente, comprobación original y pruebas específicas, fallos restantes y decisión del revisor. Vuelve a leer el ID y el cuerpo del comentario creado desde la [API de comentarios](https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-comments/) de Jira. Si alguna escritura tiene una respuesta incierta, consulta directamente el estado o los comentarios antes de considerar otra solicitud. Una lista vacía de transiciones o un campo obligatorio no disponible es una carencia de flujo de trabajo o permisos que debes resolver con el responsable del proyecto, no una invitación a inventar un ID.

## 7. Decide si `CLAUDE.md` debe cambiar

Compara los registros reales del PRD, incidencias, diff, pruebas, revisión y Jira. Pide a Claude una breve retrospectiva que señale malentendidos observados o comprobaciones ausentes. Una persona elige una modificación precisa de las instrucciones o registra una decisión de no cambiar nada, con revisor y hora. Si se aprueba, examina y haz commit únicamente del diff de `CLAUDE.md` y su hash. [La guía de memoria de Anthropic](https://code.claude.com/docs/en/memory) describe las instrucciones del proyecto; esta revisión no autoriza automáticamente trabajos futuros. No añadas secretos ni conviertas una lección especulativa en una regla del proyecto.

## Finalización y recuperación

La función solo está terminada cuando la revisión aprobada del PRD se corresponde con el esquema de épica, historias y subtareas confirmado directamente; **cada historia aprobada** tiene su estado inicial, diff aceptado, evidencia de la comprobación original y las pruebas específicas y revisión independiente; cada transición y comentario de evidencia autorizados en Jira se han leído directamente; y una persona ha tomado una decisión sobre la retrospectiva. Registra la etapa exacta pendiente si falta algo. [Elegir una primera tarea de IA](https://bigchange.ai/blog/map-work-choose-first-ai-task-guide) termina antes, en la selección de tarea y una comprobación propuesta; no demuestra este resultado de implementación.

Una creación incierta en Jira permanece en `unknown` hasta que una persona concilie su identidad. Un padre incorrecto detiene la creación de hijos. Las pruebas fallidas conservan sus criterios originales. La falta de una transición o el agotamiento del límite de uso deja un registro parcial fechado para el responsable. Limita los requisitos y datos de clientes al mínimo aprobado para Claude y Jira, comprueba los costes y permisos actuales de la cuenta y presupuesta la revisión humana del código. Esta guía documenta una ruta condicional por las herramientas; no informa de una función terminada, escritura en Jira, ejecución de modelo, ahorro medido, fusión o despliegue realizados por BIG CHANGE.

## Fuentes y lecturas adicionales

- [Atlassian, operaciones de incidencias de Jira Cloud REST API v3](https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issues/): metadatos de creación acotados, creación y lectura de incidencias y operaciones de transición. Los campos e ID del proyecto del lector deben descubrirse en ese entorno.
- [Atlassian, comentarios de incidencias](https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-comments/): creación y lectura de comentarios ADF. Los permisos y la respuesta real dependen del sitio.
- [Atlassian, búsqueda y conciliación](https://developer.atlassian.com/cloud/jira/platform/search-and-reconcile/): explica por qué la ausencia de resultados inmediatamente después de una escritura no puede resolver una creación incierta.
- [Atlassian, jerarquía de tipos de incidencia](https://support.atlassian.com/jira-cloud-administration/docs/configure-the-issue-type-hierarchy/): niveles predeterminados y configuración; aún hay que examinar la estructura del proyecto elegido.
- [Anthropic, flujos de trabajo de Claude Code](https://code.claude.com/docs/en/common-workflows), [permisos](https://code.claude.com/docs/en/permissions), [memoria](https://code.claude.com/docs/en/memory) y [costes](https://code.claude.com/docs/en/costs): planificación, autoridad de edición, instrucciones de `CLAUDE.md` y uso. No documentan una ejecución de esta función.

## Sources

- [Atlassian Jira Cloud REST API v3, incidencias](https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issues/) — Documenta metadatos de creación acotados, POST/GET de incidencias y transiciones; los metadatos amplios de creación están obsoletos. Los campos, ID y transiciones permitidas deben proceder del sitio del lector.
- [Atlassian Jira Cloud REST API v3, comentarios de incidencias](https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-comments/) — Documenta la creación y lectura de comentarios ADF, según los permisos reales. No se publicó ningún comentario para esta guía.
- [Atlassian, búsqueda y conciliación](https://developer.atlassian.com/cloud/jira/platform/search-and-reconcile/) — Explica la coherencia eventual de las búsquedas; no encontrar una incidencia no demuestra su ausencia tras una respuesta de creación incierta.
- [Atlassian, configurar la jerarquía de tipos de incidencia](https://support.atlassian.com/jira-cloud-administration/docs/configure-the-issue-type-hierarchy/) — Explica la jerarquía predeterminada y configurable. Los niveles del proyecto elegido y el comportamiento de Parent requieren una comprobación directa.
- [Atlassian, autenticación básica para API REST](https://developer.atlassian.com/cloud/jira/platform/basic-auth-for-rest-apis/) — Documenta correo electrónico y token de API para un script privado sencillo y las diferencias de las integraciones; las credenciales deben permanecer privadas.
- [Anthropic Claude Code, flujos de trabajo habituales](https://code.claude.com/docs/en/common-workflows) — Documenta Plan mode y patrones de trabajo de programación; no demuestra la implementación ni las comprobaciones del lector.
- [Anthropic Claude Code, permisos](https://code.claude.com/docs/en/permissions) — Documenta los permisos efectivos y las aprobaciones de herramientas; las instrucciones de CLAUDE.md por sí solas no autorizan comandos ni escrituras.
- [Anthropic Claude Code, memoria](https://code.claude.com/docs/en/memory) — Explica las instrucciones de proyecto de CLAUDE.md; la edición retrospectiva propuesta requiere revisión humana y no es aprendizaje automático.
- [Anthropic Claude Code, costes](https://code.claude.com/docs/en/costs) — El uso y la facturación varían según el plan y el proveedor; no se midieron cargos ni ahorros en esta guía basada exclusivamente en documentación.