Prrr

PRRR — Issue-to-PR Automation

Resolves a GitHub issue end-to-end: reads contributing guidelines, creates a branch, implements the fix/feature, runs tests, pushes, and opens a pull request.

Input

• `` — A GitHub issue number (required).

Procedure

Step 0: Parse Input

Extract the issue number from the user's invocation. If ` is missing or not a valid number, stop immediately: > **Error:** No valid issue ID provided. Usage: /prrr (e.g., /prrr 42`).

Step 1: Read Contributing Guidelines

1. Check if CONTRIBUTING.md exists at the repository root.
2. If it exists, read and parse it in full. Extract and remember:

• Branch naming conventions (if any).
• Commit message format (type, scope, subject, body, sign-off requirements).
• PR title/description conventions or templates.
• Code standards, test requirements, documentation expectations.

1. If CONTRIBUTING.md does not exist, fall back to these defaults:

• Branch name: prrr/
• Commit message: fix(project): with a descriptive body
• PR title: the commit title
• PR description: summary of changes + Closes #
• Sign-off: use git commit -s if the repo has any DCO/sign-off mentions

Also check for:

• .github/PULL_REQUEST_TEMPLATE.md or .github/PULL_REQUEST_TEMPLATE/ — use the template for PR body if present.
• .github/ISSUE_TEMPLATE/ — for understanding issue structure.

Step 2: Detect Repository Remotes

1. Run git remote -v to list all configured remotes.
2. Identify:

• origin — the main upstream remote (PR target).
• Feature remote — the remote to push the branch to. This may be a fork remote (not origin). Heuristics:
• If only origin exists, use origin for both push and PR target.
• If multiple remotes exist, prefer the one matching the current user's GitHub username for pushing, and origin as the PR base.

1. Determine the default branch by running git remote show origin | grep 'HEAD branch' or inspecting git symbolic-ref refs/remotes/origin/HEAD.

Step 3: Create Branch

1. Fetch the latest from origin: git fetch origin.
2. Check if prrr/ already exists locally or remotely:

• git branch --list prrr/
• git ls-remote --heads prrr/

1. If the branch already exists, stop:

> Error: Branch prrr/ already exists. Delete it first or use a different approach.

1. Create and check out: git checkout -b prrr/ origin/.

Step 4: Fetch and Analyze the Issue

1. Use the GitHub tool to fetch issue #:

• Retrieve title, body, labels, comments, and any linked PRs.

1. If the issue does not exist or is inaccessible, stop:

> Error: GitHub issue # not found or inaccessible. Verify the issue number and repository permissions.

1. Analyze the issue to understand:

• What needs to change (bug description, feature request, task).
• Where in the codebase the change applies (search for relevant files, modules, tests).
• Acceptance criteria from the issue body or comments.

1. Explore the codebase as needed using search, file reads, and subagents to build full context before implementing.

Step 5: Implement the Resolution

Implement a complete, production-quality resolution:

1. Code changes: Write the fix or feature. Follow code standards from CONTRIBUTING.md and existing codebase patterns.
2. Tests: Add or update tests to cover the change. If the repo has an existing test framework, follow its conventions.
3. Documentation: Update any relevant docs, README sections, or changelogs if required by CONTRIBUTING.md.
4. Verify: Ensure the code compiles/builds and passes lint checks where applicable.

Do NOT cut corners — the implementation should be ready for review.

Step 6: Test, Commit, and Push

Invoke /test-commit-push to handle this step. If /test-commit-push is not available, perform these steps manually:

1. Run tests: Execute the project's test suite. If tests fail, diagnose and fix before proceeding.

• If tests fail and the fix is unclear, stop and report:

> Error: Tests failed after implementation. See output above. The branch prrr/ has been created with your changes but has not been pushed.

1. Stage changes: git add -A (or selectively stage relevant files).
2. Commit: Create a commit following CONTRIBUTING.md conventions. Example:

`` git commit -s -m "(): " -m "" ``

• The commit body should explain what changed and why.
• Include Signed-off-by if required.

1. Push: git push prrr/.

• If the push is rejected (e.g., permissions, protected branch), stop:

> Error: Push to `` rejected. Check remote permissions and branch protection rules.

Step 7: Open the Pull Request

1. Determine PR parameters:

• Base: ` on origin`.
• Head: prrr/ on the push remote.
• Title: Follow CONTRIBUTING.md conventions. Default: the commit title.
• Body: Follow PR template if one exists. Must include:
• Summary of the changes.
• Closes # to auto-link the issue.
• Any testing notes or reviewer guidance.

1. Open the PR using the GitHub PR tool.
2. Report the PR URL to the user.

Step 8: Summary

Print a summary:

✅ Issue # resolved
   Branch: prrr/
   Commit:  
   PR: 

Error Handling

All errors must be clear and actionable. The skill stops on:

| Condition | Message | |-----------|---------| | Missing ` | No valid issue ID provided. Usage: /prrr | | Issue not found | GitHub issue # not found or inaccessible | | Branch exists | Branch prrr/` already exists | | Tests fail | Tests failed — see output. Branch created but not pushed | | Push rejected | Push rejected — check remote permissions | | PR creation fails | PR creation failed — see error details. Branch pushed successfully |

Constraints

• No hardcoded values: All repo names, remotes, branch names, and conventions are discovered at runtime.
• Generic: Works across any repository with any language, build system, or test framework.
• CONTRIBUTING.md is authoritative: If it exists, its conventions override all defaults.
• Atomic steps: Each step validates its preconditions before executing.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: sgrams
• Source: sgrams/claude-skills
• License: MIT

Install and usage instructions live in the source repository linked above.