Rails cto pull request

Pull Request

Create a pull request from the current branch into staging using the gh CLI. The PR should be easy to understand for anyone — technical or not.

Workflow

1. Preflight checks

Check the current branch:

git branch --show-current

If the current branch is staging, stop and tell the user: "You're on the staging branch — this skill creates PRs that target staging from a feature branch. Switch to your working branch first."

Check for an existing PR:

gh pr list --head "$(git branch --show-current)" --base staging --state open

If a PR already exists for this branch targeting staging, warn the user with the existing PR link and stop. Do not create a duplicate.

2. Commit outstanding changes

If there are any uncommitted or unstaged changes, commit them first using the rails-cto-commit skill before continuing. This ensures everything is captured in the PR.

3. Sync with staging

Pull the latest changes from staging into the current branch to ensure there are no merge conflicts before creating the PR. This saves the integration manager from dealing with conflicts during review.

git fetch origin staging
git merge origin/staging

If there are merge conflicts:

1. List the conflicting files and show the conflicts to the user
2. Resolve each conflict — prefer the feature branch's changes where they are intentional, and keep staging's changes where they are unrelated updates
3. After resolving, stage the files and commit the merge
4. If the conflicts are complex or ambiguous, ask the user how to resolve them before proceeding

If the merge is clean (no conflicts), continue to the next step.

4. Push to remote

Push the branch to the remote repository. If the branch has no upstream, set one:

git push -u origin "$(git branch --show-current)"

If it already tracks a remote, a simple git push is fine.

5. Gather the changes

Review what this branch has changed relative to staging:

git log staging..HEAD --oneline
git diff staging...HEAD --stat

Read the commit messages and the actual diffs to understand what changed and why.

6. Write the PR title

Write a short, plain-language title (under 72 characters) that describes what this branch accomplishes. Same rules as commit messages — no jargon, no technical shorthand, readable by anyone.

Good examples:

• Add password reset flow for logged-out users
• Fix checkout button not working on mobile
• Update pricing page with annual discount

7. Write the PR description

Write the description in plain language. Organize changes into two sections so readers can quickly tell what's significant and what's minor.

Do NOT include co-authorship lines or reference "Claude" or any AI tool anywhere.

Use this structure:

## Summary

A 1-2 sentence overview of what this branch does and why.

## Major Changes

- Describe significant changes here — new features, important fixes, behavior changes
- Each bullet should explain what changed from a user or product perspective
- Include enough context that someone unfamiliar with the code understands the impact

## Minor Changes

- Small tweaks, formatting fixes, config updates, copy changes
- Things that are good to know about but don't need close review

If there are only major changes, omit the "Minor Changes" section. If everything is minor, omit "Major Changes." Use your judgment — the point is to help the reader focus their attention.

8. Create the PR

gh pr create --base staging --title "the pr title" --body "$(cat <<'EOF'
## Summary
...

## Major Changes
...

## Minor Changes
...
EOF
)"

After creation, show the user the PR URL so they can view it.