Skill: 4ydx3906/issue-to-pr (version 1.3.0)

--- name: issue-to-pr description: "issue-to-pr — Automatically fix GitHub issues end-to-end: reads the issue, analyzes repository code, implements a fix, and submits a pull request. Use when the user provides a GitHub issue URL, mentions fixing a GitHub issue, or uses the /fix-issue command. Supports URLs in the format https://github.com/{owner}/{repo}/issues/{number}." version: "1.3.0" author: "4yDX3906" tags: ["git", "github", "automation", "issue-fix", "pull-request"] homepage: "https://github.com/4yDX3906/issue-to-pr" metadata: clawdbot: emoji: "🔧" requires: env: [] files: ["scripts/install.sh"] --- # 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:** | Format | Example | |---|---| | Full URL | `https://github.com/owner/repo/issues/123` | | Shorthand | `owner/repo#123` | | Issue number only | `#123` or `123` (requires being in a git repo) | ### 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: ```bash 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` is not installed or the command fails: 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: | Field | Description | |---|---| | **Problem summary** | One-sentence description of the bug or feature gap | | **Reproduction steps** | How to trigger the issue | | **Expected behavior** | What should happen | | **Actual behavior** | What actually happens | | **Error messages** | Stack traces, log output, error codes | | **File path hints** | Any files, modules, or functions mentioned | | **Related issues/PRs** | Cross-references that provide context | --- ## Phase 3: Clone or Locate Repository Ensure you have local access to the repository source code. ### Step 1: Check current workspace ```bash 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: ```bash 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` into the repository directory before running any git commands: ```bash cd {repo_path} ``` ### Step 2.7: Check push permission and prepare fork if needed Determine if you have push access to the repository: ```bash gh api repos/{owner}/{repo}/collaborators/$(gh api user --jq '.login') --silent 2>/dev/null has_push=$? ``` If `has_push` is non-zero (no write access), fork the repository now: ```bash 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: ```bash # 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: ```bash git checkout $default_branch git pull --ff-only ``` Check if the fix branch already exists: ```bash 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: ```bash 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: ```bash 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: | File | Likely runner | |---|---| | `package.json` | `npm test` or `npx jest` or `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 ```bash # 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: ```bash # 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: ```bash 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 ```bash 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: ```bash # 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 ```bash 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> ``` ```bash 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:** ```bash 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: | Scenario | Action | |---|---| | `gh` CLI not installed | Fall back to `git clone` and `fetch_content`. Suggest installing gh: `brew install gh` or see https://cli.github.com | | `gh auth` not configured | Prompt user to run `gh auth login` and retry | | Repository is private / 403 | Inform the user that authentication is required and guide them to authenticate | | Issue not found / 404 | Double-check the URL and ask the user to verify | | No write access to `/tmp` | Clone to the workspace directory instead | | Tests fail after fix | Analyze failure output, revise the fix, and re-verify | | Cannot determine root cause | Present findings so far and ask the user for guidance | | Large / complex issue | Break the issue into sub-tasks, fix the most critical part first, and note remaining work | | `git push` permission denied | Auto-fork the repository and push to fork | | `gh pr create` fails | Show error details and provide manual command | | User's `gh` not authenticated | Prompt user to run `gh auth login` first | | Branch already exists on remote | Ask user whether to force-push or create a new branch name | | PR already exists for this branch | Show existing PR URL and ask whether to update | | No test framework found | Run static analysis with `get_problems`, verify manually, and note in PR | | Issue contains multiple problems | Fix the most critical problem first; note remaining items as follow-up | | Fix branch already exists | Ask user to reuse, recreate, or rename the branch | --- ## 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.

path: CHANGELOG.md
content: # Changelog

All notable changes to this project will be documented in this file.

The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).

## [1.3.0] - 2025-04-08

### Improved
- Simplified PR submission flow: merged Phase 7/8 dual confirmation into a single step
- Early push permission detection and automatic fork preparation in Phase 3
- Streamlined fork workflow from 5 steps to direct remote selection
- Extended issue input formats: supports `owner/repo#123`, `#123`, and plain issue numbers
- Optimized repository location logic: removed hardcoded path scanning
- Enhanced default branch detection with GitHub API priority
- Added repository PR template detection and Draft PR support
- Added structured analysis output template in Phase 4

### Added
- Scope assessment section for multi-problem issues and monorepo detection
- Handling for missing test frameworks with static analysis fallback
- Branch conflict detection before creating fix branches
- New error handling scenarios in the error table

### Removed
- Redundant "Model Invocation" section (duplicated Progress Checklist)
- Merged "Security and Privacy", "Trust Statement", and "External Endpoints" into concise "Notes" section

## [1.2.0] - 2026-04-08

### Added
- PR body template now includes a promotional footer linking back to the issue-to-pr skill repository

## [1.1.0] - 2026-04-08

### Added
- Interactive PR submission workflow (Phase 7 & 8)
- Auto commit, push, and PR creation with user confirmation
- Auto-fork support for repositories without write access
- PR creation verification and URL feedback

### Changed
- Split original Phase 7 into Phase 7 (Present Changes) and Phase 8 (Submit PR)
- Enhanced error handling for push/PR failures

## [1.0.0] - 2025-04-08

### Added
- Initial release
- 7-phase workflow: Parse URL → Fetch Issue → Locate Repo → Analyze → Fix → Verify → Summary
- GitHub CLI (gh) integration with fetch_content fallback
- Auto-detection of default branch
- Commit message and PR description templates
- Comprehensive error handling


path: README.md
content: # 🔧 issue-to-pr

[![Skills.sh](https://img.shields.io/badge/skills.sh-issue--to--pr-blue)](https://skills.sh/4yDX3906/issue-to-pr)
[![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](LICENSE)

An AI Agent Skill that automatically reads a GitHub issue, analyzes the codebase, implements a fix, and submits a pull request — end-to-end, with one confirmation.

---

## ⚡ Quick Install

```bash
npx skills add 4yDX3906/issue-to-pr
```

Or install via [ClawHub](https://clawhub.com):

```bash
clawhub install issue-to-pr
```

> **That's it!** Once installed, just give your AI agent a GitHub issue URL and watch it work.

---

## ✨ Features

- **8-Phase Automated Workflow** — from issue parsing to automatic PR submission
- **GitHub CLI Integration** — uses `gh` for fast, authenticated access with `fetch_content` fallback
- **Smart Repo Detection** — auto-detects if you're already in the right repo or clones it
- **Default Branch Detection** — automatically identifies `main`, `master`, or custom default branches
- **Minimal Diffs** — changes only what's necessary, respecting existing code style
- **Built-in Verification** — runs tests, linting, and format checks before finishing
- **Interactive PR Submission** — review changes first, then auto-submit with one confirmation
- **Auto-Fork Support** — automatically forks repositories when you lack write access
- **Structured Output** — generates commit messages and PR descriptions ready to use

## 📋 Prerequisites

| Tool | Required | Notes |
|------|----------|-------|
| `git` | ✅ Yes | Must be installed and configured |
| `gh` (GitHub CLI) | 📌 Recommended | Enables fast issue fetching and PR creation. Install: [cli.github.com](https://cli.github.com) |

## 📦 Installation

### Option 1: ClawHub (Recommended)

```bash
clawhub install issue-to-pr
```

### Option 2: One-Line Install Script

```bash
bash scripts/install.sh
```

Or directly from the repo:

```bash
git clone https://github.com/ClawHub/issue-to-pr.git
cd issue-to-pr
bash scripts/install.sh
```

### Option 3: Manual Install

```bash
mkdir -p ~/.qoder/skills/issue-to-pr
cp SKILL.md ~/.qoder/skills/issue-to-pr/SKILL.md
```

## 🚀 Usage

In your AI-powered editor (Qoder, Cursor, Claude Code, etc.), simply provide a GitHub issue URL:

```
/fix-issue https://github.com/owner/repo/issues/123
```

Or describe it naturally:

```
Fix this GitHub issue: https://github.com/facebook/react/issues/12345
```

The agent will automatically:
1. Parse the issue URL and fetch details
2. Clone or locate the repository
3. Analyze the codebase to find the root cause
4. Implement a minimal fix
5. Run tests and linting
6. Present changes and wait for your confirmation
7. Auto-submit a PR (commit, push, and create PR) upon approval

## ⚙️ How It Works

```
  GitHub Issue    Parse & Fetch    Analyze Code    Implement Fix    Run Tests    Submit PR
 ┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐    ┌─────────┐   ┌─────────┐
 │    📋    │ ─▶ │    🔍    │ ─▶ │    🧠    │ ─▶ │    🔧    │ ─▶ │   ✅    │─▶ │   🚀    │
 └──────────┘    └──────────┘    └──────────┘    └──────────┘    └─────────┘   └─────────┘
  Read issue      Fetch details    Trace code       Minimal fix     Lint & test   Push & PR
  from GitHub     & clone repo     & find root      respecting       to verify     with one
                                   cause            code style       quality       confirmation
```

| Phase | Description |
|-------|-------------|
| **1. Parse URL** | Extract `owner`, `repo`, and issue `number` from the GitHub URL |
| **2. Fetch Issue** | Retrieve issue title, body, labels, and comments via `gh` or web scraping |
| **3. Locate Repo** | Check the current workspace or clone the repository |
| **4. Analyze** | Search the codebase, trace code paths, and identify the root cause |
| **5. Implement Fix** | Apply minimal, style-consistent code changes |
| **6. Verify** | Run the project's test suite and linters |
| **7. Present Changes** | Show fix summary and diff, wait for user confirmation |
| **8. Submit PR** | Auto commit, push (with fork fallback), and create PR |

## 🔒 Security & Privacy

- All code analysis and modifications happen **locally on your machine**
- Only standard Git/GitHub operations (clone, push, PR) communicate with GitHub
- Uses your existing `gh` CLI authentication — no additional credentials stored
- The agent **never pushes code or creates PRs without your explicit approval**
- No telemetry or usage data is collected

## 🖥️ Supported Platforms

- [Qoder](https://qoder.ai)
- [Cursor](https://cursor.sh)
- [Claude Code](https://claude.ai)
- [Windsurf](https://windsurf.ai)
- [GitHub Copilot](https://github.com/features/copilot)

## 🤝 Contributing

Contributions are welcome! Feel free to:

1. Fork the repository
2. Create a feature branch (`git checkout -b feature/improvement`)
3. Commit your changes (`git commit -m 'Add new feature'`)
4. Push to the branch (`git push origin feature/improvement`)
5. Open a Pull Request

## 📄 License

This project is licensed under the MIT License — see the [LICENSE](LICENSE) file for details.


path: clawhub.json
content: {
  "name": "issue-to-pr",
  "version": "1.3.0",
  "description": "Automatically fix GitHub issues by reading issue details, analyzing code, and submitting pull requests",
  "author": "4yDX3906",
  "homepage": "https://github.com/4yDX3906/issue-to-pr",
  "license": "MIT",
  "keywords": ["git", "github", "automation", "issue-fix", "pull-request"]
}


path: scripts/install.sh
content: #!/usr/bin/env bash

# SECURITY MANIFEST:
#   Environment variables accessed: none
#   External endpoints called: https://github.com (git clone only)
#   Local files read: SKILL.md, scripts/*
#   Local files written: ~/.qoder/skills/issue-to-pr/

set -o errexit -o nounset -o pipefail

# ============================================================
# issue-to-pr Skill — Installer / Uninstaller
# ============================================================

SKILL_NAME="issue-to-pr"
INSTALL_DIR="${HOME}/.qoder/skills/${SKILL_NAME}"
SKILL_FILE="SKILL.md"

# ------------------------------------------------------------
# Colors
# ------------------------------------------------------------
RED='\033[0;31m'
GREEN='\033[0;32m'
YELLOW='\033[0;33m'
BLUE='\033[0;34m'
NC='\033[0m' # No Color

info()    { printf "${BLUE}[INFO]${NC}  %s\n" "$*"; }
success() { printf "${GREEN}[OK]${NC}    %s\n" "$*"; }
warn()    { printf "${YELLOW}[WARN]${NC}  %s\n" "$*"; }
error()   { printf "${RED}[ERROR]${NC} %s\n" "$*" >&2; }

# ------------------------------------------------------------
# Resolve the directory where this script lives
# ------------------------------------------------------------
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
REPO_ROOT="$(cd "${SCRIPT_DIR}/.." && pwd)"

# ------------------------------------------------------------
# Uninstall
# ------------------------------------------------------------
uninstall() {
    info "Uninstalling ${SKILL_NAME}..."

    if [ -d "${INSTALL_DIR}" ]; then
        rm -rf "${INSTALL_DIR}"
        success "Removed ${INSTALL_DIR}"
    else
        warn "Nothing to uninstall — ${INSTALL_DIR} does not exist."
    fi

    success "Uninstall complete."
    exit 0
}

# ------------------------------------------------------------
# Install
# ------------------------------------------------------------
install() {
    info "Installing ${SKILL_NAME}..."

    # Check dependencies
    if ! command -v git &>/dev/null; then
        error "git is not installed. Please install git first."
        exit 1
    fi

    if command -v gh &>/dev/null; then
        info "GitHub CLI (gh) detected — full functionality available."
    else
        warn "GitHub CLI (gh) not found. The skill will use fallback methods."
        warn "For the best experience, install gh: https://cli.github.com"
    fi

    # Verify source file exists
    if [ ! -f "${REPO_ROOT}/${SKILL_FILE}" ]; then
        error "Cannot find ${SKILL_FILE} in ${REPO_ROOT}."
        error "Please run this script from the repository root or the scripts/ directory."
        exit 1
    fi

    # Create target directory
    mkdir -p "${INSTALL_DIR}"
    info "Target directory: ${INSTALL_DIR}"

    # Copy skill file
    cp "${REPO_ROOT}/${SKILL_FILE}" "${INSTALL_DIR}/${SKILL_FILE}"
    success "Copied ${SKILL_FILE} to ${INSTALL_DIR}/"

    # Verify installation
    if [ -f "${INSTALL_DIR}/${SKILL_FILE}" ]; then
        success "Installation complete!"
        echo ""
        info "The skill is now available at: ${INSTALL_DIR}/${SKILL_FILE}"
        info "You can use it in Qoder, Cursor, or Claude Code by typing:"
        echo ""
        echo "    /fix-issue https://github.com/owner/repo/issues/123"
        echo ""
    else
        error "Installation verification failed. Please try manual installation."
        exit 1
    fi
}

# ------------------------------------------------------------
# Main
# ------------------------------------------------------------
case "${1:-}" in
    --uninstall | -u)
        uninstall
        ;;
    --help | -h)
        echo "Usage: $(basename "$0") [OPTIONS]"
        echo ""
        echo "Options:"
        echo "  (none)          Install the ${SKILL_NAME} skill"
        echo "  --uninstall, -u Remove the ${SKILL_NAME} skill"
        echo "  --help, -h      Show this help message"
        ;;
    *)
        install
        ;;
esac


Security scan verdicts — ClawScan: suspicious | static analysis: clean | VirusTotal: clean | SkillSpector: suspicious (HIGH)