SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsgithub-repo-search

github-repo-search

Coding & development

View repository

Updated 10-15 23:47

About this skill

GitHub Open-Source Project Search Assistant

Purpose

Starting from the user's natural-language needs, go through requirement elicitation, query term decomposition, GitHub search, filtering and classification, and in-depth interpretation, and finally produce structured recommendation results.

The goal is not to "give a lot of links", but to "give the user a candidate repository list that is understandable, comparable, decision-ready, and directly actionable".

Scope (V1.1)

  • Data source: GitHub public repositories.
  • Unauthenticated by default (does not use the user's Token).
  • Default hard filters:stars >= 100、archived=false、is:public。
  • Default output: a single ranked list (Top N), with each item in the list labeled by "repository ownership type".
  • This process does not include installation and deployment implementation by default (unless the user requests it separately).

Quota notes (must be known)

  • Unauthenticated Core API:60 次/小时。
  • Search API：10 次/分钟(independent of the Core quota).
  • The report must note the search time and quota status to avoid results being irreproducible.

Workflow

Stage 1: Requirement convergence (must be completed, cannot be skipped)

Hard gate: Stage 1 is a precondition for the entire process. No matter how clear the user's requirement description is, this stage must be completed and explicit user confirmation obtained before entering Stage 2. It is forbidden to directly infer requirements from the user's initial description and start searching. Even if the user says "just search directly", a requirement summary must first be output for the user to confirm.

Step 1: Requirement elicitation and alignment

Goal: Turn "I want to look at XX" into a search goal that is executable, sortable, and explainable.

Information to confirm (minimum)：

  1. Topic (e.g.: agent memory, RAG, browser automation)
  2. Quantity (Top 10 / Top 20)
  3. Minimum stars (default 100)
  4. Sorting mode (must choose one of two):相关性优先 / 星标优先(default: relevance first)
  5. Target form (must choose one or more): 可直接使用的产品 / 可二次开发的框架 / 资料清单/方法论

Suggested supplementary information (optional)：

  1. Preferred tech stack (Python/TS/Go, etc.)
  2. Use case (learning, production, benchmarking)
  3. Exclusions (tutorial repositories, archived repositories, pure paper reproductions, etc.)
  4. Deployment preference (local-first/cloud-first/hybrid)

Stage output (fixed format)：

核心诉求：
- 主题：xxx
- 数量：Top N
- 最低 stars：>= 100
- 排序模式：相关性优先 / 星标优先（默认：相关性优先）
- 目标形态：xxx
- 偏好：xxx（可空）
- 排除：xxx（可空）

Confirm the above information with the user.Only after explicit user confirmation can Stage 2 be entered; otherwise stop here and continue alignment.

Stage 2: Search execution (the following stages are executed autonomously by the model, with no user involvement, until the report is delivered in Stage 4)

Step 2: Query term decomposition (5-10 groups)

Goal: Balance "recall" and "relevance" and avoid going off-topic by relying only on hard single-word searches.

Term decomposition rules：

Each group of queries is composed of the following dimensions:

  1. Core term: the user's target term
  2. Synonyms: alternative expressions (e.g. long-term memory / stateful memory)
  3. Scenario terms: coding, mcp, tool, platform, awesome, curated
  4. Technical keywords: agent, sdk, framework, database, os
  5. Exclusion approach: do not hardcode too many negative examples in the query; leave them for the subsequent filtering stage

Output format：

Query-1: "xxx"
目的：高召回核心主题

Query-2: "xxx"
目的：补同义词盲区

Step 3: Execute retrieval and candidate recall

Execution principles：

  1. Execute retrieval for each query group (recommended 30-50 per group).
  2. Merge results to form a candidate pool.
  3. By owner/repo deduplicate.
  4. Record retrieval time and API quota information.

Candidate pool fields (minimum)：

  1. owner/repo
  2. stars
  3. description
  4. repo_url
  5. archived
  6. language
  7. updated_at
  8. topics
  9. license

Step 4: Deduplication and hard filtering

Hard filtering (default)：

  1. stars >= 100
  2. archived = false
  3. is:public

Optional hard filtering (as needed)：

  1. fork = false
  2. Specified language:language:xxx
  3. Update recency: last 6-12 months

Phase 3: Quality refinement

Step 5: Noise removal and relevance re-ranking

Goal: solve the noise problem of "hitting memory but not actually agent memory".

Noise removal rules (examples)：

  1. General engineering repositories unrelated to the topic (even if stars are very high)
  2. Repositories hit by keyword false positives (memory/agent only appears incidentally in the description)
  3. Repositories with no substantive content or that are abnormal

Ranking principles (V1.1)：

star no longer used as the primary ranking, only as one of the recall thresholds. Recommended comprehensive ranking weights:

  1. Requirement relevance: 35%
  2. Scenario applicability: 30%
  3. Activity (update recency): 15%
  4. Engineering maturity (documentation/examples/maintainability): 15%
  5. stars：5%

Step 6: Repository ownership type classification (required)

Goal: let users understand at a glance "what role this repository actually plays", avoiding conflating frameworks, applications, and directories.

Recommended type dictionary：

  1. General framework layer
  2. Application product layer (ready to use)
  3. Memory layer/context infrastructure
  4. MCP service layer
  5. Directory list layer (awesome/curated)
  6. Vertical scenario solution layer
  7. Methodology/research layer

Step 7: In-depth reading and project introduction writing (required)

Goal: not a "restatement of the repository summary", but outputting a detailed introduction "with decision value for the user".

Minimum requirements for in-depth reading：

For each selected repository, at least review:

  1. README core positioning paragraph
  2. Quick start/feature section headings
  3. Recent maintenance signals (update time, Issue/PR activity)

Project introduction writing requirements (fixed)：

The "project introduction" must include two parts and be written in detail:

  1. What this is: its role and boundaries in the system architecture
  2. Why recommended: its value under the user's current goals (not generic advantages)

Can be supplemented with:

  1. Typical applicable scenarios (1-2)
  2. Limitations or inapplicable scenarios (1)

Phase 4: Delivery and iteration

Step 8: Single-list generation and report delivery (final)

Delivery structure (fixed)：

  1. Requirement summary
  2. Search term list (5-10 groups + purpose)
  3. Filtering and re-ranking rules (explicitly stated)
  4. Results overview (raw recall/after deduplication/after filtering)
  5. Top N single ranking (table)
  6. Conclusions and next-step recommendations

Top N table fields (fixed)：

Repository Stars Repository ownership type Project introduction (what it is + reasons for recommendation) Other supplementary information Link

Suggested content for "Other supplementary information"：

  • Language / License / Last updated time
  • Onboarding complexity (low/medium/high)
  • Risk notice (if any)

Step 9: User confirmation and iteration (optional)

Iteration trigger conditions：

User feedback: "too broad/too narrow/not accurate enough/not detailed enough explanation."

Iteration actions：

  1. Adjust search terms (add scenario terms or synonyms)
  2. Adjust the stars threshold (100 -> 200/500)
  3. Add constraints (language/direction/update time)
  4. Adjust type weights (for example, prioritize the application layer or prioritize the framework layer)

Default parameters (V1.1)

  1. Minimum stars:100
  2. Default output:Top 10
  3. Default filtering:archived=false
  4. Default must classify: yes
  5. Default project introduction granularity: detailed (at least "what it is + why it is recommended")

Quality checklist (self-check before delivery)

  1. Whether requirement alignment has been completed and the "target form" has been clarified
  2. Whether there are 5-10 sets of queries and each set has a purpose
  3. Whether the search time and quota status have been recorded
  4. Whether deduplication, hard filtering, and noise removal have been performed
  5. Whether repository ownership type classification has been completed
  6. Whether every recommendation has a detailed project introduction (not a one-sentence description)
  7. Whether delivery uses the fixed table fields
  8. Whether installation and implementation have been avoided being mixed into this process