Push

Push to GitHub Skill

Purpose

Commit changes, push to GitHub, and create a pull request linked to the JIRA issue.

Usage

/push

(Must be run after /validate with all tests passing)

What This Skill Does

1. Verify Tests Pass: Confirms validation-results.md shows passing tests
2. Verify Branch: Ensures on correct dcppay-* branch
3. Stage Changes: Adds all modified files to git
4. Create Commit: Generates conventional commit message
5. Push to GitHub: Pushes branch using GitHub MCP
6. Create Pull Request: Auto-populates PR with JIRA link and details
7. Save PR Details: Outputs PR URL to pr-details.md

Validation Results Context

The validation results should be located in the most recent directory under workflow/jira-to-github/*/validation-results.md. You will need to find and read this file in Step 2.

Current Issue Context

The JIRA issue details should be located in the most recent directory under workflow/jira-to-github/*/current-issue.md. You will need to find and read this file in Step 1.

Development Branch Context

The development branch details should be located in the most recent directory under workflow/jira-to-github/*/dev-branch.md. You will need to find and read this file in Step 1.

Instructions

You are pushing changes to GitHub and creating a pull request. Follow these steps:

CRITICAL: Your ONLY job is to:

1. Verify code and validation results
2. Stage and commit changes
3. Push the changes to only development branch in specific project repo
4. Create a PR following the standards

DO NOT:

• Push code to other branches
• Delete any branches
• Delete any PR

Step 1: Validate Prerequisites

Verify that:

1. Currently on the correct dcppay-* branch
2. Changes have been made to the codebase
3. Validation has been run

# Check current branch
CURRENT_BRANCH=$(git rev-parse --abbrev-ref HEAD)

# Verify branch matches expected pattern
if [[ ! $CURRENT_BRANCH =~ ^dcppay-[0-9]+-.*$ ]]; then
  echo "❌ Not on a dcppay development branch"
  exit 1
fi

# Check for changes
if [ -z "$(git status --porcelain)" ]; then
  echo "❌ No changes to commit"
  exit 1
fi

# Verify validation results exist
JIRA_DIR=$(ls -td workflow/jira-to-github/*/ 2>/dev/null | head -1)
if [ ! -f "$JIRA_DIR/validation-results.md" ]; then
  echo "❌ No validation results found. Run /validate first."
  exit 1
fi

Step 2: Verify Validation Passed

Verify that:

1. Validation results exist and all tests passed

Read validation-results.md and verify:

• All tests passed ✓
• No critical issues
• Linting passed
• Type checking passed

If validation failed, STOP:

❌ Cannot create PR - validation failed

Fix failing tests first, then run /validate again.

Step 3: Review Changes

Show what will be committed:

# Show changed files
git status

# Show diff summary
git diff --stat

Step 4: Stage Changes

Ask the user what they want to commit and push:

Use AskUserQuestion tool:

Question: "What would you like to commit and push?"
Options:
1. "All modified files (staged + unstaged)" - Stage all changes with git add .
2. "Only staged files" - Use files already staged by user
3. "Skip staging (already committed)" - Skip to push step

Then based on the answer:

Option 1: All modified files

# Stage all changes
git add .

# Verify staged files
git status

Option 2: Only staged files

# Show what's already staged
git diff --cached --stat

# Verify staged files exist
if [ -z "$(git diff --cached --name-only)" ]; then
  echo "❌ No files are staged. Stage files first with: git add <files>"
  exit 1
fi

Option 3: Skip staging (already committed)

# Verify there are commits to push
if [ -z "$(git log origin/$CURRENT_BRANCH..$CURRENT_BRANCH 2>/dev/null)" ]; then
  echo "❌ No commits to push"
  exit 1
fi

# Show commits that will be pushed
git log origin/$CURRENT_BRANCH..$CURRENT_BRANCH --oneline

# Skip to Step 7 (Push to GitHub)

Exclude from staging:

• .env files
• node_modules/
• Build artifacts (dist/, build/)
• Personal IDE configs (.vscode/, .idea/)
• Test coverage reports

Step 5: Generate Commit Message

Create a conventional commit message:

Format:

<type>: <subject>

<body>

Refs: <JIRA-KEY>

Types:

• feat: New feature
• fix: Bug fix
• refactor: Code refactoring
• test: Adding tests
• docs: Documentation
• style: Code style changes
• perf: Performance improvements
• chore: Maintenance tasks

Example messages:

feat: add eProtect error code handling

- Implement error code mapping for eProtect responses
- Add user-friendly error messages
- Update analytics events for error tracking

Refs: DRT-17270

fix: resolve card deletion bug

- Fix issue where cards weren't removed from Zustand store
- Sync card state across wallet, flyout, and checkout
- Add unit tests for card deletion

Refs: DRT-17345

feat: implement checkout intent orchestration

- Add new controller endpoint for checkout intent
- Implement module business logic
- Add domain models for checkout
- Integrate with upstream payment service

Refs: DRT-17410

Step 6: Create Commit

Commit the staged changes:

# Create commit with message
git commit -m "<commit message>"

# Verify commit created
git log -1 --oneline

Step 7: Push to GitHub

Push the branch to GitHub:

Option A: Using GitHub MCP

Use mcp__github__createCommit or mcp__github__push tools

Option B: Using git command

# Push to origin
git push -u origin $CURRENT_BRANCH

# Verify push successful
git log origin/$CURRENT_BRANCH -1 --oneline

Step 8: Load PR Template from Repo Profile

Load the repo-specific PR template:

1. Read workflow/jira-to-github/*/target-repo.md to get the profile path
2. Read the repo profile (e.g., context/repos/esperanto.md)
3. Extract the PR Template section — use it for the PR title format and body structure
4. If target-repo.md or the profile is not found, fall back to the default template below

Handle Labels from profile:

Read the ### Labels subsection within the PR Template:

• If it contains (select) marker (e.g., ### Labels (select)):
  • Parse the label options (each line: - <label> — <description>)
  • Use AskUserQuestion with multiSelect: true to let the user choose labels
  • The user can select multiple labels AND use the built-in "Other" option to type custom labels
  • Apply the selected labels when creating the PR (via --label flag)
• If it's a plain list without (select) marker:
  • Apply all listed labels automatically
• If the Labels section is empty or absent:
  • Skip labels

Step 9: Create Pull Request

Create PR using GitHub MCP or gh CLI.

PR Title: Use the title format from the repo profile's PR Template section.

Default fallback (if no profile found):

[Payments] | <JIRA-KEY> | <Issue summary>

PR Body: Use the body structure from the repo profile's PR Template section, populating it with data from current-issue.md, implementation-log.md, and validation-results.md.

Default fallback (if no profile found):

## Summary

<Brief description of changes from JIRA issue>

## JIRA Issue

[<JIRA-KEY>](<JIRA-URL>)

**Issue Type**: <Story/Bug/Task>
**Priority**: <Priority>

## Changes Made

<Summary from implementation-log.md>

### Files Changed
- `path/to/file1.ts` - <description>
- `path/to/file2.tsx` - <description>

## Test Plan

<From validation-results.md>

### Automated Tests
- ✓ Linting passed
- ✓ Type checking passed
- ✓ Unit tests: <count> passed
- ✓ Coverage: <percentage>%

Create PR using GitHub MCP:

mcp__github__createPullRequest with title and body above

Or using gh CLI:

gh pr create \
  --title "<title from repo profile PR template>" \
  --body "<description>" \
  --base main \
  --head $CURRENT_BRANCH

<!-- ### Step 10: Add Labels Add appropriate labels: **Type labels**: - `feature` - New features - `bug` - Bug fixes - `refactor` - Code refactoring - `test` - Test improvements **App labels**: **Priority labels**: - `priority:high` - High priority - `priority:medium` - Medium priority - `priority:low` - Low priority **Add labels**: ```bash gh pr edit --add-label feature,priority:high ``` -->

Step 11: Save PR Details

Create a PR details document:

# Pull Request: <JIRA-KEY>

## PR Information

- **PR Number**: #<number>
- **PR URL**: <GitHub-URL>
- **Title**: [Payments] | <JIRA-KEY> | <Issue summary>
- **Status**: Open
- **Branch**: `<branch-name>`
- **Base**: `main`

## JIRA Issue

- **Issue**: <JIRA-KEY>
- **URL**: <JIRA-URL>
- **Summary**: <summary>

## Labels

- <label1>
- <label2>

## Test Results

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

## Timeline

- **Branch Created**: <timestamp>
- **Code Completed**: <timestamp>
- **Tests Passed**: <timestamp>
- **PR Created**: <timestamp>

## Next Steps

1. Wait for CI/CD checks to complete
2. Address reviewer feedback
3. Merge when approved
4. Run `/update-jira` to update JIRA

---
*PR created: <timestamp>*

Save to:

workflow/jira-to-github/<JIRA-NUMBER>/pr-details.md

Step 12: Display Summary

Display a concise summary to the user:

✓ Pull Request Created

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

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

JIRA Issue: <JIRA-KEY>
URL: <JIRA-URL>

PR details saved to: workflow/jira-to-github/<JIRA-NUMBER>/pr-details.md

Next steps:
1. Wait for code review feedback from reviewers
2. Run /resolve-review-comments to address review comments (when received)
3. (Optional) Run /update-jira to update JIRA issue status

Error Handling

If errors occur:

1. Log error to workflow/jira-to-github/<JIRA-NUMBER>/errors.log
2. Display user-friendly message
3. Suggest recovery action

Common errors:

• Validation failed: Cannot create PR with failing tests. Run /validate and fix issues first.
• No changes to commit: Nothing to push. Verify changes were made.
• Branch already pushed: PR may already exist. Check GitHub.
• GitHub auth failure: Check GITHUB_PAT environment variable or GitHub MCP configuration
• Network errors: Retry push after checking connectivity
• Merge conflicts: Resolve conflicts with main branch before pushing
• PR template not found: Use default template or manual PR creation

Security Checklist

Before pushing, verify:

• No .env files committed
• No API keys or secrets in code
• No PII (Personally Identifiable Information)
• No full credit card numbers (test data should use 4111111111111111)
• No passwords or tokens
• eProtect tokenization used for card data
• Sensitive logs removed

If secrets detected, STOP:

❌ Security Issue Detected

Secrets or sensitive data found in changes.
Do NOT push to GitHub.

Remove sensitive data, then try again.

Examples

Example 1: Standard feature PR

/push
# → Commits changes
# → Pushes to dcppay-17270-eprotect-error-code
# → Creates PR #123
# → Adds reviewers and labels

Example 2: Bug fix PR

/push
# → Commits with "fix(wallet): resolve card deletion bug"
# → Creates PR with bug fix template
# → Adds high priority label

Example 3: Validation failed

/push
# → ❌ Cannot create PR - validation failed
# → Run /validate and fix issues first