My Claude Code Workflow: From Jira Ticket to Production-Ready Code

As a senior full-stack developer working on e-commerce platforms, I've refined a workflow that significantly accelerates my development process. The secret? Claude Code's CLI is combined with MCP servers for Jira and MySQL, plus some custom commands that supercharge the entire process. Let me walk you through exactly how I turn a Jira ticket into working code.

The Setup: MCP Servers That Actually Matter

Before diving into the workflow, let's talk about my MCP server configuration. While there are hundreds of MCP servers available, I've found two that are essential for my daily work:

1. Jira MCP Server

This is my starting point for every task. The Jira MCP server gives Claude direct access to:

• Ticket descriptions and acceptance criteria
• Comments and discussion threads
• Subtasks and linked issues
• Custom fields (priority levels, story points, sprint assignments)

Configuration:

{
  "mcpServers": {
    "jira": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-jira"],
      "env": {
        "JIRA_URL": "https://your-domain.atlassian.net",
        "JIRA_EMAIL": "your-email@company.com",
        "JIRA_API_TOKEN": "your-api-token"
      }
    }
  }
}

2. MySQL MCP Server

E-commerce means juggling products, orders, customers, inventory, and more. The MySQL MCP server lets Claude:

• Inspect table schemas and relationships
• Understand existing data structures
• Validate queries before execution
• Suggest database migrations

Configuration:

{
  "mcpServers": {
    "mysql": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-mysql"],
      "env": {
        "MYSQL_HOST": "localhost",
        "MYSQL_PORT": "3306",
        "MYSQL_USER": "dev_user",
        "MYSQL_PASSWORD": "your-password",
        "MYSQL_DATABASE": "ecommerce_db"
      }
    }
  }
}

Custom Commands: My Secret Weapons

Before we dive into the workflow, I need to share something that's been a game-changer: custom Claude Code commands. These are reusable prompt templates that I can invoke with slash commands.

I use three essential commands that I've downloaded from the claude code commands directory:

1. Analyze Codebase Command

Before starting any work, I use this to get Claude familiar with my codebase structure:

mkdir -p "$(dirname .claude/commands/analyze-codebase.md)" && curl -o .claude/commands/analyze-codebase.md https://claudecodecommands.directory/api/download/analyze-codebase

This command helps Claude understand:

• Project structure and organization
• Coding patterns and conventions
• Existing services and utilities
• Architecture decisions

2. Lyra Planning Command

For the planning phase, I use Lyra, which structures the planning process:

mkdir -p "$(dirname .claude/commands/lyra.md)" && curl -o .claude/commands/lyra.md https://claudecodecommands.directory/api/download/lyra

Lyra helps Claude create comprehensive, actionable plans with proper risk assessment and time estimates.

3. Code Review Command

After each chunk of work, I use this for thorough code reviews:

mkdir -p "$(dirname .claude/commands/code-review.md)" && curl -o .claude/commands/code-review.md https://claudecodecommands.directory/api/download/code-review

This ensures consistent code quality checks across all my work.

Pro tip: Once these commands are downloaded, they live in your .claude/commands/ directory and can be invoked with slash commands like /analyze-codebase, /lyra, and /code-review. They're project-specific so that each repo can have its own custom commands.

My Five-Step Workflow

Step 0: Analyze the Codebase (First Time on a Ticket)

Before I even look at the Jira ticket, if I'm working on an unfamiliar part of the codebase, I start with:

claude "/analyze-codebase focusing on the services/email and models/cart directories"

This gives Claude a deep understanding of:

• How our email system is structured
• What patterns do we use for cart-related operations
• Which utilities are available
• What dependencies are we using

Example output:

Codebase Analysis Complete:

Architecture Pattern: Service-oriented with repository pattern
- Services handle business logic
- Repositories handle data access
- Controllers are thin, delegating to services

Email System Structure:
- services/EmailService.js: Main email orchestrator
- Uses SendGrid wrapper from lib/sendgrid.js
- Templates in views/emails/ using Handlebars
- All emails logged to the email_logs table

Cart System:
- models/Cart.js: Sequelize model with associations
- models/CartItem.js: Line items with product references
- services/CartService.js: Business logic for cart operations
- Uses Redis for cart session caching

Key Conventions:
- Async/await for all async operations
- Structured logging with Winston
- Error handling with custom AppError class
- All database queries use parameterized statements

Available Utilities:
- lib/validators.js: Input validation helpers
- lib/formatters.js: Price, date formatting
- lib/queue.js: Bull queue for background jobs

Now Claude knows precisely how to write code that fits seamlessly into my project.

Step 1: Read the Jira Ticket

I always start by having Claude read and understand the full Context of the ticket:

claude --plan "Read Jira ticket SHOP-456 and summarize what needs to be done"

This is where the work begins. Claude uses the Jira MCP server to:

• Fetch the ticket details. Basically, it reads the ticket
• Read all comments and discussion
• Identify acceptance criteria
• Note any linked tickets or dependencies

Why this matters: In e-commerce and other complex projects, a seemingly simple feature can have far-reaching implications. A "add wishlist functionality" ticket might have performance requirements, mobile app considerations, or analytics tracking needs buried in the comments. By having Claude read everything first, we don't miss important details. Especially if you have a big monorepo, the Context can be vast and cumbersome.

Example output:

Analyzing Jira ticket SHOP-456...

Summary: Implement abandoned cart email reminders

Key Requirements:
- Send email 24 hours after cart abandonment
- Include cart items with images and prices
- Add "Complete Your Purchase" CTA button
- Apply discount code for first-time abandoners (10% off)

Technical Notes from Comments:
- Use existing SendGrid integration (see SHOP-320)
- Only send to users who have email notifications enabled
- Exclude items that went out of stock
- Add unsubscribe link per GDPR requirements

Linked Issues:
- SHOP-320: Email service setup (completed)
- SHOP-489: Cart persistence optimization (in progress)
- SHOP-502: Discount code system (completed)

Business Context:
- Marketing estimates 15% conversion on abandoned carts
- Target: Send within a 24-26 hour window for optimal engagement

Step 2: Plan Mode with Lyra

Once Claude understands the ticket, I use the Lyra command for structured planning. It will enhance your prompt and ask essential questions that you just did not think of:

claude "/lyra Create a comprehensive plan to implement abandoned cart email reminders. Consider the database schema, existing code patterns, error handling, and integration with our SendGrid service."

Lyra guides Claude to create a more thorough plan with:

• Clear phases and milestones
• Risk assessment for each phase
• Dependencies and prerequisites
• Time estimates based on similar past work
• Success criteria for each phase

Claude now leverages both MCP servers:

• Jira MCP: Pulls in requirements and constraints
• MySQL MCP: Inspects the current database schema to understand what changes are needed

Example Lyra-guided plan output:

Implementation Plan for Abandoned Cart Emails:

=== PHASE 1: DATABASE SETUP ===
Objective: Prepare the data layer for tracking abandoned carts

Tasks:
1. Inspect carts and cart_items tables (MySQL MCP)
2. Add abandoned_at timestamp column to the carts table
3. Create cart_reminder_logs table with fields:
   - id, cart_id, user_id, sent_at, email_opened
   - clicked_through, converted, discount_code_used
4. Add indexes on abandoned_at and user_id for query performance

Prerequisites: None
Dependencies: None
Time Estimate: 1-2 hours
Risk Level: LOW
- Migration is non-breaking (adding columns, not modifying)
- Can be rolled back easily if needed

Success Criteria:
✓ Migration runs without errors in staging
✓ Indexes improve query performance (< 100ms)
✓ Foreign key constraints are correctly set

=== PHASE 2: CART ABANDONMENT DETECTION ===
Objective: Identify carts eligible for reminder emails

Tasks:
1. Create the AbandonedCartService class following existing service patterns
2. Implement detectAbandonedCarts() method
   - Query carts updated 24-26 hours ago
   - Filter by active status and no completed orders
   - Exclude carts with out-of-stock items
3. Add eligibility checker (email consent, first-time vs returning)
4. Integrate with the existing CartService for data access

Prerequisites: Phase 1 complete
Dependencies:
- CartService (services/CartService.js)
- ProductService (for stock checking)
Time Estimate: 2-3 hours
Risk Level: MEDIUM
- Complex business logic with multiple conditions
- Performance concerns with large cart tables

Success Criteria:
✓ Correctly identifies abandoned carts in test scenarios
✓ Handles edge cases (multiple carts, guest users)
✓ Query performance acceptable (< 200ms for 10k carts)
✓ Unit test coverage > 90%

=== PHASE 3: EMAIL GENERATION & SENDING ===
Objective: Create and send personalized reminder emails

Tasks:
1. Create abandoned cart email template (Handlebars)
2. Implement generateEmailContent(cart) method
   - Fetch cart items with product images
   - Calculate subtotal and apply discount if eligible
   - Generate a secure checkout link with the cart ID
3. Integrate with existing EmailService
4. Add error handling and retry logic with Bull queue

Prerequisites: Phase 2 complete
Dependencies:
- EmailService (services/EmailService.js)
- SendGrid wrapper (lib/sendgrid.js)
- Discount code service (services/DiscountService.js)
Time Estimate: 3-4 hours
Risk Level: MEDIUM
- SendGrid rate limits (600 emails/minute on current plan)
- Email rendering across different clients
- Discount code generation could conflict with promos

Success Criteria:
✓ Email renders correctly in major clients (Gmail, Outlook, Apple)
✓ All links work and track properly
✓ Discount codes generate without conflicts
✓ Graceful failure with retry logic

=== PHASE 4: SCHEDULED JOB & MONITORING ===
Objective: Automate email sending and track performance

Tasks:
1. Add a cron job using node-cron (runs every hour)
2. Process abandoned carts in batches (100 at a time)
3. Log all email sends to cart_reminder_logs
4. Add metrics to the monitoring dashboard:
   - Emails sent per day
   - Open rate, click rate, conversion rate
5. Set up alerts for failures

Prerequisites: Phase 3 complete
Dependencies:
- Existing cron job system (lib/scheduler.js)
- Monitoring system (Datadog integration)
Time Estimate: 2 hours
Risk Level: LOW
- Following established patterns
- Good observability from the start

Success Criteria:
✓ Job runs reliably every hour
✓ Batch processing prevents memory issues
✓ All metrics tracked and visible in the dashboard
✓ Alerts fire on sustained failures

=== PHASE 5: TESTING & VALIDATION ===
Objective: Ensure reliability and compliance

Tasks:
1. Unit tests for all service methods
2. Integration tests with SendGrid sandbox
3. Test discount code generation and validation
4. Verify GDPR compliance (unsubscribe functionality)
5. Load testing with 10k abandoned carts

Prerequisites: All previous phases complete
Dependencies: Testing infrastructure
Time Estimate: 2-3 hours
Risk Level: LOW
- Using existing test patterns and infrastructure

Success Criteria:
✓ Test coverage > 85%
✓ All integration tests pass
✓ Load test shows acceptable performance
✓ GDPR compliance verified by legal team

=== OVERALL SUMMARY ===
Total Estimated Time: 10-14 hours (1.5-2 days)
Overall Risk Level: MEDIUM
Critical Path: Phase 1 → Phase 2 → Phase 3 → Phase 4 → Phase 5

Major Risks & Mitigations:
1. SendGrid rate limits
   → Mitigation: Implement a queue with rate limiting

2. Performance with large datasets
   → Mitigation: Batch processing, proper indexing

3. Discount code conflicts
   → Mitigation: Unique code generation with validation

4. Email deliverability
   → Mitigation: Warm up IP, monitor bounce rates

Rollout Strategy:
1. Deploy to staging, test with a real data subset
2. Enable for 10% of users (feature flag)
3. Monitor metrics for 48 hours
4. Gradually increase to 100%

This Lyra-guided planning is significantly more detailed than standard planning. It thinks through risks, dependencies, and success criteria upfront.

Step 3: Work in Chunks

Here's where my workflow really shines. Instead of trying to implement everything at once, I work through the plan in manageable chunks. For each chunk, I use Claude Code in regular mode:

Chunk 1: Database Setup

claude "Implement Phase 1 of our Lyra plan. Inspect the carts table, add the abandoned_at column, and create the cart_reminder_logs table with proper indexes."

Claude uses the MySQL MCP server to:

• Check the current schema
• Generate migration scripts
• Validate the changes

What I love about this approach: Claude can actually see my database structure. It knows my naming conventions (we use snake_case), understands my foreign key relationships, and writes migrations that match my existing patterns.

Example migration Claude generates:

-- Migration: add_abandoned_cart_tracking
-- Generated: 2025-01-15

ALTER TABLE carts
ADD COLUMN abandoned_at TIMESTAMP NULL DEFAULT NULL,
ADD INDEX idx_abandoned_at (abandoned_at),
ADD INDEX idx_abandoned_carts (abandoned_at, status, user_id);

CREATE TABLE cart_reminder_logs (
    id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
    cart_id BIGINT UNSIGNED NOT NULL,
    user_id BIGINT UNSIGNED NOT NULL,
    sent_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
    email_opened BOOLEAN DEFAULT FALSE,
    clicked_through BOOLEAN DEFAULT FALSE,
    converted BOOLEAN DEFAULT FALSE,
    discount_code_used VARCHAR(50) NULL,

    FOREIGN KEY (cart_id) REFERENCES carts(id) ON DELETE CASCADE,
    FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE CASCADE,

    INDEX idx_cart_id (cart_id),
    INDEX idx_user_id (user_id),
    INDEX idx_sent_at (sent_at)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

Chunk 2: Service Implementation

claude "Now implement Phase 2. Create the AbandonedCartService following our existing service patterns in the /services directory."

Claude:

• Reads existing service files to understand patterns
• Implements the new service with consistent error handling
• Adds proper logging and monitoring hooks
• Follows our dependency injection pattern

Chunk 3: Email Integration

claude "Implement Phase 3. Create the email template and integrate with our existing SendGrid service."

Claude knows to:

• Use our existing EmailService wrapper
• Follow our email template structure
• Include tracking pixels for open/click metrics
• Add proper error handling for SendGrid failures

Chunk 4: Scheduled Job

claude "Add the cron job for Phase 4. Use our existing job scheduler pattern with node-cron."

Chunk 5: Testing

claude "Write comprehensive tests for the AbandonedCartService. Include unit tests and integration tests with mocked SendGrid responses."

Step 4: Code Review After Each Chunk

Here's where the code review command becomes invaluable. After each chunk, instead of manually reviewing, I run:

claude "/code-review Review the AbandonedCartService implementation. Check for security issues, performance problems, code style consistency, and edge cases."

The code review command checks:

• Security: SQL injection risks, input validation, authentication
• Performance: N+1 queries, unnecessary loops, missing indexes
• Code style: Consistency with existing patterns, naming conventions
• Error handling: Proper try-catch, meaningful error messages
• Edge cases: Null checks, empty arrays, boundary conditions
• Testing: Coverage gaps, missing test scenarios

Example review output:

Code Review: AbandonedCartService

=== SECURITY ===
✓ All database queries use parameterized statements
✓ User permissions checked before accessing cart data
✓ Email addresses validated before sending
⚠ WARNING: Consider rate limiting at the user level to prevent abuse

=== PERFORMANCE ===
✓ Proper indexes used in queries
✓ Batch processing implemented
⚠ ISSUE: Line 45 - N+1 query detected when fetching cart items
  Suggestion: Use eager loading with include: [CartItem]

=== CODE STYLE ===
✓ Follows existing service patterns
✓ Consistent naming conventions
✓ Proper async/await usage
✗ ERROR: Line 78 - Magic number '24' should be a named constant
  Suggestion: const ABANDONMENT_THRESHOLD_HOURS = 24;

=== ERROR HANDLING ===
✓ All async operations wrapped in try-catch
✓ Custom AppError used appropriately
⚠ SUGGESTION: Add specific error types for SendGrid failures
  (e.g., RateLimitError, InvalidEmailError)

=== EDGE CASES ===
✓ Handles empty carts
✓ Handles users without email
✗ MISSING: What if product images are deleted?
  Suggestion: Add fallback image handling

=== TESTING ===
✓ Unit tests for main methods
✗ MISSING: Integration test for the full email flow
✗ MISSING: Test case for concurrent cart updates

Overall Score: 7/10
Recommendation: Address critical issues before proceeding to the next phase.

This automated review catches issues I might miss and ensures consistent quality across all my code.

Step 5: Iterate Based on Review

After the code review, I address any issues:

claude "Fix the N+1 query issue on line 45 by implementing eager loading. Also, extract the magic number '24' into a named constant."

Or for more complex issues:

claude "Add comprehensive error handling for SendGrid failures. Create custom error classes for RateLimitError and InvalidEmailError, and implement retry logic with exponential backoff."

Then I rerun the code review to confirm the fixes:

claude "/code-review Re-review the AbandonedCartService after fixes"

Why This Workflow Works

1. Codebase Understanding First

Starting with /analyze-codebase means Claude writes code that actually fits your project. No more generic solutions that don't match your patterns.

2. Structured Planning with Lyra

Lyra ensures comprehensive planning with risk assessment, time estimates, and success criteria. No more "oops, forgot about that" moments.

3. Context Preservation

By having Claude read the Jira ticket first, all subsequent work maintains full Context. The business requirements from the marketing team, the technical constraints from comments, and the edge cases from linked tickets—everything stays in focus.

4. Database Awareness

The MySQL MCP server means Claude understands my schema. It writes queries that leverage existing indexes, respects foreign key constraints, and generates migrations that won't cause downtime. No more "oops, forgot about that relationship" moments.

5. Automated Code Review

The /code-review command provides consistent quality checks. It catches security issues, performance problems, and edge cases that are easy to miss during manual review.

6. Manageable Chunks

Working in phases prevents overwhelm and makes code review easier. Each chunk is small enough to:

• Test thoroughly in isolation
• Review in 15-20 minutes
• Deploy independently if needed
• Roll back without affecting other parts

7. Continuous Improvement Loop

Review → Fix → Re-review creates a quality feedback loop that catches issues before they hit production.

Real-World Results

Since adopting this workflow three months ago:

• Development time reduced by 40% on average for tickets
• Code review time cut in half thanks to automated first-pass reviews
• 90% fewer bugs in production because issues are caught during the review step
• Better code consistency as Claude learns and follows our patterns
• Easier onboarding for new team members who can follow the same pattern
• Higher code quality scores in SonarQube (went from B to an A rating)

A Real Example: Before vs. After

Before this workflow (traditional approach)

Ticket: "Add abandoned cart emails" → 2 days of development

• Missed requirement about GDPR unsubscribe (found in QA)
• Database migration caused 30-second downtime (forgot to add index concurrently)
• N+1 query issue discovered in production under load
• Had to refactor the email template three times to match marketing's vision
• Discount codes conflicted with the existing promo system (emergency hotfix)

Total time including fixes: 3 days

After this workflow

Ticket: "Add abandoned cart emails" → 1 day of development

• All requirements captured in the Lyra planning phase
• Migration tested in staging, zero downtime
• N+1 query caught by /code-review before commit
• Email template approved on first try (Claude generated mockup from requirements)
• Discount code validation is built in from the start

Total time: 1 day, zero hotfixes

Common Pitfalls to Avoid

1. Don't skip the codebase analysis. Yes, it takes 5 minutes upfront, but it saves hours of refactoring when Claude generates code that doesn't match your patterns.

2. Don't skip the planning phase. I know it's tempting to jump straight to coding, but trust me—the 10-15 minutes spent on Lyra planning saves hours of refactoring.

3. Don't ignore code review warnings. If /code-review flags something as a security issue or performance problem, address it before moving on. These compounds quickly.

4. Keep your MCP configurations updated. If your database credentials change and Claude can't connect, the whole workflow breaks down. Use environment variables and keep them up to date.

5. Review each chunk before moving on. Don't let Claude complete all phases without your review. You're still the expert—Claude is your intelligent assistant, not a replacement.

6. Be specific in your instructions. "Implement the feature" is vague. "Implement Phase 2 of our Lyra plan, following the AbandonedCartService pattern we discussed" is actionable.

7. Test as you go. After each chunk, run the tests. Don't accumulate untested code.

Pro Tips

1. Download custom commands for your team

# Create a setup script for your team
#!/bin/bash

# Essential commands
mkdir -p .claude/commands

curl -o .claude/commands/analyze-codebase.md \
  https://claudecodecommands.directory/api/download/analyze-codebase

curl -o .claude/commands/lyra.md \
  https://claudecodecommands.directory/api/download/lyra

curl -o .claude/commands/code-review.md \
  https://claudecodecommands.directory/api/download/code-review

echo "Claude commands installed! Use /analyze-codebase, /lyra, and /code-review"

2. Use descriptive chunk commands

# Vague (leads to generic code)
claude "Add the email functionality"

# Specific (gets you exactly what you need)
claude "Implement the email generation method in AbandonedCartService. Use our SendGrid wrapper, include cart items with product images from the product_images table, and follow the email template structure from /templates/transactional-email.hbs"

3. Reference existing patterns

claude "Follow the same error handling pattern we use in OrderProcessingService for external API calls"

4. Use code review iteratively

# After implementing a chunk
claude "/code-review Focus on security and performance issues"

# After fixes
claude "/code-review Verify that previous issues are resolved"

5. Combine commands for power moves

# Start fresh on unfamiliar code
claude "/analyze-codebase for the payment processing module"

# Then plan with full Context
claude "/lyra Create a plan to add Apple Pay support, considering our existing Stripe integration"

6. Ask for explanations when needed

claude "Explain the query optimization you used for fetching abandoned carts. Why did you choose that index strategy?"

7. Iterate on the plan if scope changes

claude "/lyra Update our plan to include push notifications for mobile app users in addition to emails"

Recommended starting tickets

• Add a new API endpoint with database changes
• Implement a scheduled job or background worker
• Refactor a service to add new functionality

Avoid for your first attempt

• Major architectural changes
• Features touching many systems
• Critical production hotfixes (stick to your proven process)

Advanced Tips: Custom Commands

Once you're comfortable with the workflow, you can explore more commands from the claude code commands directory. The directory has dozens of specialized commands for:

• Database optimization
• Security audits
• Performance profiling
• Documentation generation
• Test coverage analysis
• And much more

You can also create custom commands tailored to your team's needs. They're just Markdown files in .claude/commands/ with structured prompts.

Conclusion

This workflow has transformed how I approach development tasks. By combining:

• MCP servers (Jira + MySQL) for Context
• Custom commands (analyze-codebase, Lyra, code-review) for structure
• Chunked implementation for manageability

I've created a system that's both faster and more reliable than my previous process.

The key insight? Context + Structure + Review = Quality at Speed. When your AI coding assistant has full Context from your ticket system and database, follows a structured planning process, and gets consistent code reviews, it becomes an incredible force multiplier.

The plan-then-execute approach ensures you're always working thoughtfully, not just churning out code. Working in chunks makes the whole process less overwhelming and easier to review. Automated code reviews catch issues before they become problems.

Give it a try on your next Jira ticket. Start small, refine your process, and watch your productivity soar.

Resources

Resources mentioned in this post:

• Claude Code CLI Documentation
• Claude Code Commands Directory
• Model Context Protocol (MCP) Overview
• MCP Servers Repository

---

Want more development tool recommendations? Browse our AI developer tools category for the latest AI-powered solutions.