Enterprise Agentic Orchestration

The goal

One command.

I point the agent at a JIRA ticket and it treats the ticket as requirements-as-code — pulls the description and acceptance criteria, writes the change, opens a draft PR, and hands it back to me.

My job is to review and click publish.

The trick isn't a magical model. It's a small, boring set of skills, two MCP servers, and the discipline to keep context tight. We use Cursor at work (I'm on the AI platform team at Nike), but the same setup runs untouched in Claude Code. Anything the agent needs to know lives in a markdown file the runtime auto-loads.

Where the skills live

Drop them here and both runtimes find them:

~/.cursor/skills/        # Cursor (work)
~/.claude/skills/         # Claude Code (personal)
  ├── implement-jira-ticket.md
  ├── review-pr.md
  ├── project-overview.md      # referenced by both
  └── pr-template.md           # referenced by implement-jira-ticket

Same markdown, same prompts — the runtime picks them up either way. That's the whole portability story.

Personal first, team later

I built this for myself before pitching it to anyone. The cost of a local workflow that nobody uses is zero. The cost of a half-baked team workflow that breaks for someone is hours of group debugging and a permanent reputation hit on the idea. Prove it on your own tickets for two or three weeks. Then share what survived.

Wiring up Atlassian MCP

Atlassian publishes an MCP server that exposes JIRA (and Confluence) as tools the agent can call. Once it's connected, the agent can fetch a ticket by ID — description, acceptance criteria, comments, links — without me copy-pasting anything. From a prompt's perspective, the only thing I have to say is:

Execute ticket ABC-1234

That's the whole user input. The skill handles the rest.

Why gh instead of the GitHub MCP

There's a perfectly good GitHub MCP. I don't use it. The GitHub CLI (gh) does everything I need — open PRs, post review comments, fetch diffs, read issues — and it costs the agent almost no extra context to use.

Two reasons that compound:

• Less tool surface, more accuracy. Every MCP tool you wire up adds tokens to every turn and adds another option the model has to choose between. More choices, more wrong choices.
• The model already knows gh.It's in the training data. A line in the skill that says "use ghfor all GitHub operations" is enough — no schema, no examples, no MCP handshake.

Rule of thumb: if a CLI exists and the model has clearly seen it, prefer the CLI over an MCP. Save MCP for systems the model doesn't already know how to talk to (JIRA, internal services, databases).

The implement-jira-ticket skill

This is the workhorse. Sketch of what it does:

1. Read project-overview.mdfor context: what the webapp is, who visits it, what we're trying to do for them. This is the "why" that stops the agent from making technically-correct but product-wrong choices.
2. Pull the ticket via the Atlassian MCP. Description, acceptance criteria, any linked tickets.
3. Plan the change. Identify files. Make edits.
4. Read pr-template.mdfor our PR template. Write the PR description against it — summary, test plan, screenshots if it's UI.
5. Open a draft PR with gh pr create --draft. Stop and hand back to me.

The draft step is the load-bearing one. It's the human-in-the-loop. The agent never publishes; I do, after I've actually read the diff. Same friction as a normal code review, but the first 90% is done.

The review-pr skill

Mirror image. I give it a PR number or URL:

Review PR #4567

The skill:

1. Fetches the PR with gh pr view and the diff with gh pr diff.
2. Finds the linked JIRA ticket (we put the ID in the branch name and PR title, so this is a string match) and reads the description and acceptance criteria via the Atlassian MCP.
3. Reviews the diff against the ticket — does the code actually do what the ticket asks? Are the acceptance criteria covered?
4. Reports findings in three buckets: critical (bugs, missing requirements, security), medium (design smells, missing tests), minor (style, naming, doc nits).
5. Shows the list to me first. I pick which ones become real PR comments. Only then does the agent post them with gh pr review.

Same human-in-the-loop pattern. The agent does the reading, I do the publishing. I've never had it post a review I regret because it can't.

How it fits together

Two skills, one core. The skills compose shared context (project-overview.md, pr-template.md), share the same tool layer (Atlassian MCP + gh), and both end at a human review step.

What's next

Once the skills have proven themselves on my own tickets, the next step is checking them into a shared repo so the rest of the team can use them. Skills are just markdown — they version, diff, and review like any other code. The skill files become a living part of how the team builds, instead of tribal knowledge that lives in one person's home directory.

Until then: keep it personal, keep the context tight, and let the agent do the boring 90%.