Ticket in, Merge Request out

You open a Jira ticket and you know what to expect - clear description, linked Figma designs, a Confluence spec page. You know exactly what needs building. You also know the next steps by heart:

• Create a worktree.
• Paste the ticket details into Claude Code.
• Set up the plan.
• Review every commit.
• React to reviews and CI failures.

What if the agent could handle all of that on its own?

I built a custom Claude Code agent that does. You give it a ticket ID. It reads the Jira ticket, fetches the context from Figma and Confluence, creates a worktree, writes a TDD-driven plan, executes it commit by commit, pushes the branch, and opens a merge request.

To skip the tutorial and use it right now, check it out here - https://github.com/akash-joshi/agent-skills/blob/main/agents/ticket.md

How to use it

/ticket ABC-123

The agent reads the Jira ticket, follows linked Figma and Confluence pages, and explores the codebase to understand what's already there. Then it creates a worktree, writes an implementation plan, and starts executing - one commit at a time, tests first, implementation second.

When it's done, you get a merge request URL.

The commit history looks something like this:

6b86ed1 [ABC-123] add password validation with length and character checks
3a2fb41 [ABC-123] pass autologin params to createAccount
fcd9f4a [ABC-123] add redirect to dashboard after signup

Each commit has tests. Each commit compiles. Each one does one thing.

The agent also writes a plan.md in the worktree that tracks its progress:

✅ Commit 1: Add password validation

### Brief requirement
The signup form accepts any password. It should enforce minimum length
and reject control characters.

### Red phase
- Submitting with password < 8 chars shows error, does NOT call createAccount
- Submitting with control characters shows error

### Green phase
- Import validateCharacters from existing validation helper
- Add passwordError state, add checks in handleSubmit

### Verification
npm test -- --testPathPattern=SignupForm

---

⬜ Commit 2: Pass autologin parameters to createAccount
...

The plan never gets committed. It's a scratchpad for the agent and you! Useful if a session crashes and you need to pick up where it left off.

Setup

You'll need the Atlassian and Figma MCP servers configured in Claude Code so the agent can read tickets and design files. You'll need a CLI tool to push and open MRs from the terminal: glab for GitLab or gh for GitHub. And git worktree, which is built into git.

Under the hood

The whole thing is two markdown files. A rules file (AGENTS.md) and an agent definition (ticket.md). Both files are public at github.com/akash-joshi/agent-skills.

To read more about configuring your own AGENTS.md file, click here - https://thewriting.dev/claude-code-isnt-just-for-developers/.

AGENTS.md - the rules file

This goes in your repo root or at ~/AGENTS.md. It's the agent's engineering handbook. Every rule you'd enforce in a code review gets written down here so the agent follows it without prompting.

The bit that matters most is plan mode instructions. They tell the agent how to structure its output. Each plan is a series of commit groups with a status indicator (⬜/✅), and each group has a brief requirement, red phase (failing tests), green phase (implementation), and a verification command. Without this, the agent dumps a wall of code that you can't review incrementally.

The other is TDD enforcement, written bluntly: "NEVER write implementation code before writing a failing test." Without this rule, agents skip tests or write them as an afterthought. Every time.

ticket.md - the agent definition

This goes at ~/.claude/agents/ticket.md. A custom agent in Claude Code is a markdown file in ~/.claude/agents/ that describes a workflow. When invoked, the agent gets all the tools of a normal session but follows whatever you've written.

The ticket agent runs in four phases:

1. Gather context. Reads the ticket via Atlassian MCP, fetches design screenshots from Figma links, pulls Confluence content, and pokes around the codebase to understand existing patterns. All the stuff you'd normally copy-paste yourself.
2. Set up worktree and plan. Creates a worktree, switches into it, and writes a structured plan.md following the format from AGENTS.md. Each acceptance criterion maps to a commit, with tests and implementation steps laid out before any code gets written.
3. Execute with TDD. Works through the plan one commit at a time. Failing tests first, minimum implementation to pass them, commit with a [TICKET-ID] prefix, mark it ✅. The agent is explicitly allowed to commit here, a scoped override of the general "don't commit on your own" rule.
4. Push and open MR. Runs the full test suite, pushes the branch, opens an MR with a structured description. Hands you the URL.

Tips and gotchas

• The agent is only as good as your AGENTS.md. Be highly prescriptive with your rules.
• If an MCP call fails, the agent is flying blind. Add a fallback to the agent description: "if MCP fails, ask the user to fix the integration."
• Start from a fresh branch off main. It avoids merge conflicts.

When this doesn't work

If you're still figuring out what the ticket actually requires, exploring approaches, having conversations with the team, prototyping, don't hand it to the agent. It needs a defined target. Ambiguity makes it guess, and its guesses add scope you didn't ask for.

Large refactors that touch dozens of files are also a poor fit. Cross-cutting changes need judgment calls about what to touch and what to leave alone, and those are hard to encode in rules.

For everything in between, CRUD features, UI changes with clear designs, contained bug fixes, it's been the most useful Claude Code workflow I've built.

Try it

Both files live in the agent-skills repo. Drop AGENTS.md at the root of your repo (or at ~/AGENTS.md), drop agents/ticket.md into ~/.claude/agents/, then in any Claude Code session run:

/ticket ABC-123

If you've built something similar or want to compare notes, I'm @thewritingdev on X.