An approved feature can cross three different systems before it is finished: a requirements document, a Jira issue hierarchy and a repository. Claude Code can help draft and implement the work, but the links between those systems need human approval and direct checks. This guide takes a developer or team lead through one real feature, including every approved story, its original tests, authorized Jira updates and a reviewed decision about project guidance.

This is a documentation-based procedure. BIG CHANGE did not access a Jira project, run Claude Code, change a repository or measure a feature delivery time. The precise issue types, fields, transitions, commands and costs come from your project and account.

The big change

  • What changed: A feature can be tracked from its approved requirement through a real Jira parent and every story to reviewed code, original checks and authorized issue updates.
  • Why it matters: The issue map, test records and direct Jira readbacks show which approved work is finished and which story remains open.
  • What to watch: Project-specific fields and transitions, uncertain writes and failed checks require human resolution; Claude Code guidance does not authorize work by itself.

Before you start

Choose a feature with an owner-approved brief, a repository you may edit and an original acceptance check you can run. Its actual work must warrant one epic-level parent, its approved stories and at least one meaningful subtask under a story in the selected Jira Cloud project. If the work has no real subtask, this particular end-to-end outcome is pending; adding a decorative issue would falsify the plan. Record the requester, approval authority, source revision, permitted data, starting Git commit, isolation or rollback route and the person who may review code and change Jira status.

Check your installed Claude Code version, authentication and permissions. Confirm that the repository's CLAUDE.md gives project guidance without granting permission to edit, run commands or send data. Decide which requirements and code Claude may receive, which commands it may run, and the usage limit for this feature. Claude Code usage may count against a subscription allowance or incur provider charges; Anthropic's cost guide does not establish your bill in advance.

For Jira, obtain permission to browse and create the relevant issue types and, later, to comment or transition issues as the authorized actor. A private script can use the email and API-token method Atlassian documents; an integration may need OAuth. Keep credentials in private secret storage. Exclude them from prompts, issue text, CLAUDE.md, logs and source control. Agree on issue visibility before sending requirements to Jira.

Keep seven private records as you proceed: docs/feature-prd.md, ticket-plan.json, an append-only issue-write journal, ticket-map.json, one implementation receipt per story, a Jira update journal and a retrospective decision. These are records of your feature, not files supplied or executed by BIG CHANGE.

1. Approve one exact PRD

Give Claude Code the actual approved feature brief and ask it to identify unresolved questions before drafting docs/feature-prd.md. The document needs the requester and approving owner, input revision, problem and intended user, scope and exclusions, numbered requirement IDs, acceptance checks and their evidence sources, nonfunctional constraints, Jira project and open questions. Have a responsible person compare the draft with the original brief and sign off on one exact content revision and hash. Resolve substantive questions before creating issues or editing code.

The hash gives later records a precise source. If the PRD changes, review the affected ticket plan and checks again; an implementation failure is not a reason to rewrite acceptance criteria into a pass.

2. Discover this project's Jira hierarchy and fields

With authorized read-only Jira REST API v3 requests, page through GET /rest/api/3/issue/createmeta/{projectIdOrKey}/issuetypes. For each proposed issue type, page through GET /rest/api/3/issue/createmeta/{projectIdOrKey}/issuetypes/{issueTypeId} to find its required create fields and allowed values. Atlassian marks the broad GET /issue/createmeta operation as deprecated in its issue API reference.

Confirm an actual epic-equivalent parent, story-level children and supported subtasks for this project. Atlassian describes the default hierarchy and its configuration; type names and IDs are not universal. Inspect how the project's Parent field works for each child level and which custom fields or visibility settings creation requires. If the project cannot represent the approved graph, record the missing type, field or permission and hold creation. A generic issue link does not make an issue a child.

3. Review the entire ticket plan before writing

Map every PRD requirement and acceptance check into ticket-plan.json. Record its planVersion, PRD hash, Jira site and project key, a local run ID and the plan approver and time. For each proposed issue, record a unique local ID, intended parent local ID, discovered issue-type ID, the required project fields, summary, description, requirement and acceptance IDs, owner and allowed visibility. The approved work determines the number of stories and subtasks. Every subtask must do genuine work under its actual story.

Jira REST v3 uses Atlassian Document Format (ADF), a structured JSON document, for multiline issue descriptions and comments. Prepare those documents from approved content and check the site's returned field metadata before forming each request. The issue API documents the create operation; it cannot supply a ready-made field object for an unknown project. A person should approve the complete graph, full requirement coverage, parent relations and exact intended write destination before any POST.

4. Create parents first and read each issue back

Create the approved parent through POST /rest/api/3/issue, then its stories, then each real subtask. Before each request, append a private journal row with the run ID, local issue ID, confirmed parent key when applicable, destination, hash of the exact approved request, UTC attempt time and pending state. Do not include a token. On HTTP 201, record Jira's returned issue ID and key, then directly GET /rest/api/3/issue/{issueIdOrKey}. Compare project, type, summary, description or PRD reference and parent with the approved plan. Mark the row confirmed only after that readback. A confirmed parent unlocks its children.

If a request times out or its response is lost, mark it unknown. Inspect Jira by project, time, approved summary and plan reference, then open any likely match directly and ask the authorized owner to resolve its identity. Atlassian warns that search after a write can lag. No search hit is not proof that creation failed. Your run ID and journal help reconciliation but do not make the server reject duplicate creates. Never replay an uncertain POST blindly.

Read the finished graph directly into ticket-map.json: each local ID, actual Jira ID and key, canonical issue URL, project, type, parent key, PRD and acceptance IDs, readback time and journal reference. Compare all approved issues and criteria with the PRD. Stop further writes if an issue is missing or misparented; use the project's reviewed correction process.

5. Implement and independently review every approved story

Work through the approved stories in dependency order. For each one, record its Jira key, starting Git commit and branch or worktree, original acceptance command, permitted paths and commands. Ask Claude Code to use Plan mode to map that story's criteria to the repository. A developer checks the plan and authorizes a bounded edit. The story boundary keeps a change reviewable; it does not remove the remaining approved stories from the feature.

After the edit, preserve the exact diff, the original check command with full output and exit status, relevant targeted tests and a verdict for each requirement ID. Inspect the actual code and logs. A written plan, generated files or Claude's statement that tests passed does not establish a working change. Hold the story on a failed check, unexpected secret, dependency change, external write or broad refactor; repair within the approved scope and rerun the original check. A separate code reviewer decides whether to accept the resulting commit or hold the diff. Record that decision for every story. Our earlier guide to one reviewed Claude Code change covers the narrower code-review stage; the PRD and complete Jira graph here supply the wider feature boundary.

6. Verify authorized Jira updates

For each reviewed story, read its current Jira status and request GET /rest/api/3/issue/{key}/transitions?expand=transitions.fields. Inspect the transition actually available to this actor, its destination and the required fields and permitted values. An authorized owner may then submit the selected transition through POST /rest/api/3/issue/{key}/transitions with the project-resolved field values. Directly read the issue again and confirm its new status. Passing a code check does not itself authorize Done, merge or deployment.

Record the prewrite status, intended transition, actor, request and response in the Jira update journal. Post a factual ADF evidence comment through POST /rest/api/3/issue/{key}/comment: accepted commit or held diff, original check and targeted tests, remaining failures and reviewer decision. Read back the created comment ID and body from Jira's comment API. If either write has an uncertain response, inspect status or comments directly before considering another request. An empty transition list or unavailable required field is a workflow or permission gap to resolve with the project owner, not an invitation to invent an ID.

7. Decide whether CLAUDE.md should change

Compare the actual PRD, ticket, diff, test, review and Jira journals. Ask Claude for a short retrospective that points to observed misunderstandings or missing checks. A human chooses a precise guidance edit or records a no-change decision, with reviewer and time. If approved, inspect and commit only that CLAUDE.md diff and its hash. Anthropic's memory guide describes project guidance; this review does not authorize future work automatically. Do not add secrets or turn a speculative lesson into a project rule.

Completion and recovery

The feature is complete only when the approved PRD revision maps to the directly confirmed epic/story/subtask graph; each approved story has its starting state, accepted diff, original check and targeted test evidence and independent review; each authorized Jira transition and evidence comment has a direct readback; and a human has decided on the retrospective. Record the exact remaining stage if any item is missing. Choosing a first AI task ends earlier, at task selection and a proposed check; it does not establish this implementation result.

An uncertain Jira creation stays unknown until a person reconciles its identity. A wrong parent stops child creation. Failed tests leave their original criteria intact. A missing transition or exhausted usage limit leaves a dated partial record for the owner. Keep requirements and customer data to the minimum approved for Claude and Jira, check current account costs and permissions, and budget for human code review. This guide documents a conditional route through the tools; it reports no completed feature, Jira write, model run, measured saving, merge or deployment by BIG CHANGE.

Sources & further reading