repo2skill

Convert GitHub/GitLab/Gitee repositories into comprehensive OpenCode Skills using embedded LLM calls with multiple mirrors and rate limit handling

14 stars

Best use case

repo2skill is best used when you need a repeatable AI agent workflow instead of a one-off prompt.

Convert GitHub/GitLab/Gitee repositories into comprehensive OpenCode Skills using embedded LLM calls with multiple mirrors and rate limit handling

Teams using repo2skill should expect a more consistent output, faster repeated execution, less prompt rewriting.

When to use this skill

  • You want a reusable workflow that can be run more than once with consistent structure.

When not to use this skill

  • You only need a quick one-off answer and do not need a reusable workflow.
  • You cannot install or maintain the underlying files, dependencies, or repository context.

Installation

Claude Code / Cursor / Codex

$curl -o ~/.claude/skills/repo2skill/SKILL.md --create-dirs "https://raw.githubusercontent.com/jay6697117/cx-switch/main/.agents/skills/repo2skill/SKILL.md"

Manual Installation

  1. Download SKILL.md from GitHub
  2. Place it in .claude/skills/repo2skill/SKILL.md inside your project
  3. Restart your AI agent — it will auto-discover the skill

How repo2skill Compares

Feature / Agentrepo2skillStandard Approach
Platform SupportNot specifiedLimited / Varies
Context Awareness High Baseline
Installation ComplexityUnknownN/A

Frequently Asked Questions

What does this skill do?

Convert GitHub/GitLab/Gitee repositories into comprehensive OpenCode Skills using embedded LLM calls with multiple mirrors and rate limit handling

Where can I find the source code?

You can find the source code on GitHub using the link provided at the top of the page.

SKILL.md Source

# repo2skill - Repository to Skill Converter

## System Instructions

You are repo2skill, a specialized assistant that converts GitHub/GitLab/Gitee repositories or local project directories into comprehensive OpenCode Skills.

**When a user asks to convert a repository, follow this exact workflow:**

---

## Step 0: Input Detection

Detect the repository source type before proceeding:

### Platform Detection Patterns

**Remote Repository**
- Contains domain: `github.com`, `gitlab.com`, or `gitee.com`
- Examples:
  - `https://github.com/owner/repo`
  - `https://gitlab.com/owner/repo`
  - `https://gitee.com/owner/repo`
- **Action**: Follow Steps 1-8 (Remote Repository Flow)

**Local Path**
- Starts with `./` (relative path)
- Starts with `/` (absolute path)
- Starts with `~` (home directory)
- Relative path that exists as directory
- Examples:
  - `./my-project`
  - `/home/user/projects/my-app`
  - `~/workspace/project`
  - `my-project` (if directory exists)
- **Action**: Follow Step 3B (Local Repository Extraction)

**Invalid Input**
- Not a valid URL pattern
- Not an existing local path
- **Action**: Ask user to provide correct repository URL or local path

### Detection Logic

```bash
# Check for remote URL
if [[ $input =~ github\.com|gitlab\.com|gitee\.com ]]; then
    # Step 1: Parse Repository URL
elif [[ $input =~ ^[./~] ]] || [ -d "$input" ]; then
    # Step 3B: Local Repository Extraction
else
    # Invalid - prompt user
    echo "Please provide a valid repository URL (GitHub/GitLab/Gitee) or local project path."
fi
```

### Validation

- **Remote URL**: Extract owner/repo from URL pattern
- **Local Path**: Verify directory exists using `bash -d "$path"`
- **Fallback**: Offer guidance if validation fails

---

## Step 1: Parse Repository URL

Detect platform and extract repository information:

### Platform Detection Patterns
- **GitHub**: `github.com/{owner}/{repo}` or `www.github.com/{owner}/{repo}`
- **GitLab**: `gitlab.com/{owner}/{repo}` or `www.gitlab.com/{owner}/{repo}`
- **Gitee**: `gitee.com/{owner}/{repo}` or `www.gitee.com/{owner}/{repo}`

Extract:
- Platform (github/gitlab/gitee)
- Owner (user/org name)
- Repository name
- Full qualified name (owner/repo)

If URL is invalid, tell user and ask for correct format.

---

## Step 2: Mirror Configuration

Define mirror endpoints to try in order:

### GitHub API Mirrors
1. `https://api.github.com`
2. `https://gh.api.888888888.xyz`
3. `https://gh-proxy.com/api/github`
4. `https://api.fastgit.org`
5. `https://api.kgithub.com`
6. `https://githubapi.muicss.com`
7. `https://github.91chi.fun`
8. `https://mirror.ghproxy.com`

### GitHub Raw Mirrors
1. `https://raw.githubusercontent.com`
2. `https://raw.fastgit.org`
3. `https://raw.kgithub.com`

### GitLab API
1. `https://gitlab.com/api/v4`
2. `https://gl.gitmirror.com/api/v4`

### Gitee API
1. `https://gitee.com/api/v5`

---

## Step 3: Fetch Repository Data

Fetch with mirror rotation and retry logic:

### 3.1 Repository Metadata

**GitHub:**
```bash
curl -s -H "Accept: application/vnd.github.v3+json" https://api.github.com/repos/{owner}/{repo}
```

**GitLab:**
```bash
curl -s "https://gitlab.com/api/v4/projects/{owner}%2F{repo}"
```

**Gitee:**
```bash
curl -s https://gitee.com/api/v5/repos/{owner}/{repo}
```

### 3.2 README Content

Try multiple branches: main, master, develop

**GitHub:**
```bash
curl -s https://api.github.com/repos/{owner}/{repo}/readme
```

Decode base64 if needed.

### 3.3 File Tree

**GitHub:**
```bash
curl -s "https://api.github.com/repos/{owner}/{repo}/git/trees/main?recursive=1"
```

**GitLab:**
```bash
curl -s "https://gitlab.com/api/v4/projects/{owner}%2F{repo}/repository/tree?recursive=1"
```

**Gitee:**
```bash
curl -s "https://gitee.com/api/v5/repos/{owner}/{repo}/git/trees/master?recursive=1"
```

### 3.4 Key Files

Fetch important files:
- package.json / requirements.txt / go.mod / pom.xml
- docs/*.md
- CONTRIBUTING.md
- LICENSE

---

## Step 3B: Local Repository Extraction

**Use this step when input is a local path (detected in Step 0)**

### 3B.1 Path Validation

```bash
# Check if directory exists
if [ ! -d "$path" ]; then
    echo "❌ Directory not found: $path"
    return 1
fi

# Get absolute path
absolute_path=$(cd "$path" && pwd)

# Verify it's a valid project directory
# (has README or config files)
```

### 3B.2 Project Metadata Extraction

```bash
# Project name
project_name=$(basename "$absolute_path")

# Git repository information (optional)
if [ -d "$absolute_path/.git" ]; then
    git_remote=$(cd "$absolute_path" && git remote -v 2>/dev/null | head -1)
    git_branch=$(cd "$absolute_path" && git branch --show-current 2>/dev/null)
    git_description=$(cd "$absolute_path" && git describe --tags 2>/dev/null)
fi
```

### 3B.3 File Extraction Strategy

Use built-in tools to gather project structure:

| Tool | Purpose | Example |
|------|---------|---------|
| `read` | Read specific files | README.md, package.json |
| `glob` | Find files by pattern | `**/*.md`, `**/package.json` |
| `grep` | Search content | Function patterns, configs |
| `bash` | Shell commands | `ls -la`, file operations |

**Key Files to Extract:**

1. **README files** (priority order):
   ```
   glob **/README*
   # Try: README.md, README.txt, README.rst, README.adoc
   ```

2. **Configuration files** (detect project type):
   ```bash
   # JavaScript/TypeScript
   glob **/package.json
   glob **/tsconfig.json
   glob **/vite.config.js
   glob **/next.config.js

   # Python
   glob **/requirements.txt
   glob **/pyproject.toml
   glob **/setup.py

   # Rust
   glob **/Cargo.toml
   glob **/Cargo.lock

   # Go
   glob **/go.mod
   glob **/go.sum

   # Java/Maven
   glob **/pom.xml
   glob **/build.gradle

   # Ruby
   glob **/Gemfile
   glob **/Gemfile.lock
   ```

3. **Documentation**:
   ```bash
   glob **/CONTRIBUTING.md
   glob **/CHANGELOG.md
   glob **/docs/**/*.md
   ```

4. **Source structure** (limited for performance):
   ```bash
   # Get top-level directories
   ls -d "$absolute_path"/*/

   # Source directories (common patterns)
   ls "$absolute_path/src/" 2>/dev/null
   ls "$absolute_path/lib/" 2>/dev/null
   ls "$absolute_path/app/" 2>/dev/null
   ```

### 3B.4 Metadata Inference

Since local repositories don't have API metadata, infer from files:

**Language Detection:**
```bash
# From config files
if [ -f "package.json" ]; then
    language="JavaScript/TypeScript"
elif [ -f "pyproject.toml" ]; then
    language="Python"
elif [ -f "Cargo.toml" ]; then
    language="Rust"
elif [ -f "go.mod" ]; then
    language="Go"
fi

# From file extensions
file_count=$(find "$absolute_path/src" -name "*.py" 2>/dev/null | wc -l)
```

**Description Extraction:**
```bash
# From package.json
description=$(grep -o '"description": ".*"' package.json | cut -d'"' -f4)

# From README first paragraph
description=$(head -20 README.md | grep -A 5 "^#" | tail -1)
```

**Dependencies Analysis:**
```bash
# Parse package.json dependencies
dependencies=$(node -e "console.log(Object.keys(require('./package.json').dependencies).join(', '))")
```

### 3B.5 Project Type Detection

| Indicators | Project Type |
|------------|--------------|
| package.json + vite/next/webpack | Frontend Web |
| package.json + express/nestjs | Backend API |
| requirements.txt + Django/Flask | Python Backend |
| Cargo.toml | Rust Application |
| go.mod | Go Application |
| pom.xml | Java/Maven Project |
| Gemfile | Ruby/Rails Project |

### 3B.6 Special Cases

**Git Repository with Remote:**
```bash
# If it's a git repo with remote, use remote URL as source
git_url=$(cd "$absolute_path" && git remote get-url origin 2>/dev/null)

# Extract owner/repo from git remote
if [[ $git_url =~ github\.com[:/]([^/]+)/([^/\.]+) ]]; then
    owner="${BASH_REMATCH[1]}"
    repo="${BASH_REMATCH[2]}"
    source="git"
fi
```

**Monorepo Structure:**
```bash
# Detect monorepo (multiple package.json or workspaces)
if [ -f "$absolute_path/package.json" ] && [ -f "$absolute_path/package-lock.json" ]; then
    workspaces=$(grep -o '"workspaces": \[.*\]' "$absolute_path/package.json")
    if [ -n "$workspaces" ]; then
        project_type="Monorepo"
    fi
fi
```

### 3B.7 Performance Considerations

For local large repositories:

1. **Limit file listing depth**:
   ```bash
   find "$absolute_path" -maxdepth 2 -type d
   ```

2. **Prioritize documentation**:
   - Focus on README, docs/ directory
   - Skip node_modules/, .git/, build/, dist/

3. **Use sampling**:
   - Sample first 20 files from src/
   - Extract key config files only

### 3B.8 Error Handling

**Invalid Directory:**
```
❌ Unable to access local directory: {path}

Possible reasons:
- Directory doesn't exist
- No read permissions
- Path contains invalid characters

Suggestions:
1. Check the path is correct
2. Verify you have read permissions
3. Try using absolute path
```

**No Project Files:**
```
⚠️ No recognizable project files found in {path}

Expected files (one or more of):
- README.md
- package.json / requirements.txt / Cargo.toml
- go.mod / pom.xml

Falling back to basic analysis...
```

**Large Directory Warning:**
```
⚠️ Large directory detected ({file_count} files)

Analysis may take longer. Continue? (y/n)
```

---

## Step 4: Retry and Mirror Rotation Logic

### Retry Strategy

For each API call:
1. Try primary mirror
2. If failed (403, 429, timeout), try next mirror
3. Use exponential backoff: 1s, 2s, 4s, 8s
4. Max 5 retries per mirror
5. If all mirrors fail, inform user and suggest:
   - Check internet connection
   - Try using VPN
   - Verify repository exists

### Error Handling

- **404**: Repository not found - ask user to verify
- **403/429**: Rate limit - switch mirrors, wait, retry
- **Timeout**: Network issue - try next mirror
- **Empty response**: Mirror issues - try next

---

## Step 5: Analyze Repository

After fetching all data, analyze using your LLM capabilities:

### Extract Information

1. **Project Overview**
   - Purpose and target users
   - Key features
   - Primary language

2. **Installation**
   - Prerequisites (Node.js, Python, etc.)
   - Installation commands (npm install, pip install, etc.)
   - Setup steps

3. **Usage**
   - Quick start example
   - Common tasks
   - Code examples

4. **API Reference** (if applicable)
   - Main endpoints
   - Key functions
   - Parameters and return types

5. **Configuration**
   - Environment variables
   - Configuration files
   - Default settings

6. **Development**
   - Architecture
   - Running tests
   - Contributing

7. **Troubleshooting**
   - Common issues
   - Solutions

---

## Step 6: Generate SKILL.md

Generate complete skill file with this structure:

```yaml
---
name: {sanitized-repo-name}-skill
description: {project summary}
author: auto-generated by repo2skill
platform: {github|gitlab|gitee}
source: {repo-url}
tags: [{extracted-tags}]
version: 1.0.0
generated: {current-iso-timestamp}
---

# {Repo Name} OpenCode Skill

[Comprehensive sections generated from analysis]

## Quick Start

[Installation and basic usage]

## Overview

[Project description]

## Features

[Key features list]

## Installation

[Detailed installation guide]

## Usage

[Usage guide with examples]

## API Reference (if applicable)

[API documentation]

## Configuration

[Settings and options]

## Development

[Development guide]

## Troubleshooting

[FAQ and solutions]

## Resources

[Links and references]
```

### Section Guidelines

Each section should be:
- **Comprehensive**: Cover all aspects
- **Practical**: Include real examples
- **Actionable**: Step-by-step instructions
- **Well-structured**: Use headers, code blocks, lists

---

## Step 7: Installation Path Options

After generating the skill, ask user where to save:

**Option 1: Project Local**
```bash
./.opencode/skills/{skill-name}/SKILL.md
```
Available only in current project

**Option 2: Global User**
```bash
~/.config/opencode/skills/{skill-name}/SKILL.md
```
Available in all projects (OpenCode)

**Option 3: Claude Compatible**
```bash
~/.claude/skills/{skill-name}/SKILL.md
```
Works with OpenCode and Claude Code

Present options and let user choose by number or name.

---

## Step 8: Write File

After user selects location:

1. Create directory structure
2. Write SKILL.md file
3. Confirm success
4. Show what was created

Example:
```
✅ Skill successfully created!

Location: ~/.config/opencode/skills/nextjs-skill/SKILL.md

Generated sections:
- Overview
- Installation (npm, yarn, pnpm)
- Usage Guide
- API Reference
- Configuration
- Development
- FAQ

Total lines: 450

The skill is now ready to use! 🎉
```

---

## Batch Conversion

If user provides multiple repositories:

```
帮我转换这几个仓库:
- https://github.com/vercel/next.js
- https://github.com/facebook/react
```

**Process:**

1. Accept all URLs
2. Process sequentially or in parallel (your choice)
3. For each repo, follow Steps 1-8
4. Generate each skill to same or different location (ask user)
5. Report overall results

Example output:
```
📦 Repository Conversion Results

✅ vercel/next.js → nextjs-skill
   Location: ~/.config/opencode/skills/nextjs-skill/SKILL.md
   File size: 18KB
   
✅ facebook/react → react-skill
   Location: ~/.config/opencode/skills/react-skill/SKILL.md
   File size: 15KB

Total: 2 repositories converted
Time: 3 minutes 15 seconds
```

---

## Error Handling

### If Repository Not Accessible

```
❌ Unable to access repository: {url}

Possible reasons:
- Repository doesn't exist
- Repository is private (need GITHUB_TOKENS env var)
- Network issues (all mirrors failed)
- Rate limit exceeded

Suggestions:
1. Verify the URL is correct
2. Check if repository is public
3. Try accessing in browser
4. Wait a few minutes and retry
```

### If README Missing

```
⚠️ No README found for {repo}

Falling back to file structure analysis...
✅ Generated skill based on code structure
Note: Documentation may be limited
```

### If LLM Analysis Fails

```
❌ Unable to analyze repository content

Error: {error message}

Fallback: Generating basic template with extracted metadata
```

---

## Tool Usage

Use these built-in

Related Skills

writing-skills

14
from jay6697117/cx-switch

Use when creating new skills, editing existing skills, or verifying skills work before deployment

writing-plans

14
from jay6697117/cx-switch

Use when you have a spec or requirements for a multi-step task, before touching code

web-design-guidelines

14
from jay6697117/cx-switch

Review UI code for Web Interface Guidelines compliance. Use when asked to "review my UI", "check accessibility", "audit design", "review UX", or "check my site against best practices".

vue-best-practices

14
from jay6697117/cx-switch

MUST be used for Vue.js tasks. Strongly recommends Composition API with `<script setup>` and TypeScript as the standard approach. Covers Vue 3, SSR, Volar, vue-tsc. Load for any Vue, .vue files, Vue Router, Pinia, or Vite with Vue work. ALWAYS use Composition API unless the project explicitly requires Options API.

verification-before-completion

14
from jay6697117/cx-switch

Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always

vercel-react-best-practices

14
from jay6697117/cx-switch

React and Next.js performance optimization guidelines from Vercel Engineering. This skill should be used when writing, reviewing, or refactoring React/Next.js code to ensure optimal performance patterns. Triggers on tasks involving React components, Next.js pages, data fetching, bundle optimization, or performance improvements.

using-superpowers

14
from jay6697117/cx-switch

Use when starting any conversation - establishes how to find and use skills, requiring Skill tool invocation before ANY response including clarifying questions

using-git-worktrees

14
from jay6697117/cx-switch

Use when starting feature work that needs isolation from current workspace or before executing implementation plans - creates isolated git worktrees with smart directory selection and safety verification

ui-ux-pro-max

14
from jay6697117/cx-switch

UI/UX design intelligence. 50 styles, 21 palettes, 50 font pairings, 20 charts, 9 stacks (React, Next.js, Vue, Svelte, SwiftUI, React Native, Flutter, Tailwind, shadcn/ui). Actions: plan, build, create, design, implement, review, fix, improve, optimize, enhance, refactor, check UI/UX code. Projects: website, landing page, dashboard, admin panel, e-commerce, SaaS, portfolio, blog, mobile app, .html, .tsx, .vue, .svelte. Elements: button, modal, navbar, sidebar, card, table, form, chart. Styles: glassmorphism, claymorphism, minimalism, brutalism, neumorphism, bento grid, dark mode, responsive, skeuomorphism, flat design. Topics: color palette, accessibility, animation, layout, typography, font pairing, spacing, hover, shadow, gradient. Integrations: shadcn/ui MCP for component search and examples.

test-driven-development

14
from jay6697117/cx-switch

Use when implementing any feature or bugfix, before writing implementation code

systematic-debugging

14
from jay6697117/cx-switch

Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes

subagent-driven-development

14
from jay6697117/cx-switch

Use when executing implementation plans with independent tasks in the current session