ワンクリックでManusで任意のスキルを実行

始める

project-index-reader-v2

スター3

フォーク1

更新日2026年5月16日 11:48

当用户要求分析仓库、生成技术文档或学习某个项目实现时，从 .claude/repo/ 仓库中读取源码并生成结构化技术文档。禁止立即编码。此 skill 仅适用于 .claude/repo/ 下的仓库。

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

Manusで実行

ソース

ZHLX2005

ZHLX2005/sl

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

Manusで実行

仓库源码阅读与技术文档生成器

核心原则

先读索引，再挖源码，后出文档。生成文档前必须先从源码中提取具体证据。

所有对话必须按照知识主题进行md文档的落盘

工作流程

Step 1: 定位目标仓库

在 .claude/repo/ 下查找用户要求的项目：

ls .claude/repo/

若仓库不存在，提示用户先通过 /mmx-research-gitclone 克隆。

Step 2: 扫描仓库索引

读取目标仓库的 PROJECT_INDEX.md 快速了解整体结构：

Read: .claude/repo/<仓库名>/PROJECT_INDEX.md

提取关键信息：

项目定位与核心功能
主要包/模块划分
入口文件位置
技术栈

Step 3: 规划文档结构

根据仓库类型和用户需求，自由决定需要生成的文档主题和数量。一个仓库可生成多份文档，不局限于一份。

输出位置（强制）：

.claude/repo/_read/<仓库名>/<文档主题>/<文档文件名>.md

例如：

.claude/repo/_read/happy/架构总览/01-项目架构与模块关系.md
.claude/repo/_read/happy/核心模块/happy-cli-入口与命令解析.md
.claude/repo/_read/happy/核心模块/happy-server-API与路由设计.md
.claude/repo/_read/happy/数据流/端到端加密同步机制.md

规划原则：

结合用户问题和仓库特点确定分析角度，不要套用固定模板
大型仓库（>5个包）至少拆分为 2-3 个主题目录
小型仓库可集中在一个主题下
主题目录名使用中文，文件编号用于排序

Step 4: 深入源码提取证据

真实性铁律：文档中的每一句话都必须能在源码中找到对应证据。禁止推断、猜测、编造。

挖掘方式：

# 读取核心入口文件
Read: .claude/repo/<仓库名>/<入口文件>

# 搜索关键接口定义
Grep: interface|type|class|struct|func.*\(.*\).*

# 搜索方法签名
Grep: func \w+|function \w+|method \w+|async \w+

# 读取关键数据结构
Read: .claude/repo/<仓库名>/<核心数据定义文件>

证据引用格式（强制）：

所有涉及源码的描述必须包含：

文件路径（相对于仓库根目录）
行号范围（如 :23 或 :45-67）
原始代码片段

- `AuthService` 接口定义了认证核心方法：
  ```typescript
  // 来源: packages/auth/src/service.ts:23-29
  interface AuthService {
    authenticate(credentials: Credentials): Promise<AuthResult>;
    refreshToken(token: string): Promise<string>;
  }


**禁止行为**：
- 描述一个接口但不提供源码位置和代码片段
- 声称"项目使用了 X 设计模式"而不引用体现该模式的源码
- 描述函数行为但不引用函数体或签名
- 对未读到的文件做任何假设性描述

**追溯原则**：如果读者对文档中的某个结论有疑问，应该能根据文档中给出的文件路径和行号，直接定位到源码并验证。

### Step 5: 生成技术文档

**输出目录（强制）**：`.claude/repo/_read/<仓库名>/<文档主题>/`

生成前必须确保目标目录已创建：
```bash
mkdir -p .claude/repo/_read/<仓库名>/<文档主题>

文档撰写原则：

中文撰写：全文使用中文
源码证据优先（强制）：涉及接口、类型、函数时，必须引用源码中的具体定义（含文件路径和行号范围）。没有源码证据的结论不得写入文档
真实可追溯：文档中的每一句话都应该能让读者根据给出的文件路径和行号，在源码中找到对应内容并验证。禁止推断、猜测、编造
自由分析：结合用户需求和仓库特点进行分析，不套用固定模板。可以包含架构分析、数据流追踪、设计决策评价、核心算法解释等——但所有分析结论都必须有源码支撑
结构化：使用 Markdown 标题层级组织，但具体结构由分析角度决定

示例输出路径：

.claude/repo/_read/happy/架构总览/01-项目架构与模块关系.md
.claude/repo/_read/happy/核心模块/happy-cli-入口与命令解析.md
.claude/repo/_read/happy/核心模块/happy-server-API与路由设计.md
.claude/repo/_read/happy/数据流/端到端加密同步机制.md

Step 6: 验证与汇总

生成完成后必须执行以下验证：

验证输出位置：确认文件确实存在于 .claude/repo/_read/<仓库名>/<文档主题>/ 下，不是仓库根目录，也不是其他位置
检查源码引用：每个涉及接口/类型/函数的结论都有源码依据
汇总汇报：向用户列出所有生成的文档路径

验证命令：

find .claude/repo/_read/<仓库名>/ -type f -name "*.md" | sort

寻找指令速查

# 列出所有仓库
Bash: ls .claude/repo/

# 读取索引
Read: .claude/repo/<repo>/PROJECT_INDEX.md

# 搜索接口/类型
Grep: ^\s*(interface|type|struct|class)\s+\w+

# 搜索函数定义
Grep: ^\s*(func|function|def|async)\s+\w+

# 读取特定文件
Read: .claude/repo/<repo>/<path>

适用场景

✅ 分析开源项目实现细节 ✅ 为团队生成技术参考文档 ✅ 学习特定技术方案的内部机制 ✅ 提取接口设计作为新项目的参考

❌ 简单文件操作 ❌ 用户已指定单个文件 ❌ 不依赖源码的通用性说明

このリポジトリの他の Skills

同じリポジトリ

intent-capture

ZHLX2005/sl

当用户希望整理需求、明确目的、描述问题，或要求"生成文档"、"整理意图"、"明确现象"时触发。用于通过多轮对话收集和整理需求，不执行任何代码修改。

2026-07-253

boot-work-flow

ZHLX2005/sl

当用户说 "boot work-flow"、"初始化 work-flow"、"为这个仓库创建 work-flow skill"、"创建 <仓库名>-work-flow" 时触发。这是一个元skill：自动检测 git 仓库名 → 在项目本地创建 <repo>-work-flow skill → 仅写入项目启动方法和启动信息作为最小骨架 → 标注后续通过 /key_board_3 添加 references 增强。

2026-07-213

git-repo-cleanup

ZHLX2005/sl

清理git嵌套仓库，保持仓库隔离性，让 git add . 干净无污染。适用于 .claude/repo/ 或其他包含克隆仓库的目录。当用户提到"清理git"、"处理嵌套仓库"、"git隔离"、"保持干净"、 "部分跟踪"、"白名单子目录"、"忽略但保留子目录"、"gitignore 否定规则"、 "忽略 .tool/"、"工具目录不入库"时触发。

2026-07-213

key-board-2

ZHLX2005/sl

当用户要求"总结成skill"、"保存对话为skill"、"提取提示词"、"做成技能"时触发。这是元技能模板，用于指导创建其他技能，而非被创建的技能本身。

2026-07-213

key-board-3

ZHLX2005/sl

当用户要求"拆分到references"、"给skill加ref引导"、"把xx沉淀为reference"、"优化skill结构"、"重构skill"、"skill膨胀了"、"合并skill"、或要求"探索/扫描现有skill看哪些可合并"时触发。本 skill 专用于按主题把已有 skill 组织成渐进式指导文档——主 SKILL.md 承担主干主题、references/ 承担特化专项的特化指导，整个 skill 包高内聚、单文档承担一个主题；长度只是边缘参考。不创建新 skill、不改变前置 skill (key_board / key_board_2) 的职责。探索模式详见 [[场景E-合并审计]]。

2026-07-163

codebase-optimizer

ZHLX2005/sl

阅读任意代码库目录（不限语言/框架），分析模块与代码结构，生成防腐蚀规范 SKILL.md、更新已有 skill 使其与代码库一致、或在使用 skill 后反思同步项目经验。覆盖"创建"、"同步"、"反思"三个场景。不生成孤儿文档。

2026-07-123

name	project-index-reader-v2
description	当用户要求分析仓库、生成技术文档或学习某个项目实现时，从 .claude/repo/ 仓库中读取源码并生成结构化技术文档。禁止立即编码。此 skill 仅适用于 .claude/repo/ 下的仓库。
version	2.0.0

仓库源码阅读与技术文档生成器

核心原则

先读索引，再挖源码，后出文档。生成文档前必须先从源码中提取具体证据。

所有对话必须按照知识主题进行md文档的落盘

工作流程

Step 1: 定位目标仓库

在 .claude/repo/ 下查找用户要求的项目：

ls .claude/repo/

若仓库不存在，提示用户先通过 /mmx-research-gitclone 克隆。

Step 2: 扫描仓库索引

读取目标仓库的 PROJECT_INDEX.md 快速了解整体结构：

Read: .claude/repo/<仓库名>/PROJECT_INDEX.md

提取关键信息：

项目定位与核心功能
主要包/模块划分
入口文件位置
技术栈

Step 3: 规划文档结构

根据仓库类型和用户需求，自由决定需要生成的文档主题和数量。一个仓库可生成多份文档，不局限于一份。

输出位置（强制）：

.claude/repo/_read/<仓库名>/<文档主题>/<文档文件名>.md

例如：

.claude/repo/_read/happy/架构总览/01-项目架构与模块关系.md
.claude/repo/_read/happy/核心模块/happy-cli-入口与命令解析.md
.claude/repo/_read/happy/核心模块/happy-server-API与路由设计.md
.claude/repo/_read/happy/数据流/端到端加密同步机制.md

规划原则：

结合用户问题和仓库特点确定分析角度，不要套用固定模板
大型仓库（>5个包）至少拆分为 2-3 个主题目录
小型仓库可集中在一个主题下
主题目录名使用中文，文件编号用于排序

Step 4: 深入源码提取证据

真实性铁律：文档中的每一句话都必须能在源码中找到对应证据。禁止推断、猜测、编造。

挖掘方式：

# 读取核心入口文件
Read: .claude/repo/<仓库名>/<入口文件>

# 搜索关键接口定义
Grep: interface|type|class|struct|func.*\(.*\).*

# 搜索方法签名
Grep: func \w+|function \w+|method \w+|async \w+

# 读取关键数据结构
Read: .claude/repo/<仓库名>/<核心数据定义文件>

证据引用格式（强制）：

所有涉及源码的描述必须包含：

文件路径（相对于仓库根目录）
行号范围（如 :23 或 :45-67）
原始代码片段

- `AuthService` 接口定义了认证核心方法：
  ```typescript
  // 来源: packages/auth/src/service.ts:23-29
  interface AuthService {
    authenticate(credentials: Credentials): Promise<AuthResult>;
    refreshToken(token: string): Promise<string>;
  }


**禁止行为**：
- 描述一个接口但不提供源码位置和代码片段
- 声称"项目使用了 X 设计模式"而不引用体现该模式的源码
- 描述函数行为但不引用函数体或签名
- 对未读到的文件做任何假设性描述

**追溯原则**：如果读者对文档中的某个结论有疑问，应该能根据文档中给出的文件路径和行号，直接定位到源码并验证。

### Step 5: 生成技术文档

**输出目录（强制）**：`.claude/repo/_read/<仓库名>/<文档主题>/`

生成前必须确保目标目录已创建：
```bash
mkdir -p .claude/repo/_read/<仓库名>/<文档主题>

文档撰写原则：

中文撰写：全文使用中文
源码证据优先（强制）：涉及接口、类型、函数时，必须引用源码中的具体定义（含文件路径和行号范围）。没有源码证据的结论不得写入文档
真实可追溯：文档中的每一句话都应该能让读者根据给出的文件路径和行号，在源码中找到对应内容并验证。禁止推断、猜测、编造
自由分析：结合用户需求和仓库特点进行分析，不套用固定模板。可以包含架构分析、数据流追踪、设计决策评价、核心算法解释等——但所有分析结论都必须有源码支撑
结构化：使用 Markdown 标题层级组织，但具体结构由分析角度决定

示例输出路径：

.claude/repo/_read/happy/架构总览/01-项目架构与模块关系.md
.claude/repo/_read/happy/核心模块/happy-cli-入口与命令解析.md
.claude/repo/_read/happy/核心模块/happy-server-API与路由设计.md
.claude/repo/_read/happy/数据流/端到端加密同步机制.md

Step 6: 验证与汇总

生成完成后必须执行以下验证：

验证输出位置：确认文件确实存在于 .claude/repo/_read/<仓库名>/<文档主题>/ 下，不是仓库根目录，也不是其他位置
检查源码引用：每个涉及接口/类型/函数的结论都有源码依据
汇总汇报：向用户列出所有生成的文档路径

验证命令：

find .claude/repo/_read/<仓库名>/ -type f -name "*.md" | sort

寻找指令速查

# 列出所有仓库
Bash: ls .claude/repo/

# 读取索引
Read: .claude/repo/<repo>/PROJECT_INDEX.md

# 搜索接口/类型
Grep: ^\s*(interface|type|struct|class)\s+\w+

# 搜索函数定义
Grep: ^\s*(func|function|def|async)\s+\w+

# 读取特定文件
Read: .claude/repo/<repo>/<path>

适用场景

✅ 分析开源项目实现细节 ✅ 为团队生成技术参考文档 ✅ 学习特定技术方案的内部机制 ✅ 提取接口设计作为新项目的参考

❌ 简单文件操作 ❌ 用户已指定单个文件 ❌ 不依赖源码的通用性说明