Jira To Github

JIRA-to-GitHub Workflow Orchestrator

Purpose

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

Usage

/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:

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:

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

/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

/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

/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

# 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