pull-request

Files (1)

• SKILL.md

SKILL.md (first lines)

## Definitions

PR=Pull Request

## Access

Access Github if the capability is available and the user instructs it.
* skills
  * /github-app skill: push with `${CLAUDE_SKILL_DIR}/../github-app/scripts/gh-app.sh git push`, then create the PR with `${CLAUDE_SKILL_DIR}/../github-app/scripts/gh-app.sh pr create`
  * /github-actions-ci: check on CI with its bundled helper
* Github API or MCP
* github CLI 

## Branching

Update the default branch to the latest from the origin.
If you were already on the default branch, branch from there.
Otherwise, check if the current branch has been merged into the updated default (could be a squash merge).
If it has been merged, then branch off the updated default (move your changes there).
Otherwise, branch off of the current branch. First ensure the updated default is merged into it.

If you are working on a sub issue of a parent issue, then look for an active parent branch to use as the base.
All sub issues that do not have dependencies should use the discovered default branch or the parent branch as their base branch.

If the issue requires an existing PR to be merged, then the base branch will be the branch for that PR.
Create it as a [Stacked PR](https://github.github.com/gh-stack/introduction/overview/).

## Description

For the PR description, use the `/document-changes` skill.
If the PR resolves an issue, ensure it is auto-closed by using the "Resolves" keyword: "Resolves #10".

When you write a commit message, follow these 7 rules:
Rule 1: Separate the subject line from the body with a single blank line.
Rule 2: Limit the subject line to 50 characters (72 is the absolute hard limit).
Rule 3: Capitalize the first letter of the subject line.
Rule 4: Do not end the subject line with a period.
Rule 5: Use the imperative mood in the subject line (e.g., "Fix bug," "Add feature,"
        not "Fixed" or "Adds"). Test formula: It must complete the sentence: "If applied,
        this commit will [your subject line here]".
Rule 6: Wrap the body text manually at 72 characters to prevent Git formatting issues.
Rule 7: Use the body to explain what and why vs. how. Assume the code explains the how;
        the message must explain the context and reasoning.

## Check on CI

When CI access is available and the user requested PR follow-up, check the CI run for the PR.
If there are CI failures, investigate them and change the PR.

If the CI failures are not related to your work, suggest filing an issue or otherwise fixing them separately.
If they are related to your work, and the changes needed are not minor, fix them using the same workflow you used to write the code.

If CI is in progress and the branch has multiple commits, check if there are incomplete runs on older commits that can be canceled. Ask the user if you can cancel them unless you are already pre-authorized to cancel.

## Cleaning up history

Before pushing the PR, squash merge commits into a useful history.
Once the PR is opened, additional commits should be added on so reviewers can see additional changes.
If additional commits added onto the PR are not useful for history
* if it is best to squash merge the PR into a single commit, tell the user
* otherwise offer to squash a subset of the commits together

From gregwebs/skills-sdlc, MIT.

More from gregwebs/skills-sdlc