pr-writing

Files (1)

• SKILL.md

SKILL.md (first lines)

# PR Writing Skill

## What I do

- Produce clean, review-ready pull request summaries.
- Keep PRs small, focused, and easy to merge.
- Ensure communication includes context, testing, and reviewer focus areas.
- Provide reusable templates for consistent PR quality.

## Workflow

### 1) Communicate early

- Link the related issue (or state why none exists).
- Announce ownership when starting work.
- Clarify scope before implementation.

### 2) Gather repo context before drafting

- Inspect `git status -sb`, `git branch -vv`, `git remote -v`, and `git diff --stat`.
- Check `gh repo view` if `gh` is available and a remote exists.
- Look for PR templates/guidelines in `.github/PULL_REQUEST_TEMPLATE*`, `.github/pull_request_template*`, `CONTRIBUTING.md`, and `README.md`.

If the remote is missing or gh is unavailable, say what was checked and fall back to git-derived context instead of guessing.

### 3) Keep scope small

- Fix one problem per PR.
- Avoid bundling unrelated changes.
- Split larger work into logical commits.

### 4) Keep changes clean

- Follow project lint/style rules.
- Preserve existing architecture and patterns.
- Remove dead code and noisy changes.

### 5) Test before opening

- State what you tested (manual + automated).
- Mention environments used.
- Call out known gaps or deferred tests.

### 6) Write the summary for reviewers

Include:

- Related issue/context
- What changed and why
- How it was tested
- Reviewer focus
- Risks/migrations
- Out-of-scope items
- Target repo/base branch when known

## PR Body Template

```markdown
## Related issue

- Closes #<issue-number>

## Summary

- <change 1>
- <change 2>
- <change 3>

## Scope

- In scope: <items>
- Out of scope: <items>

## Testing

- [ ] Unit tests
- [ ] Integration tests
- [ ] Manual verification

### Test details

- Commands run:
  - `<command>`
- Results:
  - `<result>`

## Reviewer focus

- Please review: <critical files/logic>
- Risk areas: <edge cases>

## Notes

- Migrations/config changes: <none | details>
- Follow-ups: <optional>
```

## Quick Quality Checklist

- [ ] Single clear purpose
- [ ] Minimal diff / no unrelated edits
- [ ] Clear commit history
- [ ] Tests described and reproducible
- [ ] Reviewer guidance included
- [ ] Backward compatibility considered

## When to use me

Use this skill when opening a pull request or when improving an existing PR description for faster, higher-quality review.

From Jonathan0823/pi-config, MIT.

More from Jonathan0823/pi-config