home / skills / tdhopper / dotfiles2.0 / creating-pull-requests

creating-pull-requests skill

/.claude/skills/creating-pull-requests

This skill helps you create well-structured pull requests with active-voice titles and concise, context-rich descriptions.

npx playbooks add skill tdhopper/dotfiles2.0 --skill creating-pull-requests

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

Files (1)
SKILL.md
3.8 KB
---
name: creating-pull-requests
description: Use this skill when creating pull requests, drafting PR descriptions, or running `gh pr create`. Ensures proper PR formatting with active-voice titles and structured descriptions explaining why, how, and context links.
---

# Creating Pull Requests

Create well-structured pull requests with clear titles and comprehensive descriptions.

# Critical Rules

**NEVER do these:**
- Do NOT add yourself as a coauthor on commits (no `Co-Authored-By` headers)
- Do NOT include phrases like "Generated with Claude Code" or "Created by Claude"
- Do NOT mention AI or Claude anywhere in commits or PR descriptions

# PR Title Format

Use **active voice** with a present-tense verb:

| Good | Bad |
|------|-----|
| Add user authentication | Added user authentication |
| Fix memory leak in cache | Fixing memory leak |
| Update dependencies to latest | Dependency updates |
| Remove deprecated API endpoints | Removed deprecated API |
| Refactor database connection pool | Database refactoring |

**Pattern**: `<Verb> <what> [to/in/for <context>]`

Common verbs: Add, Fix, Update, Remove, Refactor, Implement, Improve, Replace, Enable, Disable

# PR Description Structure

```markdown
## Why

[Explain the motivation for this change. What problem does it solve? What feature does it enable?]

## Approach

[Explain why this implementation was chosen over alternatives. What trade-offs were considered?]

## How it works

[Describe the technical implementation. How does the code achieve the goal?]

## Links

- [Ticket](url) or JIRA-123
- [Slack thread](url)
```

# Step-by-Step Process

## 1. Gather Context

Before creating the PR, understand what's being changed:

```bash
# See all commits on this branch vs main
git log main..HEAD --oneline

# See the full diff
git diff main...HEAD

# Check current branch name
git branch --show-current
```

## 2. Identify Links and References

Ask the user or search for:
- Jira/ticket numbers (look in commit messages or branch name)
- Related Slack conversations
- Fusion run URLs
- GCS paths for data or artifacts

## 3. Draft the PR

```bash
gh pr create --title "Add feature X to service Y" --body "$(cat <<'EOF'
## Why

[Motivation here]

## Approach

[Implementation rationale here]

## How it works

[Technical details here]

## Links

- [Ticket](url)
EOF
)"
```

# Example

**Branch**: `feature/add-retry-logic`
**Commits**: Adds exponential backoff retry to HTTP client

**Title**: `Add exponential backoff retry to HTTP client`

**Description**:
```markdown
## Why

HTTP requests to external services occasionally fail due to transient network issues. Without retry logic, these failures cascade to users as errors.

## Approach

Chose exponential backoff over fixed-interval retry to avoid thundering herd problems during partial outages. Used a max of 3 retries with jitter to spread out retry attempts.

## How it works

Wraps the existing HTTP client with a retry decorator. On 5xx responses or network errors, waits `2^attempt * 100ms + random(0-50ms)` before retrying. Logs each retry attempt for observability.

## Links

- [PROJ-1234](https://jira.example.com/browse/PROJ-1234)
- [Slack discussion](https://slack.com/archives/...)
```

# CLI Commands

```bash
# Create PR interactively
gh pr create

# Create with title and body
gh pr create --title "Add X" --body "Description here"

# Create as draft
gh pr create --draft --title "Add X" --body "..."

# Create with specific base branch
gh pr create --base develop --title "Add X" --body "..."

# Create and immediately open in browser
gh pr create --title "Add X" --body "..." --web
```

# Validation Checklist

Before creating the PR, verify:
- [ ] Title uses active voice with present-tense verb
- [ ] Description has Why, Approach, and How sections
- [ ] All relevant links are included
- [ ] No AI/Claude attribution anywhere
- [ ] No Co-Authored-By headers in commits

Overview

This skill helps you create well-structured pull requests for the dotfiles repo managed with yadm. It enforces active-voice, present-tense titles and produces PR descriptions that explain why the change was made, the chosen approach, and how the code works. It also checks for required links and disallowed attributions.

How this skill works

The skill inspects the branch commits and diffs, and prompts or assembles a PR title and description following a fixed template (Why, Approach, How it works, Links). It recommends or runs gh pr create with the composed title and body, and verifies the final PR meets validation checks (title voice, sections present, links included, no prohibited attributions).

When to use it

  • When opening any PR for the dotfiles repo
  • When drafting or editing PR descriptions
  • Before running gh pr create to ensure formatting and links are complete
  • When converting a work-in-progress to a draft or ready PR

Best practices

  • Use an active-voice, present-tense verb at the start of the title (e.g., Add, Fix, Update, Remove).
  • Follow the description template: Why, Approach, How it works, Links. Fill each section with concise, actionable detail.
  • Collect and include ticket numbers, Slack threads, run URLs, or artifact paths before creating the PR.
  • Avoid adding Co-Authored-By commit headers and do not include any AI or tool attributions in commits or PR text.
  • Keep the How it works section technical and focused on implementation details and trade-offs.

Example use cases

  • Branch feature/add-yadm-setup: Title 'Add yadm bootstrap for dotfiles' with Why/Approach/How/Links sections.
  • Fixing a broken installer script: Title 'Fix installer path handling' and include the failing scenario in Why and the chosen fix in How it works.
  • Updating dependencies: Title 'Update Homebrew formulae to latest' and explain testing approach in Approach.
  • Refactoring dotfile loading: Title 'Refactor dotfile initialization sequence' and document trade-offs and backward-compatibility in Approach.

FAQ

What exact title format should I use?

Start with a present-tense verb then the object, optionally adding context: 'Verb what [to/in/for context]'. Examples: 'Add user authentication' or 'Refactor database connection pool'.

What must I never include in commits or PR descriptions?

Do not add Co-Authored-By headers and do not include any AI or tool attributions or generated-by phrases anywhere in commits or the PR description.

Which links should I include in Links section?

Include relevant ticket or JIRA IDs, Slack discussions, CI or run URLs, and any artifact storage paths (GCS, Fusion run, etc.).

How do I create the PR from the CLI?

Use gh pr create interactively or supply --title and --body. For drafts use --draft and for specific base branches use --base. The skill can compose the body for you to pass to gh pr create.