gh-code-search

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

GitHub Code Search

GitHub代码搜索

Fetch real-world code examples from GitHub through intelligent multi-search orchestration.

通过智能多搜索编排从GitHub获取真实场景的代码示例。

Prerequisites

前置条件

Required:

gh CLI installed and authenticated (
```
gh auth login --web
```
)
Node.js + pnpm

Validation:

bash

gh auth status  # Should show authenticated

必需项：

已安装并完成认证的gh CLI（执行
```
gh auth login --web
```
）
Node.js + pnpm

验证步骤：

bash

gh auth status  # 应显示已认证状态

Usage

使用方法

bash

cd plugins/knowledge-work/skills/gh-code-search
pnpm install  # First time only
pnpm search "your query here"

bash

cd plugins/knowledge-work/skills/gh-code-search
pnpm install  # 首次使用时执行
pnpm search "你的查询内容"

When to Use

适用场景

Invoke this skill when user requests:

Real-world examples ("how do people implement X?")
Library usage patterns ("show me examples of workflow.dev usage")
Implementation approaches ("claude code skills doing github search")
Architectural patterns ("repository pattern in TypeScript")
Best practices for specific frameworks/libraries

Examples requiring nuanced multi-search:

"Find React hooks" → Need queries for
```
useState/useEffect
```
(imports),
```
function use
```
(definitions),
```
const use =
```
(arrow functions)
"Express error handling middleware" → Queries for
```
(req, res, next) =>
```
(signatures),
```
app.use
```
(registration),
```
function(err,
```
(error handlers)
"How do people use XState?" → Queries for
```
useMachine
```
,
```
createMachine
```
,
```
interpret
```
(actual function names, not "state machine")
"GitHub Actions for TypeScript projects" → Queries for
```
.yml
```
workflow files +
```
actions/setup-node
```
+
```
tsc
```
or
```
pnpm build
```
(actual commands)

当用户提出以下需求时，调用本技能：

真实场景示例（如“人们是如何实现X功能的？”）
库的使用模式（如“展示workflow.dev的使用示例”）
实现方案（如“Claude代码技能实现GitHub搜索”）
架构模式（如“TypeScript中的仓库模式”）
特定框架/库的最佳实践

需要精细化多搜索的示例：

“查找React hooks” → 需要针对
```
useState/useEffect
```
（导入语句）、
```
function use
```
（定义）、
```
const use =
```
（箭头函数）的查询
“Express错误处理中间件” → 需要针对
```
(req, res, next) =>
```
（签名）、
```
app.use
```
（注册方式）、
```
function(err,
```
（错误处理器）的查询
“人们如何使用XState？” → 需要针对
```
useMachine
```
、
```
createMachine
```
、
```
interpret
```
（实际函数名，而非“state machine”）的查询
“TypeScript项目的GitHub Actions” → 需要针对
```
.yml
```
工作流文件 +
```
actions/setup-node
```
+
```
tsc
```
或
```
pnpm build
```
（实际命令）的查询

How It Works

工作原理

Division of responsibilities:

职责划分：

Script Responsibilities (Tool Implementation)

脚本职责（工具实现）

Authenticates with GitHub (gh CLI token)
Executes single search query (Octokit API, pagination, text-match)
Ranks by quality (stars, recency, code structure)
Fetches top 10 files in parallel
Extracts factual data (imports, syntax patterns, metrics)
Returns clean markdown with code + metadata + GitHub URLs for all files

The script is a single-query tool. Claude orchestrates multiple invocations.

通过GitHub认证（使用gh CLI令牌）
执行单个搜索查询（基于Octokit API，支持分页和文本匹配）
按质量排序（星级、更新时间、代码结构）
并行获取前10个文件
提取事实数据（导入语句、语法模式、指标）
返回包含代码、元数据以及所有文件的GitHub链接的清晰Markdown内容

本脚本是单查询工具，由Claude负责多轮调用的编排。

Claude's Orchestration Responsibilities

Claude的编排职责

Claude executes a multi-phase workflow:

Query Strategy Generation: Craft 3-5 targeted search queries considering:
- Language context (TypeScript vs JavaScript)
- File type nuances (tsx vs ts for React, config files vs implementations)
- Specificity variants (broad → narrow)
- Related terminology expansion
Sequential Search Execution: Run tool multiple times, adapting queries based on intermediate results
Result Aggregation: Combine all code files, deduplicate by repo+path, preserve GitHub URLs
Pattern Analysis: Extract common imports, architectural styles, implementation patterns
Comprehensive Summary: Synthesize findings with trade-offs, recommendations, key code highlights, and GitHub URLs for ALL meaningful files

Claude会执行多阶段工作流：

查询策略生成： 生成3-5个针对性搜索查询，考虑以下因素：
- 语言上下文（TypeScript与JavaScript的区别）
- 文件类型差异（React项目的tsx与ts文件、配置文件与实现文件的区别）
- 特异性变体（从宽泛到精准）
- 相关术语扩展
顺序搜索执行： 多次运行工具，根据中间结果调整查询内容
结果聚合： 合并所有代码文件，按仓库+路径去重，保留GitHub链接
模式分析： 提取通用导入语句、架构风格、实现模式
综合总结： 整合研究结果，包括权衡方案、建议、关键代码亮点，以及所有有意义文件的GitHub链接

Claude's Orchestration Workflow

Claude的编排工作流

Step 1: Analyze Request & Generate Queries (BLOCKING)

步骤1：分析请求并生成查询（阻塞步骤）

Analyze user request to determine:

Primary language/framework (TypeScript, Python, Go, etc.)
Specific patterns sought (hooks, middleware, configs, actions)
File type variations needed (tsx vs ts, yaml vs json)

Generate 3-5 targeted queries considering nuances:

Example 1: "Find React hooks"

Query 1:
```
useState useEffect language:typescript extension:tsx
```
(matches import statements, hook usage in components)

Query 2:

function use language:typescript extension:ts

(matches hook definitions like

function useFetch()

)

Query 3:

const use = language:typescript

(matches arrow function hooks like

const useAuth = () =>

)

Example 2: "Express error handling"

Query 1:
```
(req, res, next) => language:javascript
```
(matches middleware function signatures)
Query 2:
```
app.use express
```
(matches Express middleware registration)
Query 3:
```
function(err, req, res, next) language:javascript
```
(matches error handler signatures with 4 params)

Example 3: "XState state machines in React"

Query 1:

useMachine language:typescript extension:tsx

(matches React hook usage like

const [state, send] = useMachine(machine)

)

Query 2:
```
createMachine language:typescript
```
(matches machine definitions and imports)

Query 3:

interpret xstate language:typescript

(matches service creation like

const service = interpret(machine)

)

Rationale for each query:

Match actual code patterns (function names, import statements, signatures)
NOT human-friendly search terms or documentation phrases
Different file extensions capture different use cases (tsx for components, ts for utilities)
Specific function/variable names find concrete implementations
Signature patterns match common code structures (arrow functions, function declarations)
Language/extension filters prevent noise from unrelated languages

CHECKPOINT: Verify 3-5 queries generated before proceeding

分析用户请求以确定：

主要语言/框架（TypeScript、Python、Go等）
目标特定模式（hooks、中间件、配置、Actions等）
需要的文件类型变体（tsx与ts、yaml与json）

生成3-5个针对性查询，考虑细节差异：

示例1：“查找React hooks”

查询1：
```
useState useEffect language:typescript extension:tsx
```
（匹配导入语句、组件中的hook使用）

查询2：

function use language:typescript extension:ts

（匹配

function useFetch()

这类hook定义）

查询3：
```
const use = language:typescript
```
（匹配
```
const useAuth = () =>
```
这类箭头函数形式的hook）

示例2：“Express错误处理”

查询1：
```
(req, res, next) => language:javascript
```
（匹配中间件函数签名）
查询2：
```
app.use express
```
（匹配Express中间件注册方式）
查询3：
```
function(err, req, res, next) language:javascript
```
（匹配包含4个参数的错误处理器签名）

示例3：“React中的XState状态机”

查询1：

useMachine language:typescript extension:tsx

（匹配

const [state, send] = useMachine(machine)

这类React hook用法）

查询2：
```
createMachine language:typescript
```
（匹配状态机定义与导入语句）

查询3：

interpret xstate language:typescript

（匹配

const service = interpret(machine)

这类服务创建代码）

每个查询的设计依据：

匹配实际代码模式（函数名、导入语句、签名）
不使用友好的人类搜索词或文档短语
不同文件扩展名对应不同使用场景（tsx用于组件，ts用于工具类）
特定函数/变量名能找到具体实现
签名模式匹配常见代码结构（箭头函数、函数声明）
语言/扩展名过滤避免无关语言的干扰

检查点： 确认已生成3-5个查询后再继续

Step 2: Execute Searches Sequentially

步骤2：顺序执行搜索

For each query (in order):

bash

cd plugins/knowledge-work/skills/gh-code-search
pnpm search "query text here"

After each search:

Note result count - Too many? Too few?
Check quality indicators - Stars, recency, code structure scores
Identify patterns - Are results converging on specific approaches?
Adapt next query if needed:
- Too many results → Narrow scope (add more filters)
- Too few results → Broaden (remove restrictive filters)
- Found strong pattern → Search for similar variations

Track which queries succeed - Note for summary which strategies were effective

Early stopping: If first 2-3 queries yield 30+ high-quality results, remaining queries optional

对每个查询（按顺序）执行：

bash

cd plugins/knowledge-work/skills/gh-code-search
pnpm search "查询文本"

每次搜索后：

记录结果数量 - 结果太多？太少？
检查质量指标 - 星级、更新时间、代码结构评分
识别模式 - 结果是否集中于特定实现方案？
按需调整下一个查询：
- 结果太多 → 缩小范围（添加更多过滤条件）
- 结果太少 → 扩大范围（移除限制性过滤条件）
- 发现优质模式 → 搜索类似变体

记录成功的查询 - 在总结中注明哪些策略有效

提前终止： 如果前2-3个查询已得到30+高质量结果，剩余查询可选择性执行

Step 3: Aggregate Results

步骤3：聚合结果

Combine all code files from all searches:

Collect files from each search output with their GitHub URLs
Deduplicate by
```
repository.full_name + file_path
```
- Keep highest-scored version if duplicates exist
- Note which queries found the same file (indicates strong relevance)
Maintain diversity - Ensure multiple repositories represented (avoid 10 files from one repo)
Track provenance - Remember which query found each file (useful for analysis)
Preserve GitHub URLs - Maintain full GitHub URLs for every file to include in summary

Result: Unified list of 15-30 unique, high-quality code files with GitHub URLs

合并所有搜索得到的代码文件：

收集文件 从每个搜索结果中获取文件及其GitHub链接
去重基于
```
repository.full_name + file_path
```
去重
- 若存在重复，保留评分最高的版本
- 记录哪些查询找到了同一个文件（表明相关性高）
保持多样性 - 确保结果来自多个仓库（避免10个文件都来自同一个仓库）
追踪来源 - 记录每个文件是由哪个查询找到的（便于分析）
保留GitHub链接 - 为每个文件保留完整GitHub链接，以便纳入总结

最终结果： 包含15-30个唯一、高质量代码文件的统一列表，附带GitHub链接

Step 4: Analyze Patterns

步骤4：分析模式

Extract factual patterns across all code files:

Import Analysis:

List most common imports (group by library)
Identify standard library vs third-party dependencies
Note version-specific patterns (e.g., React 18 hooks)

Architectural Patterns:

Functional vs class-based implementations
Custom hooks vs inline logic
Middleware chains vs single-handler
Configuration patterns (env vars, config files, inline)

Code Structure:

Function signatures (parameters, return types)
Error handling approaches (try/catch, error middleware, Result types)
Testing patterns (unit vs integration, mocking strategies)
Documentation styles (JSDoc, inline comments, README)

Language Distribution:

TypeScript vs JavaScript split
Strict mode usage
Type definition patterns

DO NOT editorialize - Extract facts, not opinions. Analysis comes in Step 5.

从所有代码文件中提取事实模式：

导入分析：

列出最常见的导入语句（按库分组）
区分标准库与第三方依赖
记录版本特定模式（如React 18的hooks）

架构模式：

函数式与类实现对比
自定义hooks与内联逻辑对比
中间件链与单一处理器对比
配置模式（环境变量、配置文件、内联配置）

代码结构：

函数签名（参数、返回类型）
错误处理方案（try/catch、错误中间件、Result类型）
测试模式（单元测试与集成测试、模拟策略）
文档风格（JSDoc、内联注释、README）

语言分布：

TypeScript与JavaScript的占比
严格模式的使用情况
类型定义模式

注意：仅提取事实，不加入主观意见 - 分析结论在步骤5中生成。

Step 5: Generate Comprehensive Summary

步骤5：生成综合总结

Output format (exact structure):

markdown

undefined

输出格式（严格遵循此结构）：

markdown

undefined

GitHub Code Search: [User Query Topic]

GitHub代码搜索：[用户查询主题]

Search Strategy Executed

执行的搜索策略

Ran [N] targeted queries:

```
query text
```
- [brief rationale] → [X results]
```
query text
```
- [brief rationale] → [Y results]
...

Total unique files analyzed: [N]

共执行[N]个针对性查询：

```
查询文本
```
- [简要设计依据] → [X条结果]
```
查询文本
```
- [简要设计依据] → [Y条结果]
...

分析的唯一文件总数： [N]

Pattern Analysis

模式分析

Common Imports

常见导入语句

```
library-name
```
- Used in [N/total] files
```
another-lib
```
- Used in [M/total] files

```
library-name
```
- 在[N/总文件数]个文件中使用
```
another-lib
```
- 在[M/总文件数]个文件中使用

Architectural Styles

架构风格

Functional Programming - [N] files use pure functions, immutable patterns
Object-Oriented - [M] files use classes, inheritance
Hybrid - [K] files mix both approaches

函数式编程 - [N]个文件使用纯函数、不可变模式
面向对象 - [M]个文件使用类、继承
混合模式 - [K]个文件混合两种方式

Implementation Patterns

实现模式

Pattern 1 Name: [Description with prevalence]
Pattern 2 Name: [Description with prevalence]

模式1名称：[描述及普及度]
模式2名称：[描述及普及度]

Approaches Found

发现的实现方案

Approach 1: [Name]

方案1：[名称]

Repos: [repo1], [repo2] Characteristics:

[Key trait 1]
[Key trait 2]

Example: repo/file_path:line_number

language

[relevant code snippet - NOT just first 40 lines]

仓库： [repo1], [repo2] 特点：

[关键特性1]
[关键特性2]

示例： repo/file_path:line_number

language

[相关代码片段 - 不要仅截取前40行]

Approach 2: [Name]

方案2：[名称]

[Similar structure]

[类似结构]

Trade-offs

方案权衡

Approach	Pros	Cons	Best For
Approach 1	[pros]	[cons]	[use case]
Approach 2	[pros]	[cons]	[use case]

方案	优势	劣势	适用场景
方案1	[优势]	[劣势]	[适用场景]
方案2	[优势]	[劣势]	[适用场景]

Recommendations

建议

For your use case ([infer from user's context]):

Primary recommendation: [Approach name]
- Why: [Rationale based on analysis]
- Implementation: [High-level steps]
- References: repo/file_path:line_number
Alternative: [Another approach]
- When to use: [Scenarios where this is better]
- References: repo/file_path:line_number

针对你的使用场景（[从用户上下文推断]）：

首要推荐： [方案名称]
- 原因： [基于分析的依据]
- 实现步骤： [高层级步骤]
- 参考： repo/file_path:line_number
替代方案： [另一方案]
- 适用场景： [更适合的场景]
- 参考： repo/file_path:line_number

Key Code Sections

关键代码片段

[Concept 1]

[概念1]

Source: repo/file_path:line_range

language

[Specific relevant code - imports, key function, not arbitrary truncation]

Why this matters: [Brief explanation]

来源： repo/file_path:line_range

language

[特定相关代码 - 导入语句、关键函数，而非任意截取]

重要性： [简要说明]

[Concept 2]

[概念2]

Source: repo/file_path:line_range

language

[Specific relevant code]

Why this matters: [Brief explanation]

来源： repo/file_path:line_range

language

[特定相关代码]

重要性： [简要说明]

All GitHub Files Analyzed

分析的所有GitHub文件

IMPORTANT: Include GitHub URLs for ALL meaningful files found across all searches.

List every unique file analyzed (15-30 files), grouped by repository:

重要提示： 包含所有搜索中找到的有意义文件的GitHub链接。

按仓库分组列出所有分析的唯一文件（15-30个）：

[repo-owner/repo-name] ([stars]⭐)

file_path - [language] - [brief description of what this file demonstrates]
file_path - [language] - [brief description]

file_path - [语言] - [该文件展示内容的简要描述]
file_path - [语言] - [简要描述]

[repo-owner/repo-name2] ([stars]⭐)

file_path - [language] - [brief description]

Format: Direct GitHub blob URLs with line numbers where relevant (e.g.,

https://github.com/owner/repo/blob/main/path/file.ts#L10-L50

)


**Summary characteristics:**
- **Factual** - Based on extracted data, not assumptions
- **Actionable** - Clear recommendations with reasoning
- **Contextualized** - References specific code locations with line numbers
- **Balanced** - Shows trade-offs, not just "best practice"
- **Comprehensive** - Covers patterns, approaches, trade-offs, recommendations
- **Accessible** - GitHub URLs for ALL meaningful files so users can explore full source code

---

file_path - [语言] - [简要描述]

格式要求： 使用完整的GitHub blob链接，必要时附带行号（例如：

https://github.com/owner/repo/blob/main/path/file.ts#L10-L50

）


**总结特点：**
- **事实性** - 基于提取的数据，而非假设
- **可操作性** - 提供清晰的建议及理由
- **上下文关联** - 引用带行号的具体代码位置
- **平衡性** - 展示权衡方案，而非仅推荐“最佳实践”
- **全面性** - 涵盖模式、方案、权衡、建议
- **易访问性** - 提供所有有意义文件的GitHub链接，方便用户查看完整源码

---

Step 6: Save Results to File

步骤6：将结果保存到文件

After generating comprehensive summary, persist for future reference:

Generate timestamp:
- Invoke
```
timestamp
```
  skill to get deterministic YYYYMMDDHHMMSS format
- Example:
```
20250110143052
```
Sanitize query for filename:
- Convert user's original query to kebab-case slug
- Rules: lowercase, spaces → hyphens, remove special chars, max 50 chars
- Example: "React hooks useState" → "react-hooks-usestate"

Construct file path:

Directory:
```
docs/research/github/
```
Format:
```
<timestamp>-<sanitized-query>.md
```

Full path:

docs/research/github/20250110143052-react-hooks-usestate.md

Save using Write tool:
- Content: Full comprehensive summary from Step 5
- Ensures persistence across sessions
- User can reference past research
Log saved location:
- Inform user where file was saved
- Example: "Research saved to docs/research/github/20250110143052-react-hooks-usestate.md"

Why save:

Comprehensive summaries represent significant analysis work (30-150s of API calls)
Users may want to reference patterns/trade-offs later
Builds searchable knowledge base of GitHub research
Avoids re-running expensive queries for same topics

生成综合总结后，将其持久化以便后续参考：

生成时间戳：
- 调用
```
timestamp
```
  技能获取标准化的YYYYMMDDHHMMSS格式时间戳
- 示例：
```
20250110143052
```
为文件名清理查询内容：
- 将用户原始查询转换为短横线分隔的小写格式（kebab-case）
- 规则：小写、空格替换为短横线、移除特殊字符、最大长度50字符
- 示例：“React hooks useState” → “react-hooks-usestate”

构建文件路径：

目录：
```
docs/research/github/
```
格式：
```
<timestamp>-<sanitized-query>.md
```

完整路径：

docs/research/github/20250110143052-react-hooks-usestate.md

使用Write工具保存：
- 内容：步骤5生成的完整综合总结
- 确保跨会话持久化
- 用户可参考过往研究结果
记录保存位置：
- 告知用户文件保存位置
- 示例：“研究结果已保存至docs/research/github/20250110143052-react-hooks-usestate.md”

保存原因：

综合总结包含大量分析工作（30-150秒的API调用）
用户后续可能需要参考模式/权衡方案
构建可搜索的GitHub研究知识库
避免针对同一主题重复执行昂贵的查询

Error Handling

错误处理

Common issues:

Auth errors: Prompt user to run
```
gh auth login --web
```
Rate limits: Show remaining quota, reset time. If hit during multi-search, stop gracefully with partial results
Network failures: Continue with partial results, note which queries failed
No results for query: Note in summary, adjust subsequent queries to be broader
All queries return same files: Note low diversity, recommend broader initial queries

Graceful degradation: Partial results are acceptable. Complete summary based on available data.

常见问题：

认证错误： 提示用户执行
```
gh auth login --web
```
速率限制： 显示剩余配额及重置时间。如果在多搜索过程中触发限制，优雅停止并返回部分结果
网络故障： 继续处理部分结果，记录哪些查询失败
查询无结果： 在总结中注明，调整后续查询以扩大范围
所有查询返回相同文件： 记录结果多样性低，建议初始查询范围更宽泛

优雅降级： 部分结果是可接受的，基于可用数据完成总结。

Limitations

局限性

GitHub API rate limit: 5,000 req/hr authenticated (multi-search uses more quota)
Each tool invocation fetches top 10 results only
Skips files >100KB
Sequential execution takes longer than single query (10-30s per query)
Provides factual data, not conclusions (Claude interprets patterns)
Deduplication assumes exact path matches (renamed files treated as unique)

GitHub API速率限制：认证用户每小时5000次请求（多搜索会消耗更多配额）
每次工具调用仅获取前10个结果
跳过大于100KB的文件
顺序执行比单次查询耗时更长（每个查询10-30秒）
仅提供事实数据，结论由Claude基于模式推断
去重基于精确路径匹配（重命名文件会被视为唯一文件）

Typical Execution Time

典型执行时间

Per query: 10-30 seconds depending on:

Number of results (100 max)
File sizes
Network latency
API rate limits

Full workflow (3-5 queries): 30-150 seconds

Optimization: If first queries yield sufficient results, skip remaining queries

每个查询： 10-30秒，取决于：

结果数量（最多100条）
文件大小
网络延迟
API速率限制

完整工作流（3-5个查询）： 30-150秒

优化： 如果前几个查询已得到足够结果，可跳过剩余查询

Integration Notes

集成示例

Example: User asks "find Claude Code skills doing github search"

javascript

// 1. Claude analyzes: Skills use SKILL.md with frontmatter, likely in .claude/skills/
// 2. Claude generates queries:
//    - "filename:SKILL.md github search" (matches SKILL.md files with "github search" text)
//    - "octokit.rest.search language:typescript" (matches actual Octokit API usage)
//    - "gh api language:typescript path:skills" (matches gh CLI usage in skills)
// 3. Claude executes sequentially:
cd plugins/knowledge-work/skills/gh-code-search
pnpm search "filename:SKILL.md github search"
// [analyze results]
pnpm search "octokit.rest.search language:typescript"
// [analyze results]
pnpm search "gh api language:typescript path:skills"
// 4. Claude aggregates, deduplicates, analyzes patterns
// 5. Claude generates comprehensive summary with trade-offs and recommendations

示例：用户提问“查找实现GitHub搜索的Claude Code技能”

javascript

// 1. Claude分析：技能使用带前置元数据的SKILL.md文件，通常位于.claude/skills/目录
// 2. Claude生成查询：
//    - "filename:SKILL.md github search"（匹配包含“github search”文本的SKILL.md文件）
//    - "octokit.rest.search language:typescript"（匹配实际的Octokit API用法）
//    - "gh api language:typescript path:skills"（匹配技能中的gh CLI用法）
// 3. Claude顺序执行：
cd plugins/knowledge-work/skills/gh-code-search
pnpm search "filename:SKILL.md github search"
// [分析结果]
pnpm search "octokit.rest.search language:typescript"
// [分析结果]
pnpm search "gh api language:typescript path:skills"
// 4. Claude聚合结果、去重、分析模式
// 5. Claude生成包含权衡方案和建议的综合总结

Testing

测试

Validate workflow with diverse queries:

Simple: "React hooks" (should generate 3+ queries, combine results)
Complex: "GitHub Actions TypeScript project setup" (requires config + implementation queries)
Ambiguous: "state management" (should generate queries for Redux, Zustand, XState, Context)

Check quality:

Deduplication works (no repeated files in summary)
Diverse repositories (not all from one repo)
Summary includes trade-offs and recommendations
Code snippets are relevant (not arbitrary truncations)

使用多样化查询验证工作流：

简单查询：“React hooks”（应生成3+查询，合并结果）
复杂查询：“GitHub Actions TypeScript项目配置”（需要针对配置和实现的查询）
模糊查询：“状态管理”（应生成针对Redux、Zustand、XState、Context的查询）

质量检查点：

去重功能正常（总结中无重复文件）
结果来自多个仓库（并非全部来自同一个仓库）
总结包含权衡方案和建议
代码片段具有相关性（非任意截取）