Repo Analysis

---

name: repo-analysis

description: "Read, explain, and evaluate a software repository or GitHub project in an engineering-oriented way. Use when the user asks to read a repo, understand a codebase, analyze architecture, evaluate whether a project is worth following or adopting, prepare onboarding notes, or summarize stack, module boundaries, risks, and entry points. Supports three output modes: 速读版, 架构版, and 接手评审版. Also supports a lightweight GitHub health layer for public repositories when the user asks whether a project is worth following, adopting, or referencing. Triggers include requests like 读一下这个项目, 看看这个 GitHub 仓库, 分析一下 repo, 这个项目怎么样, 帮我快速理解代码结构, 给我一个架构分析, or 给我一个接手评审."

---

# Repo Analysis

Overview

Use this skill to turn an unfamiliar repository into a concrete engineering assessment.

The goal is not to restate the README, but to identify what the project is, how it is structured, how it runs, where the main boundaries are, and what risks or follow-up questions matter.

Default mindset:

Output modes

Choose one mode as early as possible.

If the user does not specify, choose the lightest mode that still answers the request.

Prefer explicit user choice over automatic detection.

Mode 1: 速读版

Use when the user wants a fast understanding.

Typical asks:

Goal:

Depth:

Expected output size:

Mode 2: 架构版

Use when the user wants system structure, runtime flow, or design analysis.

Typical asks:

Goal:

Depth:

Expected output size:

Mode 3: 接手评审版

Use when the user wants adoption, maintenance, or takeover judgment.

Typical asks:

Goal:

Depth:

Expected output size:

Automatic mode selection

When the user does not explicitly choose a mode, infer it from intent.

Default to 速读版

Use 速读版 when the user says things like:

Behavior:

Default to 架构版

Use 架构版 when the user says things like:

Behavior:

Default to 接手评审版

Use 接手评审版 when the user says things like:

Behavior:

Explicit override wins

If the user explicitly asks for:

Then use that mode directly, even if other phrasing suggests something else.

Mixed requests

If the user mixes intents, choose a primary mode and keep the rest lightweight.

Example:

- primary mode: 速读版

- secondary: add a short takeover judgment

If both parts are clearly important, say which mode you are using first and note what is being kept brief.

Default workflow

Follow this order unless the user asks for a narrower slice.

1. Clarify the analysis target

2. Choose output mode

3. Scan repository shape and stack

4. Read the minimum set of high-signal files

5. Map architecture and runtime flow as needed

6. Judge health, risks, and adoption cost as needed

7. Output a structured engineering summary

Keep the investigation evidence-based. Prefer direct repo evidence over guesswork.

Use a simple evidence ladder when reporting:

1. Clarify the analysis target

First determine which of these the user actually wants:

Also determine the target scope as early as possible:

Call out the scope explicitly in the answer when it materially affects depth.

Examples:

If the request is broad and you can proceed safely, default to:

2. Scan repository shape and stack

Start broad, then narrow.

Collect these first:

Questions to answer early:

3. Read the minimum high-signal files

Do not read everything. Read the smallest set that explains the system.

Priority order:

1. Root `README*`

2. Service/module README files

3. Stack manifests (`package.json`, `pyproject.toml`, etc.)

4. Main entry points (`main.*`, `index.*`, router/bootstrap files)

5. Architecture or deployment docs

6. A few core service files that reveal control flow

Use these patterns to find entry points:

4. Map architecture and runtime flow

Build an internal map of the project using these lenses.

A. Product boundary

B. Module boundary

Identify the major modules and what each owns.

Good output shape:

C. Execution path

Trace one or two important paths end to end.

Examples:

D. Data and control points

Look for:

E. Operating complexity

Check whether the project includes:

These areas usually dominate maintenance cost.

5. Judge health, risks, and adoption cost

Evaluate with engineering judgment, not marketing language.

Health signals

Look for:

Risk signals

Look for:

Adoption / takeover cost

Comment on:

Optional GitHub enhancement

When the target is a public GitHub repository and the user wants evaluation, not just code reading, optionally add a lightweight GitHub health layer.

Use it when the user asks things like:

Keep it lightweight. Only add the signals that materially help engineering judgment:

Do **not** turn the answer into a market report or community roundup by default.

Treat this as an enhancement layer. Do not let external hype replace code-level judgment.

6. Mode-specific output templates

Use the template that matches the chosen mode.

A. 速读版

Use this when speed matters more than depth.

#### 问题判断

#### 原因分析

#### 快速结论

如果目标是公共 GitHub 仓库，且用户明显在问“值不值得看 / 跟 / 用”，可额外补一个短块：

控制规则：

#### 阅读建议

#### 验证方式

B. 架构版

Use this when structure and flow matter most.

#### 问题判断

#### 原因分析

#### 架构拆解

#### 结论

#### 阅读建议

#### 验证方式

C. 接手评审版

Use this when the user wants engineering judgment for takeover or adoption.

#### 问题判断

#### 原因分析

#### 接手评审结论

如果目标是公共 GitHub 仓库，且用户明显在问是否采用，可额外补一个短块：

#### 建议方案

#### 验证方式

Output quality rules

Always:

Never:

Suggested investigation checklist

Use this as a lightweight checklist, not a rigid form.

Reference files

Read these only when needed: