← All resources
AI & delivery
10 min read

A Jira issue is the agent's brief. Ready it first.

On 10 September 2026 GitHub put Jira issues on a Copilot canvas and said the chosen issue travels into the pull request. Four lines on the work item decide whether that handoff is safe.

See Story Studio
The issue you choose is the brief

GitHub's changelog for 10 September 2026 is short. The Copilot app brings Jira issues onto a shared canvas. You choose what moves forward. Copilot carries that issue into investigation, implementation, and pull request preparation.

That is a different job from the ticket you wrote for a refinement meeting. A meeting can finish a half-written issue. The agent reads the fields and starts.

Copilot for Jira has taken assignments since general availability on 25 June 2026. The canvas is the new room: someone picks an issue and sends it. The integration docs already list which fields go with it. This page is the rule for whether you should press the control.

Most issues were written for a meeting

A planning conversation repairs a thin ticket. People interrupt, point at a repo, and remember which comment retired the earlier one. Copilot does not sit in that room.

Four ways the handoff fails before a line of code

The title is a wish

"Improve validation" names a mood. Hidde de Smet's gate for the task, published 17 September 2026, puts that sentence next to a real one: reject an empty display name in src/users/, return the existing error type, add tests beside the current ones, do not change the public API. Only the second gives an agent a place to start and a reviewer a way to stop.

The description is the meeting

Decisions sit in memory. Comments contradict the description. The integration sends title, description, labels, comments, and custom fields such as acceptance criteria. Contradictory comments are part of the packet. The agent does not know which one you abandoned.

The repository is assumed

GitHub's instruction is blunt: to name a repository, mention it in the description or a comment. If you do not, the agent asks, guesses, or opens the pull request in the tree your workspace default happens to pin.

Done is a feeling

"Works as expected" gives nobody a command to run. The same September note asks for expected validation and an out-of-scope line. Without those, a green pull request can still be the wrong change.

If you would not hand that text to a new engineer and leave the room, do not hand it to Copilot.

A ticket can pass this gate and still ship the wrong behaviour with green checks. That failure is a different article: AI can pass the tests without doing the job .

Ready means four lines before the trigger

I keep seeing the same split. The issue is ready to estimate — the team can argue the size — and empty as a brief. Story points do not name a file.

You start a Copilot cloud agent session from Jira by assigning GitHub Copilot, mentioning @GitHub Copilot, or running a Jira automation that uses the Copilot action. Only someone with write access to the repository can do it. The session receives the work item's title, description, labels, comments, and Atlassian custom fields such as acceptance criteria. Workspace custom instructions can pin a default repository so the agent does not stop to ask.

None of that fills a blank outcome. This is not a definition of ready for estimation. That later question is whether the team can size the work. This one is whether the text, alone, is a brief.

Four lines on the issue, before anyone assigns Copilot.

Outcome. Exclusions. How to prove it. Which repository. Miss one, and the issue is not ready.

Whether the team can size the work is a different article: Ready to estimate is not a finished spec.

Three ways teams hand the issue over

The canvas, the assignee field, and the @mention all read the issue. The choice is what you put there first.

A

Assign the issue as it stands

Trigger Copilot from the text already on the work item. Fast, and faithful to a ticket that was never written for an agent.

B

Put the real brief beside the issue

Write a sharper prompt in chat, Slack, or a late comment, and leave the issue body alone.

C

Write the four lines, then trigger

Outcome, exclusions, proof, and repository live on the issue. Only then do you assign, mention, or choose it on the canvas.

Assign it as written

You assign GitHub Copilot, mention @GitHub Copilot, or let an automation fire when the issue reaches a status. The agent reads what is already there.

What actually travels
  • The canvas or the assignee field selects the issue.
  • Copilot receives the title, description, labels, comments, and custom fields such as acceptance criteria.
  • On a public repository, GitHub adds that captured Jira text to the pull request, where anyone can read it.
  • A later @GitHub Copilot mention starts a new session and a new pull request. Continue in Chat, or the linked session on GitHub, updates the current one.
Where this holds
  • No second document. The issue the team already shares is the brief.
  • Status, assignee, and the pull request stay on one work item.
  • Acceptance criteria you already keep in a custom field travel without a copy step. GitHub has read those fields since the April 2026 update.
Where it breaks
  • A slogan and a meeting note become the implementation plan.
  • An automation on "issue created" or "moved to In Progress" fires before anyone has written the four lines.
  • Old comments stay in the packet. The agent treats them as current unless you say otherwise.

The fastest trigger publishes your draft.

Assign Copilot on a public repository and the Jira text lands on the pull request. That includes comments you thought were internal.

Keep the real brief off the issue

Someone writes the precise prompt in a Copilot chat, a Slack thread, or a comment added at the last minute. The description stays as it was for the humans.

What actually travels
  • The useful sentences sit beside the fields the next trigger will read.
  • A @GitHub Copilot mention can carry extra instructions, and that mention starts a session.
  • The canvas still selects the issue. The next person who assigns Copilot gets the old body.
  • A second mention opens a second pull request. It does not extend the first.
Where this holds
  • You can be specific in the moment without rewriting a messy ticket.
  • A developer who knows the tree can name paths the issue never had.
Where it breaks
  • Two briefs. The one the agent was handed, and the one the team thinks is current.
  • A workspace default repository can override a path you only said in chat.
  • The review splits the moment someone mentions Copilot again.

A side brief feels careful.

It is how the issue and the pull request drift apart. The canvas will keep choosing the issue, not your Slack thread.

Write the four lines, then trigger

Before any assignee, mention, automation, or canvas handoff, the work item states the outcome, the exclusions, the proof, and the repository.

Four stacked lines on a ticket: the behaviour to ship, what must not change, the check a reviewer can run, and the repository name
The four lines
  • Outcome: the behaviour that must be true when the pull request opens. One change, not a theme.
  • Exclusions: what must not move — public API, a neighbouring feature, data already in production.
  • Proof: the test, command, or check a reviewer can run. De Smet calls this expected validation.
  • Repository: named in the description, unless workspace custom instructions already pin the only repository this change can land in, and you mean that one.
  • Then assign GitHub Copilot, mention @GitHub Copilot, or choose the issue on the canvas.
Where this holds
  • The packet Copilot carries is the packet you meant.
  • The same four lines give a human reviewer a stop condition.
  • You can refuse the handoff without a debate about the model.
Where it breaks
  • It costs about ten minutes on a ticket that used to take one.
  • A second repository the agent cannot access, a rule that lives only in someone's head, or a check nobody can run still needs a person. The lines make that obvious. They do not remove it.
  • Typing "works as expected" into the proof line is the same gap as leaving it blank.

This is the gate.

Assigning the issue as it stands, or hiding the brief in chat, skips it. Story Studio can help you shape and review the ticket. It does not start a Copilot session.

How the three options compare

Same trigger. Different packet.

QuestionAs writtenSide briefFour lines
What Copilot reads on the next triggerThe issue as it standsThe issue, not the side promptThe four lines
One source of truthYes, and it may be thinNoYes
Repository named before work startsOnly if it was already thereOften only in the side promptOn the issue, or an explicit workspace default you mean
Exclusions a reviewer can seeOnly if the old ticket had themEasy to say, easy to loseRequired
Proof someone can runRareSometimes, then it driftsRequired
Follow-up stays on one pull requestOnly via Continue in ChatA new mention opens a new pull requestSame chat-versus-mention rule, on a stable brief

What Copilot reads on the next trigger

As written

The issue as it stands

Side brief

The issue, not the side prompt

Four lines

The four lines

One source of truth

As written

Yes, and it may be thin

Side brief

No

Four lines

Yes

Repository named before work starts

As written

Only if it was already there

Side brief

Often only in the side prompt

Four lines

On the issue, or an explicit workspace default you mean

Exclusions a reviewer can see

As written

Only if the old ticket had them

Side brief

Easy to say, easy to lose

Four lines

Required

Proof someone can run

As written

Rare

Side brief

Sometimes, then it drifts

Four lines

Required

Follow-up stays on one pull request

As written

Only via Continue in Chat

Side brief

A new mention opens a new pull request

Four lines

Same chat-versus-mention rule, on a stable brief

Use the issue, or do not send it

The canvas did not make the model wiser. It made the issue the thing you pick. These are the rules I would put on the team wall.

  • If the issue states the outcome, the exclusions, the proof, and the repository, then assign GitHub Copilot, mention @GitHub Copilot, or choose it on the canvas.
  • If any of those four is missing, then do not assign, and do not let an automation assign. Write the missing line first.
  • If workspace custom instructions already pin a single repository and this change belongs there, then the issue may omit the repository line. If the change could land somewhere else, name the repository on the issue.
  • If the work needs a repository the agent cannot open, a business rule that is not written down, or a check nobody can run, then a person does that part. A longer prompt does not cover it.
  • If you need to change a pull request that is already open, then use Continue in Chat or the linked GitHub agent session. A new @GitHub Copilot comment starts a new session and a new pull request.
  • If the repository is public, then treat the Jira text as public the moment you assign Copilot. GitHub copies it onto the pull request.
  • If the four lines are present and the agent still opens a green pull request that misses the job, then the ticket failed a later test. Read the guide on criteria that name what must change, what must stay, and what must disappear.

Sources checked for this page

Then the trigger

The September canvas sends the issue you choose. It does not repair the issue.

Assign it when the four lines are on it. Until then the honest status is not ready — for Copilot, and for anyone who was not in the room when the decision was made.

Outcome. Exclusions. Proof. Repository. Then the trigger.

Get the backlog item ready before you estimate it

Acceptance criteria and a ticket the team can build.

See Story Studio