Версия Markdown

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

# Проведите утверждённую функцию через Jira и проверенное изменение с Claude Code

> Проведите утверждённую функцию через настоящий эпик Jira, все истории и содержательные подзадачи. Проверьте каждое изменение с Claude Code, подтвердите обновления задач и рассмотрите решение по инструкциям проекта.

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.

Прежде чем функция будет завершена, она может пройти через три системы: документ требований, иерархию задач Jira и репозиторий. Claude Code помогает составлять документы и реализовывать работу, но связи между системами требуют одобрения человека и прямой проверки. Это руководство помогает разработчику или руководителю команды провести одну реальную функцию через весь процесс, включая **каждую утверждённую историю**, исходные тесты, разрешённые обновления Jira и рассмотренное решение об инструкциях проекта.

Процедура основана на документации. BIG CHANGE не обращалась к проекту Jira, не запускала Claude Code, не меняла репозиторий и не измеряла время реализации функции. Точные типы задач, поля, переходы, команды и расходы зависят от вашего проекта и учётной записи.

## Главное изменение

- **Что изменилось:** Функцию можно проследить от утверждённого требования через настоящую родительскую задачу Jira и каждую историю до проверенного кода, исходных проверок и разрешённых обновлений задач.
- **Почему это важно:** Карта задач, протоколы тестов и данные, повторно прочитанные напрямую из Jira, показывают, какая утверждённая работа завершена, а какая история ещё открыта.
- **На что обратить внимание:** Поля и переходы конкретного проекта, операции записи с неопределённым результатом и неудачные проверки требуют решения человека; инструкции Claude Code сами по себе не дают разрешения на работу.

## Перед началом

Выберите функцию с описанием, утверждённым ответственным владельцем, репозиторием, который вам разрешено менять, и исходной приёмочной проверкой, которую можно запустить. Реальная работа должна оправдывать одну родительскую задачу уровня эпика, утверждённые истории и хотя бы одну содержательную подзадачу под историей в выбранном проекте Jira Cloud. Если настоящей подзадачи нет, этот конкретный сквозной результат остаётся незавершённым; добавление декоративной задачи исказит план. Запишите заказчика, полномочия на утверждение, редакцию источника, разрешённые данные, начальный коммит Git, способ изоляции или отката и человека, который вправе проверять код и менять статус Jira.

Проверьте установленные [версию Claude Code, аутентификацию и разрешения](https://code.claude.com/docs/en/permissions). Убедитесь, что файл `CLAUDE.md` репозитория содержит инструкции проекта, но не разрешает редактирование, запуск команд или передачу данных. Определите, какие требования и код можно передавать Claude, какие команды ему разрешены и каков лимит использования для этой функции. Использование Claude Code может расходовать квоту подписки или приводить к начислениям поставщика; [руководство Anthropic по стоимости](https://code.claude.com/docs/en/costs) не определяет ваш счёт заранее.

Для Jira получите разрешение просматривать и создавать нужные типы задач, а затем комментировать их или выполнять переходы от имени уполномоченного пользователя. Закрытый скрипт может использовать [описанный Atlassian способ с электронной почтой и API-токеном](https://developer.atlassian.com/cloud/jira/platform/basic-auth-for-rest-apis); интеграции может потребоваться OAuth. Храните учётные данные в закрытом хранилище секретов. Не включайте их в запросы модели, тексты задач, `CLAUDE.md`, журналы или систему контроля версий. Согласуйте видимость задач до передачи требований в Jira.

По ходу работы ведите семь закрытых записей: `docs/feature-prd.md`, `ticket-plan.json`, журнал записи задач, допускающий только добавление, `ticket-map.json`, подтверждение реализации каждой истории, журнал обновлений Jira и решение по итогам ретроспективы. Это записи о вашей функции, а не файлы, предоставленные или выполненные BIG CHANGE.

## 1. Утвердите точную версию PRD

Передайте Claude Code действительно утверждённое описание функции и попросите выявить нерешённые вопросы до подготовки `docs/feature-prd.md`. Документ должен содержать заказчика и утверждающего владельца, редакцию входных данных, проблему и целевого пользователя, границы и исключения, пронумерованные идентификаторы требований, приёмочные проверки и источники доказательств, нефункциональные ограничения, проект Jira и открытые вопросы. Ответственный человек должен сравнить черновик с исходным описанием и утвердить одну точную редакцию содержимого и её хеш. Решите существенные вопросы до создания задач или редактирования кода.

Хеш даёт последующим записям точный источник. При изменении PRD повторно рассмотрите затронутый план задач и проверки; неудачная реализация не повод переписывать критерии приёмки так, чтобы получить успешный результат.

## 2. Выясните иерархию и поля этого проекта Jira

С помощью разрешённых запросов **только для чтения** к Jira REST API v3 постранично прочитайте `GET /rest/api/3/issue/createmeta/{projectIdOrKey}/issuetypes`. Для каждого предложенного типа задачи постранично прочитайте `GET /rest/api/3/issue/createmeta/{projectIdOrKey}/issuetypes/{issueTypeId}`, чтобы определить обязательные поля создания и допустимые значения. Atlassian помечает широкую операцию `GET /issue/createmeta` как устаревшую в своём [справочнике API задач](https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issues/).

Подтвердите настоящую родительскую задачу, эквивалентную эпику, дочерние задачи уровня истории и поддерживаемые подзадачи для этого проекта. Atlassian описывает [стандартную иерархию и её настройку](https://support.atlassian.com/jira-cloud-administration/docs/configure-the-issue-type-hierarchy/); названия и идентификаторы типов не универсальны. Проверьте, как поле Parent проекта работает на каждом дочернем уровне и какие пользовательские поля или настройки видимости нужны при создании. Если проект не способен представить утверждённую структуру, запишите недостающий тип, поле или разрешение и приостановите создание. Обычная ссылка между задачами не создаёт родительско-дочернюю связь.

## 3. Проверьте весь план задач до записи

Сопоставьте каждое требование PRD и приёмочную проверку в `ticket-plan.json`. Запишите его `planVersion`, хеш PRD, сайт и ключ проекта Jira, локальный идентификатор запуска, утверждающего план и время. Для каждой предлагаемой задачи запишите уникальный локальный ID, предполагаемый локальный ID родителя, обнаруженный ID типа, обязательные поля проекта, сводку, описание, идентификаторы требований и приёмки, владельца и разрешённую видимость. Число историй и подзадач определяется утверждённой работой. Каждая подзадача должна выполнять настоящую работу под своей действительной историей.

Jira REST v3 использует **Atlassian Document Format (ADF)**, структурированный документ JSON, для многострочных описаний и комментариев. Подготовьте документы из утверждённого содержимого и проверяйте возвращённые сайтом метаданные полей перед составлением каждого запроса. [API задач](https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issues/) описывает создание, но не предоставляет готовый объект полей для неизвестного проекта. Человек должен утвердить всю структуру, покрытие всех требований, родительские связи и точный адрес записи до любого `POST`.

## 4. Сначала создайте родителей и повторно прочитайте каждую задачу

Создайте утверждённого родителя через `POST /rest/api/3/issue`, затем его истории, затем каждую настоящую подзадачу. Перед **каждым** запросом добавьте в закрытый журнал строку с ID запуска, локальным ID задачи, подтверждённым ключом родителя, если применимо, адресом назначения, хешем точного утверждённого запроса, временем попытки в UTC и состоянием `pending`. Не включайте токен. Получив HTTP 201, запишите возвращённые Jira ID и ключ задачи, затем напрямую выполните `GET /rest/api/3/issue/{issueIdOrKey}`. Сравните проект, тип, сводку, описание или ссылку на PRD и родителя с утверждённым планом. Отметьте строку как `confirmed` только после повторного чтения. Подтверждённый родитель позволяет создавать дочерние задачи.

Если запрос превысил время ожидания или ответ потерян, отметьте его как `unknown`. Проверьте Jira по проекту, времени, утверждённой сводке и ссылке на план, непосредственно откройте вероятные совпадения и попросите уполномоченного владельца установить их идентичность. [Atlassian предупреждает о возможной задержке поиска после записи](https://developer.atlassian.com/cloud/jira/platform/search-and-reconcile/). Отсутствие результата не доказывает, что создание не удалось. ID запуска и журнал помогают сверке, но не заставляют сервер отклонять повторное создание. Никогда не повторяйте вслепую `POST` с неопределённым результатом.

Прочитайте готовую структуру напрямую и занесите в `ticket-map.json`: каждый локальный ID, реальные Jira ID и ключ, канонический URL задачи, проект, тип, ключ родителя, идентификаторы PRD и приёмки, время повторного чтения и ссылку на журнал. Сравните **все** утверждённые задачи и критерии с PRD. Прекратите дальнейшие записи, если задача отсутствует или прикреплена не к тому родителю; используйте проверенную процедуру исправления проекта.

## 5. Реализуйте и независимо проверьте каждую утверждённую историю

Выполняйте утверждённые истории в порядке зависимостей. Для каждой запишите ключ Jira, начальный коммит Git и ветку или рабочее дерево, исходную приёмочную команду, разрешённые пути и команды. Попросите Claude Code использовать [Plan mode](https://code.claude.com/docs/en/common-workflows), чтобы сопоставить критерии истории с репозиторием. Разработчик проверяет план и разрешает ограниченное редактирование. Граница истории делает изменение удобным для проверки, но не исключает остальные утверждённые истории из функции.

После редактирования сохраните точный diff, исходную проверочную команду с полным выводом и статусом завершения, соответствующие целевые тесты и вердикт для каждого ID требования. Проверьте настоящий код и журналы. Письменный план, созданные файлы или слова Claude об успешных тестах не доказывают, что изменение работает. Приостановите историю при неудачной проверке, неожиданном секрете, изменении зависимостей, внешней записи или масштабном рефакторинге; исправляйте в утверждённых границах и повторяйте исходную проверку. Отдельный проверяющий код решает, принять получившийся коммит или оставить diff на рассмотрении. Запишите это решение для каждой истории. [Наш прежний гид по одному проверенному изменению с Claude Code](https://bigchange.ai/blog/superpowers-claude-code-plan-test-review-change-guide) охватывает более узкий этап проверки кода; PRD и полная структура Jira здесь задают границы всей функции.

## 6. Подтвердите разрешённые обновления Jira

Для каждой проверенной истории прочитайте текущий статус Jira и запросите `GET /rest/api/3/issue/{key}/transitions?expand=transitions.fields`. Проверьте переход, действительно доступный этому пользователю, его конечный статус, обязательные поля и допустимые значения. Затем уполномоченный владелец может отправить выбранный переход через `POST /rest/api/3/issue/{key}/transitions` со значениями полей, определёнными для проекта. Снова напрямую прочитайте задачу и подтвердите новый статус. Успешная проверка кода сама по себе не разрешает Done, слияние или развёртывание.

Запишите в журнал обновлений Jira статус до записи, предполагаемый переход, пользователя, запрос и ответ. Через `POST /rest/api/3/issue/{key}/comment` опубликуйте фактический ADF-комментарий с доказательствами: принятый коммит или отложенный diff, исходная проверка и целевые тесты, оставшиеся сбои и решение проверяющего. Повторно прочитайте ID и текст созданного комментария из [API комментариев](https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-comments/) Jira. Если ответ любой записи неясен, непосредственно проверьте статус или комментарии до рассмотрения ещё одного запроса. Пустой список переходов или недоступное обязательное поле — пробел в процессе или разрешениях, который нужно решить с владельцем проекта, а не повод выдумать ID.

## 7. Решите, нужно ли менять `CLAUDE.md` в проекте

Сравните реальные записи PRD, задач, diff, тестов, проверки и Jira. Попросите Claude о краткой ретроспективе с указанием наблюдавшихся недопониманий или отсутствующих проверок. Человек выбирает точное изменение инструкций либо фиксирует решение ничего не менять, с проверяющим и временем. Если одобрено, проверьте и закоммитьте только diff файла `CLAUDE.md` и его хеш. [Руководство Anthropic по памяти](https://code.claude.com/docs/en/memory) описывает инструкции проекта; эта проверка не разрешает будущую работу автоматически. Не добавляйте секреты и не превращайте предположительный урок в правило проекта.

## Завершение и восстановление

Функция завершена, только когда утверждённая редакция PRD соответствует напрямую подтверждённой структуре эпика, историй и подзадач; **каждая утверждённая история** имеет начальное состояние, принятый diff, доказательства исходной проверки и целевых тестов и независимую проверку; каждый разрешённый переход Jira и комментарий с доказательствами напрямую прочитан повторно; человек принял решение по ретроспективе. Если чего-то не хватает, запишите точный оставшийся этап. [Выбор первой задачи для ИИ](https://bigchange.ai/blog/map-work-choose-first-ai-task-guide) заканчивается раньше — на выборе задачи и предложенной проверке; это не подтверждает описанный результат реализации.

Неопределённое создание в Jira остаётся в состоянии `unknown`, пока человек не сверит идентичность. Неверный родитель останавливает создание дочерних задач. Неудачные тесты сохраняют исходные критерии. Недостающий переход или исчерпанный лимит использования оставляют датированную частичную запись для владельца. Ограничьте требования и данные клиентов минимумом, утверждённым для Claude и Jira, проверьте текущие расходы и разрешения учётной записи и предусмотрите ресурсы на человеческую проверку кода. Руководство описывает условный путь через инструменты и не сообщает о завершённой BIG CHANGE функции, записи в Jira, запуске модели, измеренной экономии, слиянии или развёртывании.

## Источники и дополнительные материалы

- [Atlassian, операции с задачами Jira Cloud REST API v3](https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issues/): ограниченные метаданные создания, создание и чтение задач, операции переходов. Поля и идентификаторы проекта читателя нужно выяснять в самом проекте.
- [Atlassian, комментарии задач](https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-comments/): создание и повторное чтение ADF-комментариев. Разрешения и реальный ответ зависят от сайта.
- [Atlassian, поиск и сверка](https://developer.atlassian.com/cloud/jira/platform/search-and-reconcile/): объясняет, почему отсутствие результата сразу после записи не разрешает неопределённое создание.
- [Atlassian, иерархия типов задач](https://support.atlassian.com/jira-cloud-administration/docs/configure-the-issue-type-hierarchy/): стандартные уровни и настройка; структуру выбранного проекта всё равно необходимо проверить.
- [Anthropic, рабочие процессы Claude Code](https://code.claude.com/docs/en/common-workflows), [разрешения](https://code.claude.com/docs/en/permissions), [память](https://code.claude.com/docs/en/memory) и [стоимость](https://code.claude.com/docs/en/costs): планирование, полномочия на редактирование, инструкции `CLAUDE.md` и использование. Они не документируют выполнение этой функции.

## Sources

- [Atlassian Jira Cloud REST API v3, задачи](https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issues/) — Описывает ограниченные метаданные создания, POST/GET задач и переходы; широкие метаданные создания устарели. Поля проекта, ID и разрешённые переходы должны поступать с сайта читателя.
- [Atlassian Jira Cloud REST API v3, комментарии задач](https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-comments/) — Описывает создание и повторное чтение ADF-комментариев с учётом действительных разрешений. Для этого руководства комментарии не публиковались.
- [Atlassian, поиск и сверка](https://developer.atlassian.com/cloud/jira/platform/search-and-reconcile/) — Объясняет отложенную согласованность поиска; отсутствие результата не доказывает отсутствие задачи после неопределённого ответа на создание.
- [Atlassian, настройка иерархии типов задач](https://support.atlassian.com/jira-cloud-administration/docs/configure-the-issue-type-hierarchy/) — Объясняет стандартную и настраиваемую иерархию. Уровни выбранного проекта и поведение Parent требуют прямого изучения.
- [Atlassian, базовая аутентификация для REST API](https://developer.atlassian.com/cloud/jira/platform/basic-auth-for-rest-apis/) — Описывает электронную почту с API-токеном для простого закрытого скрипта и отличия интеграций; учётные данные должны оставаться закрытыми.
- [Anthropic Claude Code, распространённые рабочие процессы](https://code.claude.com/docs/en/common-workflows) — Описывает Plan mode и приёмы работы с кодом; не доказывает реализацию или проверки читателя.
- [Anthropic Claude Code, разрешения](https://code.claude.com/docs/en/permissions) — Описывает фактические разрешения инструментов и одобрения; инструкции CLAUDE.md сами по себе не разрешают команды или запись.
- [Anthropic Claude Code, память](https://code.claude.com/docs/en/memory) — Объясняет инструкции проекта в CLAUDE.md; предложенная правка по итогам ретроспективы требует человеческой проверки и не является автоматическим обучением.
- [Anthropic Claude Code, стоимость](https://code.claude.com/docs/en/costs) — Использование и оплата зависят от плана и поставщика; в этом основанном только на документации руководстве расходы или экономия не измерялись.