# Jira To Github

> JIRA-to-GitHub Workflow Orchestrator

- Skill: `valasubramanian-kr/jira-to-github` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add valasubramanian-kr/jira-to-github`
- Raw SKILL.md: https://api.skillmd.com/api/skills/valasubramanian-kr/jira-to-github/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: valasubramanian-kr (https://skillmd.com/u/valasubramanian-kr)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/valasubramanian-kr/jira-to-github

---


# JIRA-to-GitHub Workflow Orchestrator

## Purpose

Execute the complete JIRA-to-GitHub workflow with confirmation gates at each stage.

## Usage

```bash
/jira-to-github DRT-17270
```

## What This Skill Does

Orchestrates all 9 core workflow stages sequentially with user confirmation between stages:

1. **Analyze JIRA** → Fetch issue and Confluence docs
2. **Explore Context** → Gather external docs, codebase patterns, human input
3. **Plan Implementation** → Design approach with architectural choices
4. **Review Plan** → Human feedback loop for plan approval/revision
5. **Create Dev Branch** → Create `dcppay-*` branch
6. **Code Feature** → Implement changes
7. **Write Tests** → Create unit tests for implemented code
8. **Validate Changes** → Run tests, linting, type checking
9. **Push to GitHub** → Create pull request

## Instructions

You are orchestrating the complete JIRA-to-GitHub development workflow. This is a multi-stage process with confirmation gates to ensure quality and alignment.

### Overview

This workflow automates the entire development cycle from JIRA ticket to GitHub pull request. At each stage, you'll see a summary and can approve or reject before proceeding.

**Stages**:
1. 📋 Analyze JIRA Issue
2. 🔍 Explore Context
3. 📝 Plan Implementation
4. 👀 Review Plan
5. 🌿 Create Dev Branch
6. 💻 Code Feature
7. 🧪 Write Tests
8. ✅ Validate Changes
9. 🚀 Push to GitHub

### Step 1: Extract JIRA Key

Extract the JIRA key from the argument:
- Format: `DRT-12345`, `TEAM-123`, etc.
- Validate format (letters-numbers)

### Step 2: Create Workflow Directory

Create the workflow state directory:

```bash
JIRA_KEY="<extracted-key>"
mkdir -p workflow/jira-to-github/$JIRA_KEY
```

### Step 3: Stage 1 - Analyze JIRA Issue

**Action**: Invoke `/pull <JIRA-KEY>`

This stage:
- Detects the target repo from `git remote` and writes `target-repo.md`
- Fetches JIRA issue details
- Retrieves Confluence documentation
- Downloads attachments (screenshots, PDFs, documents) to `attachments/` directory
- Saves analysis to `current-issue.md`

**Display Summary**:
```
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Stage 1/9: 📋 Analyze JIRA Issue
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Issue: <JIRA-KEY> - <Summary>
Type: <Issue Type>
Priority: <Priority>
Target Repo: <repo-name> (<detected-via>)

Confluence Docs: <count> pages retrieved
Figma Links: <count> designs found
Attachments: <count> downloaded

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
```

**Confirmation Gate**:
```
Proceed to context exploration? (Y/n)
```

If user says **No**: Stop workflow and display exit message.
If user says **Yes**: Continue to Stage 2.

### Step 4: Stage 2 - Explore Context

**Action**: Invoke `/explore`

This stage:
- Launches 3-4 parallel exploration agents:
  - Agent 1: Fetches external documentation (Figma, Confluence)
  - Agent 2: Searches codebase for reference implementations
  - Agent 3: Analyzes attachments (screenshots, PDFs) if present
- Asks clarification questions (human-in-the-loop)
- Requests additional context from user
- Consolidates findings into exploration-summary.md

**Display Summary**:
```
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Stage 2/9: 🔍 Explore Context
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

External Context:
- Figma: <count> components analyzed
- Confluence: <count> pages retrieved

Codebase Patterns:
- Reference implementations: <count>
- Reusable utilities: <count>

Attachments Analysis:
- Screenshots analyzed: <count>
- Documents reviewed: <count>

Human Input:
- Clarifications gathered: <count> questions answered
- Additional context: <screenshots/docs/examples>

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
```

**Auto-proceed**: Automatically continue to Stage 3 (Plan Implementation).

### Step 5: Stage 3 - Plan Implementation

**Action**: Invoke `/plan`

This stage:
- Loads exploration context and issue details
- Designs 2-3 architectural approaches with trade-offs
- **Presents architectural choices** (human-in-the-loop)
- User selects preferred approach
- Creates implementation plan with chosen approach
- Saves to `implementation-plan.md`

**Display Summary**:
```
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Stage 3/9: 📝 Plan Implementation
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Architectural Approach Selected: <approach name>

Technical Approach:
<1-sentence summary>

Files to modify: <count>
New files to create: <count>
Tests to add: <count>

Architectural Options Considered:
- Option 1: <name> - <brief description>
- Option 2: <name> - <brief description>

Risks:
- <risk 1>
- <risk 2>

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
```

**Auto-proceed**: Automatically continue to Stage 4 (Plan Review) for human feedback.

### Step 6: Stage 4 - Review Plan

**Action**: Invoke `/review`

This stage:
- Presents the implementation plan for human review
- Accepts review comments or questions as input
- Allows plan revisions based on feedback
- Creates audit trail of all review sessions
- Saves review log to `review-log.md`

**Display Summary**:
```
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Stage 4/9: 👀 Review Plan
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

How would you like to proceed with the implementation plan?

Options:
1. Provide review comments (suggestions or changes)
2. Ask questions (need clarification)
3. Approve and continue (plan looks good)

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
```

**Review Process**:
- If user provides **review comments**: Plan is revised and re-presented for review
- If user asks **questions**: Questions are answered and user can approve or request changes
- If user **approves**: Workflow proceeds to Stage 5

**Multiple Review Cycles**:
- Review can iterate multiple times until approval
- All feedback, questions, and revisions are logged
- User maintains full control over plan acceptance

**Confirmation Gate**:
After approval, display:
```
Plan approved! Proceed to branch creation? (Y/n)
```

If user says **No**: Stop workflow.
If user says **Yes**: Continue to Stage 5.

### Step 7: Stage 5 - Create Dev Branch

**Action**: Invoke `/branch`

This stage:
- Extracts JIRA number
- Generates branch name: `dcppay-<number>-<short-title>`
- Creates branch from main
- Saves to `dev-branch.md`

**Display Summary**:
```
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Stage 5/9: 🌿 Create Dev Branch
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Branch: dcppay-<number>-<short-title>
Base: main
Status: Created ✓

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
```

**Auto-proceed**: No confirmation needed (branch creation is non-destructive).

### Step 8: Stage 6 - Code Feature

**Action**: Invoke `/code`

This stage:
- Reads implementation plan
- Applies team-specific patterns
- Creates new files
- Modifies existing files
- Saves to `implementation-log.md`

**Display Summary**:
```
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Stage 6/9: 💻 Code Feature
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Files created: <count>
Files modified: <count>
Lines changed: <count>

Changes:
1. <file1> - <description>
2. <file2> - <description>

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
```

**Auto-proceed**: No confirmation needed (tests will be written in next stage).

### Step 9: Stage 7 - Write Tests

**Action**: Invoke `/test`

This stage:
- Reads implementation plan and log
- Analyzes existing test patterns
- Creates comprehensive unit test files
- Follows project testing conventions
- Saves to `unit-tests.md`

**Display Summary**:
```
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Stage 7/9: 🧪 Write Tests
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Test files created: <count>
Tests written: <count>
Expected coverage: <percentage>%

Testing Patterns:
- React Testing Library
- Jest mocks
- Custom hooks testing

Test Files:
1. <file1.spec.ts> - <count> tests
2. <file2.spec.tsx> - <count> tests

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
```

**Auto-proceed**: No confirmation needed (validation will run in next stage).

### Step 10: Stage 8 - Validate Changes

**Action**: Invoke `/validate`

This stage:
- Runs linting
- Runs type checking
- Runs unit tests
- Runs integration tests
- Generates coverage report
- Saves to `validation-results.md`

**Display Summary**:
```
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Stage 8/9: ✅ Validate Changes
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Linting: ✓ Passed
Type Check: ✓ Passed
Unit Tests: ✓ <count> passed
Integration Tests: ✓ <count> passed
Coverage: <percentage>%

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
```

**If tests fail**:
```
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Stage 8/9: ❌ Validate Changes FAILED
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Linting: ✓ Passed
Type Check: ❌ Failed (<count> errors)
Unit Tests: ❌ <count> failed

Failed Tests:
- <test-name> - <error>

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Workflow paused. Fix errors and run /validate manually.
Once validation passes, run /push to continue.
```

**Confirmation Gate** (if tests passed):
```
All tests passed! Create pull request? (Y/n)
```

If user says **No**: Stop workflow (changes remain on branch).
If user says **Yes**: Continue to Stage 9.

### Step 11: Stage 9 - Push to GitHub

**Action**: Invoke `/push`

This stage:
- Commits changes with conventional message
- Pushes to GitHub
- Creates pull request
- Adds reviewers and labels
- Saves to `pr-details.md`

**Display Summary**:
```
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Stage 9/9: 🚀 Push to GitHub
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

✓ Pull Request Created

PR #<number>: [<JIRA-KEY>] <summary>
URL: <GitHub-URL>

Branch: <branch-name>
Reviewers: @<reviewer1>, @<reviewer2>
Labels: <labels>

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
```

### Step 12: Workflow Complete

Display final summary:

```
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
✨ Workflow Complete!
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

JIRA Issue: <JIRA-KEY> - <summary>
GitHub PR: #<number> - <URL>

Workflow Summary:
✓ Issue analyzed
✓ Context explored (external docs, codebase patterns, human input)
✓ Plan created (architectural approach selected)
✓ Plan reviewed and approved
✓ Branch created: <branch-name>
✓ Code implemented (<count> files)
✓ Unit tests written (<count> tests)
✓ Validation passed (<count> tests, <coverage>% coverage)
✓ PR created

Next Steps:
1. Monitor PR for CI/CD checks
2. Wait for code review feedback from reviewers
3. Run /resolve-review-comments to address review comments (when received)
4. Merge when approved
5. Optional: Run /update-jira to update JIRA

Workflow artifacts saved to:
workflow/jira-to-github/<JIRA-KEY>/

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
```

## Error Handling

### Error Recovery Strategies

If any stage fails:

1. **Log Error**:
```bash
echo "<error>" >> workflow/jira-to-github/<JIRA-KEY>/errors.log
```

2. **Display Error Context**:
```
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
❌ Workflow Failed at Stage <N>
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Stage: <stage-name>
Error: <error-message>

Recovery Options:
1. Fix the issue manually
2. Re-run the failed skill: /<skill-name>
3. Continue from this stage once fixed
4. Start over: /jira-to-github <JIRA-KEY>

Workflow state preserved in:
workflow/jira-to-github/<JIRA-KEY>/

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
```

3. **Preserve State**: All completed stages are saved, workflow can resume.

### Common Error Scenarios

**Stage 1 - Analyze JIRA**:
- JIRA not found → Verify JIRA key
- Confluence error → Continue without Confluence docs
- Network error → Retry after checking connectivity

**Stage 2 - Plan Implementation**:
- User cancels → Exit gracefully
- Figma error → Continue without Figma

**Stage 3 - Create Dev Branch**:
- Branch exists → Offer to checkout or rename
- Not on main → Checkout main first
- Uncommitted changes → Stash or commit

**Stage 5 - Code Feature**:
- File not found → Verify paths in plan
- Syntax errors → Fix and retry
- Permission errors → Check file permissions

**Stage 6 - Write Tests**:
- Implementation not found → Run /code first
- Test patterns unclear → Use project defaults
- Missing test utilities → Install required packages

**Stage 7 - Validate Changes**:
- Tests fail → **STOP**, fix tests, resume manually
- Linting errors → Auto-fix if possible
- Coverage too low → Add more tests

**Stage 8 - Push to GitHub**:
- Auth error → Check GitHub credentials
- Network error → Retry push
- PR already exists → Link to existing PR

## User Control

Users can control the workflow at multiple points:

**Pause/Cancel**:
- Press Ctrl+C to cancel at any time
- State is preserved, can resume later

**Skip Stages**:
- Cannot skip stages (sequential dependency)
- Can run individual skills manually instead

**Modify During Workflow**:
- At confirmation gates, can choose to revise
- Can manually edit files between stages
- Can re-run individual stages

**Resume After Failure**:
- Run individual skill that failed
- Or restart entire workflow with same JIRA key

## Progress Tracking

Workflow state tracked in:
```
workflow/jira-to-github/<JIRA-KEY>/
├── current-issue.md          ✓ Stage 1 complete
├── attachments/              ✓ Stage 1 (JIRA attachments)
├── exploration-summary.md    ✓ Stage 2 complete
├── implementation-plan.md    ✓ Stage 3 complete
├── review-log.md             ✓ Stage 4 complete
├── dev-branch.md             ✓ Stage 5 complete
├── implementation-log.md     ✓ Stage 6 complete
├── unit-tests.md             ✓ Stage 7 complete
├── validation-results.md     ✓ Stage 8 complete
└── pr-details.md             ✓ Stage 9 complete
```

## Examples

Example 1: Successful full workflow
```bash
/jira-to-github DRT-17270

# Stage 1: Analyzes issue → User confirms
# Stage 2: Explores context → Asks clarification questions, gathers external docs
# Stage 3: Plans implementation → Presents architectural choices → User selects
# Stage 4: Reviews plan → User approves
# Stage 5: Creates dcppay-17270-eprotect-error-code branch
# Stage 6: Implements code
# Stage 7: Writes unit tests
# Stage 8: Runs validation → All pass → User confirms
# Stage 9: Creates PR #123
# ✓ Complete!
```

Example 2: User provides review feedback and revises plan
```bash
/jira-to-github DRT-17270

# Stage 1: Analyzes issue → User confirms
# Stage 2: Explores context → Gathers comprehensive findings
# Stage 3: Plans implementation → User selects architectural approach
# Stage 4: Reviews plan → User requests changes
# Plan revised based on feedback
# Stage 4: Reviews updated plan → User approves
# Stages 5-9 complete
# ✓ Complete!
```

Example 3: Validation fails, manual fix, resume
```bash
/jira-to-github DRT-17270

# Stages 1-7 complete
# Stage 8: Validation fails ❌
# User fixes tests manually
# Run /validate → Pass ✓
# Run /push → PR created
```

Example 4: Run individual stages
```bash
# Instead of full workflow, run each stage manually:
/pull DRT-17270
# Review output, then:
/explore
# Answer clarification questions, provide additional context, then:
/plan
# Select architectural approach, then:
/review
# Review and approve, then:
/branch
/code
/test
/validate
/push
```