· 6 min read

From Jira Ticket to Pull Request, Without Leaving the Chat

github-copilot ai developer-experience talks

On May 21st I gave a talk at the Schiphol GitHub Copilot Community of Practice. It was a beginner-friendly session about something I’ve been quietly building a workflow around: taking a Jira ticket and ending up with a pull request without ever leaving the chat.

It was also the first time since 2019 that I stood in front of an actual audience. I’ve kept giving technical talks and demos in the meantime. Lots of them online, with audiences ranging from a handful of people on a call to a couple dozen on a webinar. But the last in-person crowd was a DevOps Amsterdam meetup, and that was a long time ago (pre-covid). Honestly, I’d forgotten how much fun it is. Reading the room, riffing off reactions, having a real conversation after the slides come down: none of that translates to a webcam.

What the talk was about

A typical feature touches five or more tools: Jira, the browser, the editor, the terminal, GitHub. Every switch costs context and focus.

The premise of the talk was simple: if you can keep an agent inside one chat session, and give it the right small set of tools, it can do the boring parts of “ticket → PR” for you. Read the ticket. Plan. Implement. Run the tests. Open the PR. Link it back to the ticket. No tab-switching, no copy-pasting acceptance criteria, no forgetting to update the Jira workitem.

The audience was developers who hadn’t really used agentic Copilot workflows yet, so the goal was to demystify, not to impress. I wanted people to walk out thinking “I can set this up on Monday,” not “that was cool but it’s magic.”

The demo workload

I needed a small project that was easy to read and Schiphol-themed. So I built schiphol-cop-demo, a tiny Python CLI that prints a fake departures board to your terminal:

$ python -m schiphol_flights
DEPARTURES — Schiphol (AMS)

FLIGHT    DESTINATION             GATE    SCHEDULED   STATUS
KL1001    London (LHR)            D04     06:25       Departed
HV5821    Barcelona (BCN)         H06     06:55       Departed
KL1745    New York (JFK)          E18     07:10       Delayed +25m
...

You can filter by terminal or status:

python -m schiphol_flights --terminal D --status delayed

The point of the CLI is that I have an example codebase to develop a feature against. So why not choose Python without any dependencies that just prints out a small departures board.

Wiring up the tools

The setup is deliberately boring: no MCP servers, just CLIs that Copilot can call as bash tools. The agent doesn’t get magic powers. It gets a short list of CLIs it is allowed to use, and clear instructions on what to do with them.

Those instructions live in a layered stack that all ships with every request:

  • .github/copilot-instructions.md — repo-wide policy, applies to every contributor.
  • .github/instructions/*.instructions.md — path-scoped rules (per language, per folder).
  • AGENTS.md at the repo root — agent-mode and CLI permissions.

Priority only matters when two layers conflict. For this demo the interesting layer is AGENTS.md, because that’s where the tool allowlist lives.

The two CLIs people tend not to have seen are acli and gh:

  • acli is the Atlassian CLI. It pulls Jira tickets, lists them, and posts comments back.
  • gh is the GitHub CLI. It opens pull requests with a templated body that links the ticket and the acceptance criteria.

Pulling the full ticket as JSON looks like this:

acli jira workitem view PSR-1234 --json --fields '*all'

The rest of the allowlist is unsurprising: git (read-only, no force-push), pytest, python, pip for dev installs. Anything destructive (merging a PR, rewriting history) needs explicit approval. The agent has to ask.

The workflow in one breath

Once the tools are wired up, the conversation has five beats:

  1. Pull context. acli reads the ticket as JSON, plus any ADRs in docs/adr/ that touch the area.
  2. Plan. /plan turns the ticket into a checklist of tasks, files, and approach.
  3. Implement. The agent edits files and runs pytest.
  4. Iterate. Refine in chat and editor until the diff looks right.
  5. Open PR. gh pr create from the diff, with a body that links the ticket and ticks off the acceptance criteria.

That’s it. No new framework, no new IDE, no new vendor. Just an AGENTS.md, two CLIs most teams already have lying around, and a small project to demo on.

The PR the agent opened is still there: PSR-2758: Add airline filter and delay summary to departures CLI. It starts from a Jira ticket, adds an --airline flag and a summary footer to the CLI, ships 18 passing tests, and links the ticket in the PR body. All of that was produced inside one chat session.

What I asked people to take away

Five things, roughly in the order they matter during a session:

  • Always start with /plan. Before the agent writes a single line of code, have it read the ticket, look at the relevant code, and come back with a plan you can approve. It catches misunderstandings while they’re cheap, and it gives you a checkpoint before any edits hit the repo.
  • Use /compact before the window fills. Around 80% of the context window, run /compact so Copilot summarises the session and frees room. Skip it and the agent starts forgetting your constraints halfway through the next change.
  • Analyse your sessions afterwards. End a run by asking the agent to “do a deep technical analysis of this session and output it as a static HTML file.” Read it. You’ll spot anti-patterns and the moments where things went sideways.
  • Constrain the agent with an allowlist. Don’t hand it the keys to everything and hope. List the tools it can use, and gate the destructive ones behind explicit approval.
  • Make your repository agent-friendly. ADRs, ticket templates, PR templates, an AGENTS.md, a clean test command: if they’re committed in the repo, the agent picks them up. If they live in someone’s head, it can’t.

The human bit

I expected to be more nervous than I was. Turns out I just really enjoyed it. You can see when people get it, and you can see when they don’t, and you adjust on the spot. That feedback loop is the part I’d been missing. I’d like to do this more often.

Thanks to the Schiphol CoP for the invite and for being a friendly first audience to come back to. The full repo lives at scholtenmartijn/schiphol-cop-demo, and the slides are in the same repo if you want to flip through them.