Awesome Chatgpt Search

Search the awesome-ChatGPT-repositories database for the user's query.

Instructions

Ground rules — they apply whether this skill was invoked explicitly or picked automatically:

• Present only repositories from the bundled data files, even when the list has just a few matches — then say so and suggest other keywords rather than filling the gap from elsewhere.
• Don't search the web or open repository pages to add or verify details (setup, license, activity) unless the user explicitly asks for that: the curated list is the source of truth here, and its star counts and descriptions are snapshots. Copy names, URLs, and star counts exactly as they appear in the records.
• The output templates in Steps 5b–7 are fixed: keep their Markdown headings (##, ###), field labels, and order, and don't restyle them (for example, turning the result list into a table or a prose summary).
• If the data files can't be read (for example, shell commands are blocked), say so and link https://github.com/taishi-i/awesome-ChatGPT-repositories instead of substituting other sources.

Step 1 — Interpret the query

The query is the text the user passed to this skill (the same skill runs in Claude Code, Codex, and other agents):

• Claude Code: the arguments of /awesome-chatgpt-search, appended at the end as ARGUMENTS: ….
• Codex and other agents: the user's message that invoked this skill ($awesome-chatgpt-search in Codex), minus the skill mention itself.

If there is no explicit query text, use the user's latest request.

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/ next to this SKILL.md; 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 the keyword search, 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 read whole files into context (no Read tool, cat, or full-file dumps). Locate the data directory once — it is the data/ folder next to this SKILL.md:

• Claude Code: ${CLAUDE_SKILL_DIR}/data
• Codex and other agents: <directory of this SKILL.md>/data, built from the absolute path you loaded this SKILL.md from.

If that directory does not exist (unusual install), find it — the data directory is the folder that contains the printed file:

find "$PWD" "$HOME/.agents/skills" "$HOME/.claude/skills" "${CODEX_HOME:-$HOME/.codex}/skills" -type f -name repos-unity.json -path "*awesome-chatgpt-search*" 2>/dev/null | head -1

Shell variables may not persist between commands, so write the resolved absolute path in place of $DATA in the commands below.

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 more general single-word stems or tool names from Step 1 — multi-word phrases rarely match) and re-run.
• If it returns the full head cap, your keywords are good; proceed.
• Only fall back to reading individual files if grep is unavailable.