Skill v1.0.1

version: "1.0.1" description: Search 2500+ curated ChatGPT and LLM open-source repositories. Use when the user asks to find tools, libraries, or repos related to ChatGPT, LLMs, RAG, agents, langchain, NLP, AI development, or any open-source AI tooling.

Search the awesome-ChatGPT-repositories database for: "$ARGUMENTS"

Instructions

Step 1 — Interpret the query

The user's query is: "$ARGUMENTS"

Supported query modifiers:

• category:<name> — filter to one category
• language:<lang> — filter by programming language
• list categories or categories — skip to Step 5b
• Plain text — keyword search across all categories

The descriptions are in English, so convert non-English queries to English keywords before searching.

Examples:

Keyword tips:

• Use stems, not full words. Substring match catches variants: embed → embedding/embeddings, retriev → retrieval/retrieve, classif → classification/classifier, generat → generation/generative, fine-tun → fine-tune/fine-tuning, summari → summarize/summarization, orchestrat → orchestrate/orchestration.
• Add domain-specific names. For common LLM/AI domains, include well-known tool or framework names present in the database:

• Aim for 3–6 keywords. Too few miss items; too many inflate low-quality partial matches.

Step 2 — Search the data files with grep

Data is split into per-category files. Each file is a JSON array with one repo record per line, so you can grep for matches instead of reading whole files — this keeps token use low (a typical query pulls in a few dozen matching lines instead of hundreds of KB). Fields per record:

• u: GitHub URL · n: repository name · d: English description
• c: category · l: language (optional) · t: topics comma-separated (optional)
• sc: quality score 0–8 · st: star count (optional) · ns: normalized star score 0–10 (optional)

File list (all under data/ relative to this plugin; six categories over ~200 entries are split a/b):

Which files to search — pick the minimum set that covers the query, then grep them (below):

Rule A — category: specified: grep only that category's file(s), skip routing below. Match the category name case-insensitively and accept common variants: cli/clis/command-line → CLIs · chatbot/bot/chatbots → Chatbots · browser/extension/browser-extension → Browser-extensions · prompt/prompts → Prompts · tutorial/tutorials → Tutorials · reimpl/reimplementation → Reimplementations · awesome/lists → Awesome-lists · open ai/openai → Openai. If the value matches no category, fall back to keyword routing (Rule C).

Rule B — list categories: skip all file reads, jump to Step 5b.

Rule C — keyword routing for general queries:

Use the English keywords from Step 1 (not the original query text) for routing. For each row below, check if any English keyword contains or matches the listed terms (case-insensitive substring). Use that row's file(s) only if there is a match. If multiple rows match, collect all their files (deduplicated). If no rows match, use the default: repos-chatbots-a.json, repos-nlp-a.json, repos-openai-a.json, repos-others-a.json.

Then grep those files for the keywords — do NOT open whole files with the Read tool. Locate the data directory once:

DATA="$(find "${HOME}/.claude/plugins" "${PWD}" -type d -name data -path "*awesome-chatgpt-search*" 2>/dev/null | head -1)"

Then grep the selected files for your Step 1 keywords and cap the output. Use -F (literal substring match — same semantics as the scoring step, and safe for keywords like c++ or .net) with one -e per keyword:

grep -ihF -e keyword1 -e keyword2 -e keyword3 "$DATA"/repos-nlp-a.json "$DATA"/repos-nlp-b.json | head -120

Each line of output is one repo record (a JSON object) that matched at least one keyword — score those lines directly in Step 4. This reads only the matching repos, not the whole files. Notes:

• If grep returns fewer than ~8 lines, broaden the keywords (add stems/tool names from Step 1) and re-run.
• If it returns the full head cap, your keywords are good; proceed.
• Only fall back to the Read tool on individual files if grep is unavailable.

Step 3 — Filter by language (if language:<lang> was given)

Append a language filter to the grep pipeline (the l field holds the language, matched case-insensitively):

grep -ihF -e keyword1 -e keyword2 "$DATA"/repos-clis-a.json "$DATA"/repos-clis-b.json | grep -iF '"l":"<lang>"' | head -120

Step 4 — Score candidates

Using the English keywords from Step 1, compute a relevance score for each repo record returned by grep:

Text match score (case-insensitive, per keyword):

• Name (n) exact keyword match: +20 pts
• Name (n) contains keyword: +10 pts
• Description (d) contains keyword: +5 pts
• Topics (t) contains keyword: +3 pts
• Category (c) contains keyword: +2 pts

Popularity bonus (added once per item):

• If ns (normalized star score) is present: min(4, ns * 0.4)
• Otherwise: min(4, sc * 0.5)

Quality bonus (always added): min(2, sc * 0.25)

Combined score = text_match + popularity_bonus + quality_bonus

Exclude items with text_match < 5 (catches only accidental partial hits). Collect top 20 candidates by combined score.

Step 5a — Re-rank with your judgment

Apply semantic judgment to produce the final ordered list of up to 10 results.

Re-rank by evaluating each candidate on:

1. Semantic centrality — how directly does this repo address the query's core intent?
2. Quality signal — higher sc means a richer, better-documented project.
3. Category fit — match the repo type to the implied need:

• "build a chatbot / ボット" → prefer Chatbots, CLIs
• "learn / tutorial / 勉強" → prefer Tutorials
• "prompt engineering" → prefer Prompts
• "use from browser" → prefer Browser-extensions
• "NLP task" → prefer NLP, Langchain
• "OpenAI API" → prefer Openai

1. Specificity — a repo specialized for the exact use-case beats a general one.
2. Language fit — if the user implied a language, prefer repos with matching l.

Step 5b — List categories (only if query was list categories / categories)

Skip scoring. Present:

## Available categories
 
| Category | Count |
|----------|-------|
| Awesome-lists | 98 |
| Prompts | 190 |
| Chatbots | 383 |
| Browser-extensions | 257 |
| CLIs | 268 |
| Reimplementations | 42 |
| Tutorials | 21 |
| NLP | 425 |
| Langchain | 180 |
| Unity | 17 |
| Openai | 329 |
| Others | 477 |
| **Total** | **2,687** |

Step 6 — Format the output

## Search results for "$ARGUMENTS"
 
*(Searched for: keyword1, keyword2, ...)*
 
Found N result(s).
 
### 1. [repository-name](url)
**Category:** category  ·  **Language:** language  ·  ⭐ {st} stars
Description text here.
*Topics: tag1, tag2, tag3*
 
### 2. ...

Omit the Language line if l is absent. Omit ⭐ stars if st is absent. Omit the Topics line if t is absent.

If no results found, suggest alternate keywords and link to: https://github.com/taishi-i/awesome-ChatGPT-repositories

Step 7 — Output use-case selection guide

After the search results list, append a guide table to help users pick the right repo for their specific situation.

Match the section heading and table language to the query language — if the query was in Japanese, use Japanese for the heading and column headers; otherwise use English.

## Use-case Selection Guide
 
| Use case | Recommended | Score | Why |
|---|---|---|---|
| ... | [name](url) | sc=N | short reason |

Rules:

• List 3–6 distinct use cases derived from the top 10 results. Each row should represent a meaningfully different scenario (e.g., "deploy a self-hosted chatbot" vs. "build a RAG pipeline"), not just a restatement of the query.
• For each row, select the single best repo from the top 10 results.
• Score column: show sc=N using the item's quality score.
• Why: write a 10–15 word reason in the query language explaining the practical benefit. Do not copy the description verbatim.
• If two use cases map to the same repo, merge them into one row or drop the weaker one.
• If there are fewer than 3 meaningfully distinct use cases in the results, output as many rows as make sense (minimum 1).