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

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

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

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

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

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

Проверьте установленные версию Claude Code, аутентификацию и разрешения. Убедитесь, что файл CLAUDE.md репозитория содержит инструкции проекта, но не разрешает редактирование, запуск команд или передачу данных. Определите, какие требования и код можно передавать Claude, какие команды ему разрешены и каков лимит использования для этой функции. Использование Claude Code может расходовать квоту подписки или приводить к начислениям поставщика; руководство Anthropic по стоимости не определяет ваш счёт заранее.

Для Jira получите разрешение просматривать и создавать нужные типы задач, а затем комментировать их или выполнять переходы от имени уполномоченного пользователя. Закрытый скрипт может использовать описанный Atlassian способ с электронной почтой и API-токеном; интеграции может потребоваться 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 задач.

Подтвердите настоящую родительскую задачу, эквивалентную эпику, дочерние задачи уровня истории и поддерживаемые подзадачи для этого проекта. Atlassian описывает стандартную иерархию и её настройку; названия и идентификаторы типов не универсальны. Проверьте, как поле Parent проекта работает на каждом дочернем уровне и какие пользовательские поля или настройки видимости нужны при создании. Если проект не способен представить утверждённую структуру, запишите недостающий тип, поле или разрешение и приостановите создание. Обычная ссылка между задачами не создаёт родительско-дочернюю связь.

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

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

Jira REST v3 использует Atlassian Document Format (ADF), структурированный документ JSON, для многострочных описаний и комментариев. Подготовьте документы из утверждённого содержимого и проверяйте возвращённые сайтом метаданные полей перед составлением каждого запроса. API задач описывает создание, но не предоставляет готовый объект полей для неизвестного проекта. Человек должен утвердить всю структуру, покрытие всех требований, родительские связи и точный адрес записи до любого 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 предупреждает о возможной задержке поиска после записи. Отсутствие результата не доказывает, что создание не удалось. ID запуска и журнал помогают сверке, но не заставляют сервер отклонять повторное создание. Никогда не повторяйте вслепую POST с неопределённым результатом.

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

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

Выполняйте утверждённые истории в порядке зависимостей. Для каждой запишите ключ Jira, начальный коммит Git и ветку или рабочее дерево, исходную приёмочную команду, разрешённые пути и команды. Попросите Claude Code использовать Plan mode, чтобы сопоставить критерии истории с репозиторием. Разработчик проверяет план и разрешает ограниченное редактирование. Граница истории делает изменение удобным для проверки, но не исключает остальные утверждённые истории из функции.

После редактирования сохраните точный diff, исходную проверочную команду с полным выводом и статусом завершения, соответствующие целевые тесты и вердикт для каждого ID требования. Проверьте настоящий код и журналы. Письменный план, созданные файлы или слова Claude об успешных тестах не доказывают, что изменение работает. Приостановите историю при неудачной проверке, неожиданном секрете, изменении зависимостей, внешней записи или масштабном рефакторинге; исправляйте в утверждённых границах и повторяйте исходную проверку. Отдельный проверяющий код решает, принять получившийся коммит или оставить diff на рассмотрении. Запишите это решение для каждой истории. Наш прежний гид по одному проверенному изменению с Claude Code охватывает более узкий этап проверки кода; 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 комментариев Jira. Если ответ любой записи неясен, непосредственно проверьте статус или комментарии до рассмотрения ещё одного запроса. Пустой список переходов или недоступное обязательное поле — пробел в процессе или разрешениях, который нужно решить с владельцем проекта, а не повод выдумать ID.

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

Сравните реальные записи PRD, задач, diff, тестов, проверки и Jira. Попросите Claude о краткой ретроспективе с указанием наблюдавшихся недопониманий или отсутствующих проверок. Человек выбирает точное изменение инструкций либо фиксирует решение ничего не менять, с проверяющим и временем. Если одобрено, проверьте и закоммитьте только diff файла CLAUDE.md и его хеш. Руководство Anthropic по памяти описывает инструкции проекта; эта проверка не разрешает будущую работу автоматически. Не добавляйте секреты и не превращайте предположительный урок в правило проекта.

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

Функция завершена, только когда утверждённая редакция PRD соответствует напрямую подтверждённой структуре эпика, историй и подзадач; каждая утверждённая история имеет начальное состояние, принятый diff, доказательства исходной проверки и целевых тестов и независимую проверку; каждый разрешённый переход Jira и комментарий с доказательствами напрямую прочитан повторно; человек принял решение по ретроспективе. Если чего-то не хватает, запишите точный оставшийся этап. Выбор первой задачи для ИИ заканчивается раньше — на выборе задачи и предложенной проверке; это не подтверждает описанный результат реализации.

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

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