home / skills / fcakyon / claude-codex-settings / pr-workflow

This skill automates and guides the PR workflow from branch setup to creating a well-documented pull request.

npx playbooks add skill fcakyon/claude-codex-settings --skill pr-workflow

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
2.6 KB
---
name: pr-workflow
description: This skill should be used when user asks to "create a PR", "make a pull request", "open PR for this branch", "submit changes as PR", "push and create PR", or runs /create-pr or /pr-creator commands.
---

# Pull Request Workflow

Complete workflow for creating pull requests following project standards.

## Process

1. **Verify staged changes** exist with `git diff --cached --name-only`

2. **Branch setup**
   - If on main/master, create feature branch first: `feature/brief-description` or `fix/brief-description`
   - Use `github-dev:commit-creator` subagent to handle staged changes if needed

3. **Documentation check**
   - Update README.md or docs based on changes compared to target branch
   - For config/API changes, use `mcp__tavily__tavily_search` to verify info and include sources

4. **Analyze all commits**
   - Use `git diff <base-branch>...HEAD` to review complete changeset
   - PR message must describe all commits, not just latest
   - Focus on what changed from reviewer perspective

5. **Create PR**
   - Use `/pr-creator` agent or `gh pr create` with parameters:
     - `-t` (title): Start with capital letter, use verb, NO "fix:" or "feat:" prefix
     - `-b` (body): Brief summary + bullet points with inline markdown links
     - `-a @me` (self-assign)
     - `-r <reviewer>`: Find via `gh pr list --repo <owner>/<repo> --author @me --limit 5`

6. **PR Body Guidelines**
   - **Summary**: Few words or 1 sentence describing changes
   - **Changes**: Bullet points with inline links `[src/auth.py:42](src/auth.py#L42)`
   - **Examples**: For significant changes, include before/after code examples
   - **No test plans**: Never mention test procedures in PR

## Examples

### With inline source links:

```
Update Claude Haiku to version 4.5

- Model ID: claude-3-haiku-20240307 → claude-haiku-4-5-20251001 ([source](https://docs.anthropic.com/en/docs/about-claude/models/overview))
- Pricing: $0.80/$4.00 → $1.00/$5.00 per MTok ([source](https://docs.anthropic.com/en/docs/about-claude/pricing))
- Max output: 4,096 → 64,000 tokens ([source](https://docs.anthropic.com/en/docs/about-claude/models/overview))
```

### With code changes:

```
Refactor authentication to use async context manager

- Replace synchronous auth flow with async/await pattern in [src/auth.py:15-42](src/auth.py#L15-L42)
- Add context manager support for automatic cleanup

Before:
\`\`\`python
def authenticate(token):
    session = create_session(token)
    return session
\`\`\`

After:
\`\`\`python
async def authenticate(token):
    async with create_session(token) as session:
        return session
\`\`\`
```

Overview

This skill automates and enforces a consistent pull request workflow for my personal Claude Code and OpenAI Codex setup. It guides branch creation, commit analysis, documentation updates, and PR creation using /pr-creator or gh commands to produce reviewer-friendly PRs. The skill focuses on clear titles, comprehensive PR bodies, and inline source links for fast review.

How this skill works

It inspects staged and local changes, ensures you are on a feature branch (creates one if needed), and analyzes the complete diff against the target base branch. It helps update docs, formats a multi-commit PR body with inline file/line links and examples, and runs the selected PR creation command (/pr-creator or gh pr create) with standard flags (title, body, assignee, reviewers).

When to use it

  • When you want to open a new pull request from your current branch or staged changes
  • After finishing a set of commits that need a consolidated PR message covering all commits
  • When you need to ensure documentation or README updates accompany code changes
  • When you want consistent PR titles and bodies with inline source links and examples
  • When you prefer automating reviewer selection or self-assignment via CLI or agent commands

Best practices

  • Confirm staged changes with git diff --cached --name-only before creating a PR
  • If on main/master, create a feature branch named feature/brief-description or fix/brief-description
  • Describe the full changeset using git diff <base>...HEAD, not just the last commit
  • Start PR titles with a capitalized verb and avoid prefixes like fix: or feat:
  • Use bullets with inline source links and include before/after examples for significant refactors
  • Assign yourself and add reviewers via gh pr list to find likely reviewers

Example use cases

  • Push local commits and create a PR that summarizes several commits and links to changed lines
  • Refactor authentication to async with a before/after code example in the PR body
  • Update API or config and include docs/README changes plus external sources for verification
  • Run /pr-creator to auto-generate a title, body, and self-assign the PR using project conventions
  • Use gh pr create with -t and -b flags prefilled by the skill for quick CLI-driven PRs

FAQ

Should PR titles include conventional prefixes like fix: or feat:?

No. Use a concise title starting with a capitalized verb and omit conventional prefixes.

Do I include test plans in the PR body?

No. The workflow intentionally avoids mentioning test procedures in PR descriptions.

How do I reference specific lines in files?

Include inline links formatted like [src/file.py:42](src/file.py#L42) to point reviewers to exact locations.