contributor-pr-description

Name: contributor-pr-description
Author: flutter

2.7kstars159forks

How to install contributor-pr-description?

flutter/agent-plugins/contributor-pr-description

$npx -y skills add flutter/agent-plugins --skill contributor-pr-description

Installs into the current project.

Summary

Guidelines and format for writing pull request descriptions in this repository. Use this skill whenever the user asks you to draft a pull request description, submit a PR, or update a PR description.

Files · 1

View on GitHub

SKILL.md

1	# Pull Request Description Guidelines
2
3	When writing a pull request (PR) description, your goal is to provide reviewers with enough context to understand what you did, why you did it, and how they can verify it. A good PR description speeds up the review process and serves as documentation for future contributors.
4
5	## Identity Verification
6
7	If you are in an environment where there are multiple GitHub identities (e.g., an AI agent identity and a primary user identity), you must verify your identity before pushing or creating a PR.
8
9	Before committing, pushing, or opening a PR, ensure you are using the identity that the user expects based on the type of work and the repository you are working on. Verify your active GitHub CLI auth (`gh auth status`) and ensure your Git commit author (`git commit --author="..."`) matches the correct identity for the task.
10
11	## PR Description Template
12
13	Always use the following template (or a very similar structure) when drafting a PR description:
14
15	```markdown
16	## Summary
17	[Provide a clear, 1-2 sentence summary of what this PR does.]
18
19	## Motivation and Context
20	[Explain why this change is necessary. What problem does it solve? If it's a bug fix, what was the broken behavior?]
21
22	## Related Issues
23	[If this PR fixes an open issue, link to it using keywords. e.g., "Fixes #123" or "Closes #456". If it relates to an issue but doesn't close it, use "Related to #789".]
24
25	## What changed
26	[Optional: Provide a bulleted list of the most important technical changes made in the code. This is useful for larger PRs.]
27	- Added `FooClass` to handle XYZ.
28	- Updated `BarMethod` to return `Result`.
29
30	## Testing Instructions
31	[Explain how reviewers can test your changes locally. Mention any manual verification steps.]
32	- Run `dart test` to ensure all tests pass.
33	- [Any specific manual testing steps]
34
35	```
36
37	## Tone and Style
38
39	1. Be clear and concise: Avoid rambling. Use bullet points for readability.
40	2. Focus on the "Why": The diff shows what changed. The description should explain why it changed.
41	3. Be professional: Use natural, accessible language.
42
43	## Examples of Bad vs Good Summaries
44
45	Bad: "Fixed the bug." (Too vague, doesn't explain what bug)
46	Bad: "Changed line 42 in `main.dart` to use `foo` instead of `bar`." (Focuses too much on the code, which is visible in the diff)
47
48	Good: "Fixes a crash when the user clicks 'Submit' without entering an email address by adding validation to the input form." (Explains the problem and the solution)

People who liked this also viewed

6 picks

Type

contributor-pr-description

2.7kstars159forks

View on GitHub

How to install contributor-pr-description?

flutter/agent-plugins/contributor-pr-description

$npx -y skills add flutter/agent-plugins --skill contributor-pr-description

Installs into the current project.

Summary

Guidelines and format for writing pull request descriptions in this repository. Use this skill whenever the user asks you to draft a pull request description, submit a PR, or update a PR description.

Files · 1

View on GitHub

SKILL.md

1	# Pull Request Description Guidelines
2
3	When writing a pull request (PR) description, your goal is to provide reviewers with enough context to understand what you did, why you did it, and how they can verify it. A good PR description speeds up the review process and serves as documentation for future contributors.
4
5	## Identity Verification
6
7	If you are in an environment where there are multiple GitHub identities (e.g., an AI agent identity and a primary user identity), you must verify your identity before pushing or creating a PR.
8
9	Before committing, pushing, or opening a PR, ensure you are using the identity that the user expects based on the type of work and the repository you are working on. Verify your active GitHub CLI auth (`gh auth status`) and ensure your Git commit author (`git commit --author="..."`) matches the correct identity for the task.
10
11	## PR Description Template
12
13	Always use the following template (or a very similar structure) when drafting a PR description:
14
15	```markdown
16	## Summary
17	[Provide a clear, 1-2 sentence summary of what this PR does.]
18
19	## Motivation and Context
20	[Explain why this change is necessary. What problem does it solve? If it's a bug fix, what was the broken behavior?]
21
22	## Related Issues
23	[If this PR fixes an open issue, link to it using keywords. e.g., "Fixes #123" or "Closes #456". If it relates to an issue but doesn't close it, use "Related to #789".]
24
25	## What changed
26	[Optional: Provide a bulleted list of the most important technical changes made in the code. This is useful for larger PRs.]
27	- Added `FooClass` to handle XYZ.
28	- Updated `BarMethod` to return `Result`.
29
30	## Testing Instructions
31	[Explain how reviewers can test your changes locally. Mention any manual verification steps.]
32	- Run `dart test` to ensure all tests pass.
33	- [Any specific manual testing steps]
34
35	```
36
37	## Tone and Style
38
39	1. Be clear and concise: Avoid rambling. Use bullet points for readability.
40	2. Focus on the "Why": The diff shows what changed. The description should explain why it changed.
41	3. Be professional: Use natural, accessible language.
42
43	## Examples of Bad vs Good Summaries
44
45	Bad: "Fixed the bug." (Too vague, doesn't explain what bug)
46	Bad: "Changed line 42 in `main.dart` to use `foo` instead of `bar`." (Focuses too much on the code, which is visible in the diff)
47
48	Good: "Fixes a crash when the user clicks 'Submit' without entering an email address by adding validation to the input form." (Explains the problem and the solution)

People who liked this also viewed

6 picks

Type