메뉴
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.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Validates an in-progress PR or feature branch of dart_skills_lint against known downstream ecosystem consumers. Use when assessing breaking changes across external repositories during PR evaluation, testing migrations against the changelog, or determining necessary backwards compatibility shims.
How to integrate, update, and configure the dart_skills_lint validation tool within a repository. Make sure to use this skill whenever the user asks to update dart_skills_lint, configure skills validation tests, fix skills linter dependency drifts, verify repository state before editing, optimize lint rules execution, or draft pull request submission commands.
Use this skill when you need to validate AI agent skills with dart_skills_lint — running the linter, interpreting failures, fixing violations, and authoring custom rules.
A deliberately broken fixture used by example/README.md to show what each rule's error output looks like.
Reference fixture for dart_skills_lint. Demonstrates a SKILL.md that passes every default rule: hyphen-lowercase name matching the parent directory, a properly sized description, and no other frontmatter fields that would trigger the disallowed-field check.
Reviews the specified code against the canonical API Design guidelines. Use this skill when the user asks for an API review or to check code against API design principles.
| name | contributor-pr-description |
| description | 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. |
| metadata | {"internal":true} |
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.
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.
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.
Always use the following template (or a very similar structure) when drafting a PR description:
## Summary
[Provide a clear, 1-2 sentence summary of what this PR does.]
## Motivation and Context
[Explain why this change is necessary. What problem does it solve? If it's a bug fix, what was the broken behavior?]
## Related Issues
[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".]
## What changed
[Optional: Provide a bulleted list of the most important technical changes made in the code. This is useful for larger PRs.]
- Added `FooClass` to handle XYZ.
- Updated `BarMethod` to return `Result`.
## Testing Instructions
[Explain how reviewers can test your changes locally. Mention any manual verification steps.]
- Run `dart test` to ensure all tests pass.
- [Any specific manual testing steps]
Bad: "Fixed the bug." (Too vague, doesn't explain what bug)
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)
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)