pr

Files (1)

• SKILL.md

SKILL.md (first lines)

# GitHub Pull Request

Use this workflow when the user wants a PR created from the current branch.

## Base Branch

- Use the user-provided base branch when present.
- Default to `main` when no base branch is provided.

## Workflow

1. Identify the current branch with `git branch --show-current`.
2. Stop if the current branch is the base branch.
3. Inspect commits with `git log origin/<base>..HEAD --oneline`.
4. Inspect changed files with `git diff origin/<base>...HEAD --name-status`.
5. Inspect the full branch diff with `git diff origin/<base>...HEAD`.
6. Check whether the branch is pushed and whether an open PR already exists.
7. Summarize the changes by feature additions, structural changes, refactors,
   tests, and docs.
8. Identify the key change a reviewer needs to understand and choose the smallest
   useful visual explanation (see below). Omit it when the summary is sufficient.
9. Draft a PR title and body that match existing repository style.
10. Push the current branch if needed.
11. Create the PR with the available GitHub tooling, preferring `gh pr create`
    when available.
12. Return the PR URL.

## PR Body Shape

Follow the repository's PR template when present. Otherwise, prefer a concise
body like:

```md
## Summary
- ...

<!-- Optional: add a change-specific section with the smallest useful visual. -->

## Testing
- ...
```

Place each visual next to the short explanation it supports. Choose a heading
that fits the change rather than always using `How It Works`; omit unused
optional sections. Mention tests that were not run.

## Visual Explanations

Choose by what the reviewer needs to understand, not by file type or a fixed
diagram format:

| Key point | Smallest useful view |
| --- | --- |
| Conditions, branches, or algorithms | Pseudocode or a short `diff` |
| Call order or runtime execution path | Call tree in a `text` block |
| UI composition or state ownership | Component tree |
| File responsibilities or module moves | Shallow file tree |
| Requests and responses between participants | Mermaid `sequenceDiagram` |
| Data flow, branching, or dependencies | Mermaid `flowchart` |
| Visible UI or layout changes | Captured before/after screenshots |

- Use `diff` when a small part of an existing shape changes: pseudocode, call
  trees, component trees, or file trees. Show the small whole block instead when
  most of it is new or omitted context would hide ownership or order.
- Prefer one visual. Add another only when it explains a distinct key point;
  skip visuals for trivial changes or when they merely repeat the summary.
- Use actual names, paths, states, and relationships from the branch diff and
  relevant source. Keep only the calls, files, state, and boundaries needed to
  understand the change, not the entire architecture. Do not invent components,
  relationships, or screenshot evidence.
- Use captured screenshots accessible from the PR for appearance changes.
  If unavailable, describe the change in text instead of guessing its appearance.
- Keep visuals readable directly on GitHub using Markdown, fenced code blocks,
  Mermaid, or accessible images. Do not generate local HTML artifacts or require
  the `show-me` skill for this step.

## Safety

- Do not create a PR from `main` or the selected base branch.
- Do not force-push unless the user explicitly requests it.
- If an open PR already exists for the branch, return that PR instead of creating
  a duplicate.

From EATSTEAK/skills, MIT.

More from EATSTEAK/skills