---
name: repo-explorer
description: Use this skill when the user asks to explore a repository, get familiar with a project, "repo explorer", "tell me about this repo", "repo-explorer", "what does this repository do", or wants an overview of a Gitee repository. Requires Gitee MCP Server to be configured.
version: 1.0.0
requires:
  mcp-servers:
    - gitee
---

> **Note**: If you have `mcporter` installed locally, you should use `mcporter` to invoke the MCP tool instead of directly calling the MCP tool. The `mcporter` CLI provides a more convenient interface and better error handling.

# Repo Explorer via Gitee MCP

Quickly explore the structure and core content of a Gitee repository and generate an overview report to help get up to speed on an unfamiliar project.

## Prerequisites

- Gitee MCP Server configured (tools: `get_file_content`, `search_files_by_content`, `list_user_repos`)
- User must provide: repository owner, repository name
- Optional: specific area of interest (e.g., "I want to understand the authentication mechanism")

## Steps

### Step 1: Fetch Key Documentation

Start by reading these files using `get_file_content`:

1. `README.md` or `README_CN.md`: project introduction
2. `CONTRIBUTING.md`: contribution guide (development conventions)
3. `CHANGELOG.md`: change history (evolution of the project)
4. `package.json` / `go.mod` / `pom.xml` / `requirements.txt`: tech stack and dependencies

### Step 2: Explore Project Structure

First, use `get_file_content` with `path="/"` to get the root directory tree:

```
get_file_content(owner="[owner]", repo="[repo]", path="/")
```

This returns the top-level directory structure in a single call, providing a quick overview of the project's layout.

Then, browse key subdirectories to identify:

**Common project structure patterns**
- `src/` or `lib/`: core source code
- `cmd/` or `bin/`: CLI entry points (Go / C++ projects)
- `api/` or `routes/`: API definitions
- `tests/` or `test/`: test code
- `docs/`: detailed documentation
- `scripts/` or `.gitee/` or `.github/`: build / CI scripts
- `config/` or `configs/`: configuration files

### Step 3: Analyze Core Code

Based on the project type, read key files in depth:

**Web application**
- Entry file (main.go / index.js / app.py)
- Route definition files
- Database schema or model definitions

**Library / SDK**
- Main entry file (public API entry point)
- Core algorithm files

**CLI tool**
- Command definition files
- Configuration handling logic

Use `search_files_by_content` to locate core logic:
- Search for `main`, `init`, `Router`, etc.
- Search for specific keywords matching the user's area of interest

### Step 4: Generate Repository Overview Report

```
# Repository Overview: [owner/repo]

## About
[One-paragraph description summarizing the project based on the README]

## Tech Stack
- **Language**: [primary language]
- **Framework**: [main framework]
- **Storage**: [database / cache]
- **Deployment**: [Docker / K8s / other]

## Directory Structure
[Key directory annotations]
├── src/          # Core source code
├── api/          # API definitions
├── tests/        # Tests
└── docs/         # Documentation

## Core Modules
| Module | Path | Responsibility |
|--------|------|---------------|
| [name] | [path] | [one-sentence description] |

## Data Models (if applicable)
[Main entities and their relationships]

## Getting Started
[Setup steps extracted from README / CONTRIBUTING]

\`\`\`bash
# Install dependencies
[command]

# Start the project
[command]
\`\`\`

## Contribution Highlights
[Key conventions from CONTRIBUTING.md]

## Recent Activity
[Latest version highlights from CHANGELOG or README]
```

### Step 5: Deep Dive (optional)

If the user has a specific area of interest, use `search_files_by_content` for targeted searches:
- Authentication: search `auth`, `token`, `permission`
- Database operations: search `SELECT`, `INSERT`, `Model`
- Configuration: search `config`, `env`, `ENV`

## Notes

- Prefer smaller files when reading; avoid loading very large files all at once
- Keep the report focused and concise — do not try to cover everything
- If the project has no README, infer its purpose from the code structure and comments