issue-to-pr — Agent Skill

You are an autonomous agent that reads a GitHub issue, understands the problem, locates the relevant code, implements a fix, and prepares everything for review. Follow the phases below in order, using the checklist to track progress.

Progress Checklist

Use this checklist to track your progress through the workflow:

• Phase 1: Parse Issue Reference
• Phase 2: Fetch Issue Details
• Phase 3: Clone or Locate Repository
• Phase 4: Analyze the Issue
• Phase 5: Implement the Fix
• Phase 6: Verify the Fix
• Phase 7: Present Changes & Get Confirmation
• Phase 8: Submit Pull Request (User-Approved)

Phase 1: Parse Issue Reference

Extract the GitHub issue reference from the user's input.

Supported input formats:

https://github.com/owner/repo/issues/123

owner/repo#123

#123

123

Parsing logic

1. Full URL: Scan for

   https://github.com/{owner}/{repo}/issues/{number}

   and extract components directly.
2. Shorthand: Match

   {owner}/{repo}#{number}

   pattern.
3. Issue number only: If only a number (or

   #number

   ) is provided:
   • Run

     git remote -v

     to detect the current repository's GitHub remote.
   • Parse

     owner

     and

     repo

     from the remote URL (supports both HTTPS and SSH formats).
   • If not in a git repo or no GitHub remote is found, ask the user for the full URL.
4. If no valid reference is found, ask the user to provide a valid GitHub issue URL.
5. Confirm the parsed values before proceeding:

   Parsed issue: {owner}/{repo}#{number}

Phase 2: Fetch Issue Details

Retrieve the full issue content including title, body, labels, and comments.

Strategy A: Use

gh

CLI (preferred)

Run in the terminal:

gh issue view {number} --repo {owner}/{repo} --comments

If the command succeeds, extract from the output:

• Title
• Body / Description
• Labels
• Comments (may contain important context, reproductions, or workarounds)

Strategy B: Fallback to

fetch_content

If

gh

1. Use the

   fetch_content

   tool with the issue URL:

   https://github.com/{owner}/{repo}/issues/{number}

2. Parse the fetched page content to extract:
   • Issue title and body
   • Any referenced file paths, error messages, or stack traces
   • Comments from maintainers or the reporter

Extract Key Information

From the issue content, identify and note:

Phase 3: Clone or Locate Repository

Ensure you have local access to the repository source code.

Step 1: Check current workspace

git remote -v 2>/dev/null

• If the output contains

  github.com/{owner}/{repo}

  (or

  github.com:{owner}/{repo}

  ), you are already in the correct repo. Skip to Step 3.

Step 2: Clone if needed

If the current workspace is not the target repository, clone it:

gh repo clone {owner}/{repo} /tmp/{repo} 2>/dev/null || git clone https://github.com/{owner}/{repo}.git /tmp/{repo}

Then inform the user about the clone location.

Step 2.5: Change into the repository directory

After locating or cloning the repository,

cd

cd {repo_path}

Step 2.7: Check push permission and prepare fork if needed

Determine if you have push access to the repository:

gh api repos/{owner}/{repo}/collaborators/$(gh api user --jq '.login') --silent 2>/dev/null
has_push=$?

If

has_push

gh repo fork {owner}/{repo} --remote-name fork --clone=false

This ensures the fork is ready before creating the fix branch. Note which remote to push to:

• If you have write access: push to

  origin

• If you forked: push to

  fork

Step 3: Ensure correct branch

First, detect the default branch:

# Detect the default branch (prefer GitHub API, fallback to git)
default_branch=$(gh api repos/{owner}/{repo} --jq '.default_branch' 2>/dev/null)
if [ -z "$default_branch" ]; then
  default_branch=$(git symbolic-ref --short refs/remotes/origin/HEAD 2>/dev/null | sed 's|^origin/||')
fi
if [ -z "$default_branch" ]; then
  default_branch="main"
fi

Then check out the default branch and pull latest changes:

git checkout $default_branch
git pull --ff-only

Check if the fix branch already exists:

if git show-ref --verify --quiet refs/heads/fix/issue-{number} 2>/dev/null || \
   git show-ref --verify --quiet refs/remotes/origin/fix/issue-{number} 2>/dev/null; then
  echo "Branch fix/issue-{number} already exists"
fi

If the branch already exists, ask the user whether to:

• Reuse the existing branch and continue from where it left off
• Recreate the branch from the latest default branch (deletes existing work)
• Rename to

  fix/issue-{number}-v2

  (or incrementing suffix)

Create the fix branch:

git checkout -b fix/issue-{number}

Phase 4: Analyze the Issue

Systematically locate the problem in the codebase.

4.1 Keyword Search

Use the error messages, file paths, and function names from the issue to search:

• Use

  grep_code

  to search for error strings, function names, or variable names mentioned in the issue.
• Use

  search_codebase

  for semantic searches when the issue describes behavior rather than specific code.
• Use

  search_file

  to find files by name if the issue mentions specific filenames.

4.2 Understand the Context

Once you find candidate files:

1. Read the relevant files to understand the current implementation.
2. Trace the code path that leads to the reported bug.
3. Check related tests to understand expected behavior.
4. Review recent git history for the affected files if useful:

   git log --oneline -10 -- {file_path}
   

4.3 Root Cause Analysis

Before writing any code, produce a structured analysis:

### Analysis Result
- **Root Cause:** {Why the bug occurs}
- **Affected Files:** {file1 (function_name), file2 (function_name)}
- **Fix Strategy:** {What the minimal change should be}
- **Risk Assessment:** Low / Medium / High
- **Estimated Changes:** {N files, ~M lines}

This structured output will be referenced in Phase 5 (implementation) and Phase 7 (summary).

4.4 Scope Assessment

Before proceeding to implementation, assess the scope:

• Multiple sub-problems: If the issue describes multiple distinct problems, focus on the most critical one first. Note remaining items for follow-up issues or separate PRs.
• Monorepo detection: Check for

  workspaces

  in

  package.json

  ,

  pnpm-workspace.yaml

  ,

  lerna.json

  , or similar workspace config files. If found, narrow your search scope to the relevant package/workspace.

Phase 5: Implement the Fix

Apply the minimal code change to resolve the issue.

Guidelines

• Minimal diff: Change only what is necessary to fix the issue. Do not refactor unrelated code.
• Consistency: Follow the existing code style, naming conventions, and patterns in the project.
• No new dependencies unless absolutely required and justified.
• Use the

  search_replace

  tool to make precise edits.

If Multiple Files Need Changes

1. Plan the full set of changes before starting.
2. Apply changes one file at a time.
3. After each file change, verify there are no syntax errors using

   get_problems

   .

Phase 6: Verify the Fix

Validate that the fix works and doesn't break anything.

6.1 Detect Project Type and Test Runner

Look for common indicators:

package.json

npm test

npx jest

npx vitest

Cargo.toml

cargo test

go.mod

go test ./...

pyproject.toml

setup.py

pytest

Makefile

make test

pom.xml

mvn test

build.gradle

./gradlew test

6.2 Run Tests

# Run the full test suite or scoped tests related to the changed files
{test_command}

• If tests pass, proceed to Phase 7.
• If tests fail, analyze the failure, adjust the fix, and re-run.

6.2.1 No Test Framework Detected

If no test runner or test files are found:

1. Run static analysis using

   get_problems

   on all changed files to catch syntax errors and type issues.
2. Manually verify the fix by reading through the changed code paths.
3. Note in the PR that automated tests were not available:

   No automated test framework was detected in this project. The fix was verified via static analysis and manual code review.

6.3 Lint / Format Check (if available)

Check if the project has lint or format tools configured, and run them:

# Examples
npm run lint 2>/dev/null
cargo clippy 2>/dev/null
go vet ./... 2>/dev/null

Fix any lint issues introduced by your changes.

Phase 7: Present Changes & Get Confirmation

Present the fix to the user and wait for explicit approval before proceeding.

7.1 Show Fix Summary

## Fix Summary for {owner}/{repo}#{number}

**Issue:** {issue_title}
**Root Cause:** {brief explanation}
**Changes:**
- `{file_path_1}`: {what was changed and why}
- `{file_path_2}`: {what was changed and why}

7.2 Show Diff

Display the actual code changes so the user can review them:

git diff

Highlight the key modifications and explain their impact.

7.3 Wait for User Confirmation

Ask the user:

Would you like me to submit these changes as a Pull Request? If anything needs adjustment, let me know.

• If the user approves, proceed to Phase 8.
• If the user requests changes, revise the fix (return to Phase 5) and re-present.

Phase 8: Submit Pull Request (User-Approved)

Only execute this phase after the user has approved the changes in Phase 7.

Step 1: Stage and Commit

git add -A
git commit -m "fix: {short description} (#{number})

{Detailed explanation of what was wrong and how this commit fixes it.}

Closes #{number}"

Step 2: Push the branch

Push to the appropriate remote based on the permission check from Phase 3:

# If you have write access (push succeeded in Phase 3 check):
git push origin fix/issue-{number}

# If you forked the repository in Phase 3:
git push fork fix/issue-{number}

Step 2.5: Check for repository PR template

pr_template=""
for f in .github/PULL_REQUEST_TEMPLATE.md .github/pull_request_template.md docs/pull_request_template.md PULL_REQUEST_TEMPLATE.md; do
  if [ -f "$f" ]; then
    pr_template="$f"
    break
  fi
done

If a PR template is found, use it as the base for the PR body and fill in the relevant sections. Otherwise, use the default template below.

Step 3: Create Pull Request

Default PR Body Template

## Summary

Fixes #{number}.

### Problem
{Brief problem description from issue analysis}

### Solution
{Brief solution description from fix implementation}

### Changes
- {change 1}
- {change 2}

### Testing
- [x] Existing tests pass
- [x] {Any additional verification performed}

---
<sub>🔧 Generated by [issue-to-pr](https://github.com/4yDX3906/issue-to-pr)</sub>

gh pr create \
  --repo {owner}/{repo} \
  --title "fix: {short description}" \
  --body "$pr_body" \
  --base {default_branch} \
  --head {head_ref}

{head_ref}

is

fix/issue-{number}

for direct push or

{your_username}:fix/issue-{number}

for fork push.

Tip: Add the

--draft

flag to create a draft PR if the fix needs further review before marking as ready.

Step 4: Verify & Report

• Capture the PR URL from the

  gh pr create

  output.
• Report to the user:

  ✅ PR created successfully: {PR_URL} Please review the PR page for any CI checks or reviewer feedback.

• If creation fails, show the full error and provide the manual command as a fallback.

Fallback: Manual Instructions

If the user declines auto-submission or any step fails, present:

1. Suggested commit message:

   fix: {short description} (#{number})
   
   {Detailed explanation}
   
   Closes #{number}
   

2. PR creation command:

   gh pr create \
     --title "fix: {short description}" \
     --body "..." \
     --base {default_branch}
   

3. Recommend next steps:
   • Review the diff:

     git diff {default_branch}

   • Commit and push the changes
   • Create the PR and verify CI passes

Error Handling

Handle these common failure scenarios gracefully:

gh

git clone

fetch_content

brew install gh

gh auth

gh auth login

/tmp

git push

gh pr create

gh

gh auth login

get_problems

Notes

• Local operations: All code analysis and modification happens locally. Only standard Git and GitHub API operations (clone, push, PR creation) send data to GitHub.
• Authentication: Uses your existing

  gh

  CLI credentials. No additional credentials are stored.
• User consent required: The agent will not push code or create PRs without explicit user approval in Phase 7.