Example: The Ticket Management Workflow

Relevant source files

The following files were used as context for generating this wiki page:

• .claude/commands/ticket.md
• .mcp.json
• README.md
• CLAUDE.md
• .claude/agents/code-reviewer.md
• .github/workflows/pr-claude-code-review.yml

The Ticket Management Workflow provides a powerful automation layer that connects Claude Code directly to external issue tracking systems like JIRA or Linear. Its primary purpose is to streamline the development lifecycle by allowing Claude to read a ticket, understand its requirements, implement the corresponding feature or fix, and update the ticket's status. This is orchestrated through a combination of a custom slash command, /ticket, and a backend integration system known as MCP (Model Context Protocol) servers.

This system is designed to significantly reduce manual overhead for developers. By invoking a single command, a developer can trigger a complete workflow that includes fetching ticket details, creating a new git branch, implementing the code changes, and preparing a pull request, all while linking the work back to the original ticket. This ensures that development work is tightly coupled with project management requirements from start to finish.

Sources: README.md:29-34, .claude/commands/ticket.md

Architecture and Configuration

The backbone of the ticket management workflow is the Model Context Protocol (MCP). MCP servers act as local bridges between Claude Code and external APIs, such as JIRA, Linear, GitHub, and Slack. These servers expose a set of tools (e.g., jira_get_issue, jira_update_issue) that Claude can use to interact with these external services.

Sources: README.md:144-150

This diagram illustrates the high-level architecture of the MCP integration.

MCP Server Configuration

MCP servers are defined in the .mcp.json file at the project root. This file specifies which servers to run, how to run them, and what environment variables they require for authentication.

Sources: README.md:148, .mcp.json

Example .mcp.json Configuration

The following snippet shows how JIRA, Linear, GitHub, and other services are configured. Each server is defined as a stdio process, launched using npx with the appropriate package.

{
  "mcpServers": {
    "jira": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@anthropic/mcp-jira"],
      "env": {
        "JIRA_HOST": "${JIRA_HOST}",
        "JIRA_EMAIL": "${JIRA_EMAIL}",
        "JIRA_API_TOKEN": "${JIRA_API_TOKEN}"
      }
    },
    "linear": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@anthropic/mcp-linear"],
      "env": { "LINEAR_API_KEY": "${LINEAR_API_KEY}" }
    },
    "github": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@anthropic/mcp-github"],
      "env": { "GITHUB_TOKEN": "${GITHUB_TOKEN}" }
    }
  }
}

Sources: .mcp.json:2-27, README.md:183-193

Configuration Fields

The mcpServers object contains key-value pairs where the key is the server name and the value is its configuration object.

Field	Required	Description
type	Yes	The server type. stdio is used for local processes.
command	For stdio	The executable to run (e.g., npx, python).
args	No	An array of command-line arguments for the executable.
env	No	A map of environment variables to pass to the process. Supports ${VAR} expansion for secure handling of secrets.

Sources: README.md:168-177, .mcp.json

The /ticket Command Workflow

The entire workflow is initiated by the user with the /ticket slash command, followed by a ticket identifier (e.g., /ticket PROJ-123). This command is defined in .claude/commands/ticket.md and contains the high-level instructions for Claude to follow.

Sources: README.md:32-34, .claude/commands/ticket.md

Command Definition

The command is configured to use tools for reading files and interacting with the git repository. The $ARGUMENTS variable captures the ticket ID provided by the user.

---
description: Read a ticket, understand the requirements, and implement the feature.
allowed-tools: Bash(git:*), Read, Grep
---

# Your task is to implement the ticket: $ARGUMENTS

## Steps
1.  **Understand the Goal**: Read the ticket details to fully understand the acceptance criteria and context.
2.  **Explore the Code**: Use `Grep`, `Read`, and `Glob` to find relevant files.
3.  **Formulate a Plan**: Outline the changes you will make.
4.  **Create a Branch**: Use `git` to create a new branch following team conventions.
5.  **Implement**: Write the code, following all project skills and patterns.
6.  **Update Ticket**: After implementation, update the ticket status and link the PR.

Sources: .claude/commands/ticket.md:1-14

Execution Flow

When a user runs /ticket PROJ-123, Claude executes a sequence of actions involving the user, the MCP server, and the local file system/git repository.

This sequence diagram illustrates the typical flow of the /ticket command.

Workflow Steps Summary

Step	Action	Tools Used	Source
1. Fetch Ticket	Claude calls the MCP server (e.g., jira_get_issue) to retrieve ticket details.	MCP Server	README.md:202-203
2. Analyze Requirements	Claude parses the description and acceptance criteria.	Internal	README.md:205-209
3. Explore Codebase	Claude uses Read, Grep, and Glob to find relevant files.	Read, Grep	.claude/commands/ticket.md:9
4. Create Branch	A new git branch is created, following project conventions.	Bash(git:*)	README.md:212, CLAUDE.md:23
5. Implement Feature	Claude writes or modifies code to satisfy the ticket requirements.	Write, Edit	README.md:214
6. Update Ticket Status	Claude calls the MCP server again to update the ticket status (e.g., to "In Review").	MCP Server	README.md:216-217
7. Create Pull Request	Claude creates a pull request, linking it back to the ticket.	Bash(gh:*)	README.md:219

Summary

The Ticket Management Workflow is a core automation feature that integrates Claude Code with external project management tools. By leveraging MCP servers and a custom /ticket command, it automates the entire development cycle from ticket analysis to pull request creation. This not only accelerates development but also ensures consistency and adherence to project standards by programmatically handling branching, implementation, and status updates.

Sources: README.md:29-34