Create Pr. Skip

create a pull request with standardized description template

Security Scan

The skill's instructions match its stated purpose (creating a PR with a template) but there are small inconsistencies: it omits required binaries/credentials (git, gh, and GitHub auth) from its metadata and doesn't document authentication needs.

Purpose & Capability

The name/description align with the instructions: the SKILL.md describes gathering git context and using the GitHub CLI (gh) to create and label PRs. However, the skill metadata declares no required binaries or credentials even though the instructions rely on git and gh and on an authenticated GitHub session.

Instruction Scope

The runtime instructions stay within the stated purpose: they run git commands to gather diffs/commits, infer change categories, and use gh to create/edit PRs and labels. There are no instructions to read unrelated system files, external endpoints, or to exfiltrate data.

Install Mechanism

This is an instruction-only skill with no install spec or code files, so nothing will be written to disk or downloaded during install. That minimizes install risk.

Credentials

The SKILL.md requires git and the GitHub CLI (gh) and implicitly requires GitHub authentication (gh auth or GITHUB_TOKEN) to create/edit PRs, but the registry metadata lists no required binaries or environment/credential variables. The omission is disproportionate and can mislead users about necessary credentials and tooling.

Persistence & Privilege

always is false and disable-model-invocation is true, so the skill will not run autonomously and does not request permanent high privilege. The skill does not modify other skills or system-wide settings.

What to consider before installing

This skill appears to do what it says (prepare a PR description and call the GitHub CLI), but the metadata omits important prerequisites. Before installing/using it: ensure you have git and the GitHub CLI (gh) installed and authenticated (gh auth login or a GITHUB_TOKEN), and run it only from the intended repository/branch because the instructions run git commands and create an actual PR. Because disable-model-invocation is true, the skill cannot run on its own, but you should still verify templates and the final PR body before submitting. If you plan to publish or automate this skill, ask the author to declare required binaries and the authentication requirement in the metadata so users know what credentials and tooling are needed.

Create Pull Request

Create a pull request with a well-structured description based on the branch changes.

Instructions

1. Gather Context

First, collect information about the changes:

# Get current branch and verify it's not main
git branch --show-current

# Get commit history for this branch
git log --oneline main..HEAD

# Get detailed commit messages for context
git log --format="### %s%n%n%b" main..HEAD

# Get file change statistics
git diff --stat main..HEAD

# Get the actual diff for understanding changes
git diff main..HEAD

2. Analyze the Changes

Based on the gathered information, determine:

• What changed: Categorize changes (features, fixes, refactors, docs, tests)
• Why it changed: Infer motivation from commit messages and code changes
• Impact: Breaking changes, new dependencies, migrations needed
• Testing: What tests were added/modified, how to verify manually

3. Check for Related Issues

Look for issue references:

• In commit messages (e.g., "fixes #123", "closes #456")
• In branch name (e.g., fix/issue-123-description)
• In code comments or TODOs addressed

4. Generate PR Description

Create the PR using this template structure:

gh pr create --title "<type>(<scope>): <description>" --body "$(cat <<'EOF'
## Summary

<1-3 sentence overview of what this PR does and why>

## Changes

<Categorized bullet list of changes>

### Added
- <new features or capabilities>

### Changed
- <modifications to existing functionality>

### Fixed
- <bug fixes>

### Removed
- <deprecated or removed functionality>

## Motivation

<Why were these changes needed? What problem does this solve?>

## Testing

<How was this tested?>

- [ ] Unit tests added/updated
- [ ] Integration tests added/updated
- [ ] Manual testing performed

### Manual Testing Steps

<If applicable, steps to manually verify the changes>

## Breaking Changes

<If any, describe what breaks and migration path. Remove section if none.>

## Related Issues

<Link to related issues. Remove section if none.>

- Closes #<issue_number>
- Related to #<issue_number>

## Checklist

- [ ] Code follows project style guidelines
- [ ] Self-review completed
- [ ] Tests pass locally
- [ ] Linting passes
- [ ] Documentation updated (if needed)

---

Generated with [Claude Code](https://claude.com/claude-code)
EOF
)"

5. Title Format

Use conventional commit format for the PR title:

• feat(scope): add new feature
• fix(scope): correct bug behavior
• refactor(scope): restructure without behavior change
• docs(scope): update documentation
• test(scope): add or modify tests
• chore(scope): maintenance tasks

6. Apply Labels

After creating the PR, apply appropriate labels based on the changes. Use gh pr edit <number> --add-label <label>.

Check the repository's available labels first:

gh label list

Common Type Labels

Label	When to Use
enhancement	New features, capabilities, or improvements
bug	Bug fixes
documentation	Documentation-only changes
breaking-change	User-facing breaking changes requiring migration

Breaking Change Criteria

Only apply breaking-change for user-facing changes that require users to modify their:

• Configuration files
• CLI invocations
• API integrations

Do NOT apply for internal refactors unless they affect external consumers.

7. After Creation

After creating the PR:

1. Display the PR URL with applied labels
2. Suggest adding reviewers if appropriate
3. Note if any CI checks need to pass

Guidelines

DO:

• Be specific about what changed and why
• Include testing evidence
• Link related issues
• Note breaking changes prominently
• Remove empty optional sections

DON'T:

• Include irrelevant commits (keep PR focused)
• Leave placeholder text in the description
• Skip the testing section
• Create PRs without running local checks first