# Analyze Repo

> 分析开源项目，找到可完成的PR方向

- Skill: `advancedcat/analyze-repo` (Agent Skill)
- Install (CLI): `npx skillmds@latest add advancedcat/analyze-repo`
- Raw SKILL.md: https://api.skillmd.com/api/skills/advancedcat/analyze-repo/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: AdvancedCat (https://skillmd.com/u/advancedcat)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/advancedcat/analyze-repo

---



# 开源项目共享分析

## 项目信息

Github地址： {REPO_URL}
我的目标： 找到 1～3 个可以在2周内完成、且能在面试系统讲述的PR方向

---

## 准备工作（请先执行）

阅读以下文件以建立项目理解，文件不存在则跳过：

- README.md
- CONTRIBUTING.md
- CHANGELOG.md / HISTORY.md
- 项目主入口文件(main.py / index.ts / app.py等)

然后输出目录结构（depth=3），标注你认为的核心模块目录，并用 2～3句话描述：这个项目的核心 Agent 循环是什么？使用哪种规则范式？

---

## 分析维度一： Issue 列表筛选

访问 {REPO_URL}/issues，筛选出符合以下**全部条件**的 Issue：
**筛选条件**

- 标签包含 `good first issue`、`help wanted`、`bug`、`enhancement` 之一
- 状态为 open， 进60天内有过活动（非 stale）
- 无人认领（无 assignee）
- 描述清晰，有明确的期望行为或可复现步骤
- 所需改动范围在 1～3 个文件内，不涉及整体架构重构

**输出格式**
|Issue #|标题|类型|所需技能|预估工作量|推荐理由|

---

## 分析维度二： 架构层缺陷分析

深入阅读代码，逐一检查以下7个维度。
**每个维度必须定位到具体文件和函数，禁止泛泛而谈**

---

### 1. 任务规划（Task Planning）

分析项目当前使用的规划范式（ReAct 、 Plan-and-Execute / CoT / 无显式范式）

重点检查

- 任务能够被分解为子任务？有无显式的 Plan 生成步骤？
- 子任务执行失败时，是否有动态重规划机制，还是直接报错退出？
- 规划结果是否可被持久化，以支持断点续跑？
- 若项目完全没有规划层，直接依赖 LLM 单步决策，是否存在引入规划层的空间？

---

### 2. 多 Agent 协作

分析项目的 Agent 拓扑结构。

重点检查

- 当前是单 Agent 还是多 Agent 协作？
- 若是单 Agent，是否存在天然适合拆分为 Orchestrator + Worker 结构的场景？
- 若是多 Agent 协作，通信协议是什么？角色职责是否清晰？结果聚合策略是否合理？
- Agent之间是否存在状态共享机制，还是完全无状态的串行调用？

### 3. 上下文管理（Context Management）

分析项目如何处理长对话和token限制问题

重点检查

- 当context接近模型token上限时，策略是什么（硬截断 / 滚动窗口 / 摘要压缩）
- 压缩或截断策略是否丢失关键的工具调用历史或中间结果？
- 跨轮次的对话历史如何存储和读取？是否存在冗余或浪费？
- 是否存在针对不同类型消息（系统指令、工具结果、对话历史）的差异化管理策略？

---

### 4. Human-in-the-Loop机制

分析项目是否引入了 Human-in-the-Loop 机制，以支持复杂任务的执行。
重点检查

- 遇到低置信度决策或高风险（文件写入、外部API调用、消息发送等）时，是否有暂停并等待人工确认的机制？
- 是否有 Checkpoint 机制，支持 Agent 执行中断后从断点恢复？
- 人工介入后，Agent 能否将人的反馈融入后续决策，还是从头再来？

---

### 5. Agent 评估框架（Evaluation）

分析项目是否具备系统评估 Agent 表现的能力

重点检查

- 是否有 eval 模块或测试集？评估粒度是只看最终结果，还是追踪完整trace？
- 是否集成了外部评估工具（LangSmith、Arize、自定义pipeline）？
- 工具调用的选择是否正确、参数是否合理，有没有被量化追踪？
- 若完全没有评估机制，引入最小可用 eval pipeline 的改造成本是多少？

---

### 6. Tool 检索与路由（Tool Retrieval）

分析项目的工具管理和选择机制

重点检查

- 当前是全量工具注入（所有tool schema塞入system prompt）还是按需检索？
- 若工具超过20个，是否有向量化检索机制按任务动态选择相关子集？
- 工具的描述质量如何？是否存在语义相似导致 LLM 选择混乱的问题？
- 是否支持 MCP 协议？若不支持，现有 tool 层是否有接入 MCP 的改造空间？

---

### 7. Streaming 与中间状态可见性

分析Agent执行过程的实时可见性。

重点检查

- 是否支持流式输出（streaming token by token）？
- Agent 的中间状态（当前在执行哪个子任务、调用了什么工具、参数是什么）是否对外状态广播？
- 是否有事件、状态订阅接口，供前端实时展示 Agent 执行进度？
- 如果缺失，现有架构是否支持以低侵入方式引入 straming 和状态广播？

---

### 每个维度的输出格式

**现状描述**： **（定位到具体文件路径 + 函数名）**
**缺陷 / 缺失**： **（当前方案存在什么问题，或完全缺失）**
**影响程度**： **high / medium / low**
**改进方向**：**（1～3 句话，描述可行的改造方案）**
**改动范围**：**（预计涉及文件数和代码行量级）**
**面试叙事角度？**：**（用一句话说明，这个贡献在面试中能体现什么能力）**

---

## 最终输出：Top3 贡献建议

**第 N 名：{PR方向名称}**

- 一句话描述
- 来源维度：Issue #xxxx / 代码分析-维度X
- 入口文件：
- 为什么适合我：（描述这个方向对我的目标有什么帮助）
- 预计工作量：小，中，大
- 面试中能讲什么：（描述这个方向在面试中能体现什么能力）
- 风险点：（可能遇到的阻力或依赖）