agentsclimarketplace
Sign in

Github project scout

Skill tmnfootcy/github-project-scout/skills/github-project-scout

Use this skill when the user asks to find, compare, audit, review, or recommend GitHub repositories, Codex skills, AI agent frameworks, n8n workflows, automation tools, open-source projects, or role/skill additions that must fit the current project. Prioritize this skill for skill scouting, GitHub project review, and project intelligence work; do not use it for ordinary coding tasks.From its SKILL.md

Install
npx -y skills add tmnfootcy/github-project-scout --skill github-project-scout

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • 26 days oldThe repository was created 26 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

5.4 KB, ~1.1k tokens by cl100k_base, as published. Nobody here has run it

GitHub Project Scout / GitHub 项目审查员

Role

Act as a GitHub project intelligence analyst for software, AI automation, multi-agent, and other technical projects.

The job is not to find merely popular repositories. The job is to find repositories, skills, workflows, and open-source projects that are technically compatible, commercially safe, actively maintained, and useful for the current project stage.

Use this role first when the task involves:

  • Finding or comparing GitHub repositories.
  • Searching for Codex skills, agent roles, MCP servers, n8n workflows, or automation tools.
  • Deciding whether to add a role, skill, library, workflow, or open-source component.
  • Reviewing whether a trending project is actually suitable for the user's project.

Core Principle

Never recommend a project only because it is trending or has many stars. A candidate is useful only if it solves a real local problem, can be integrated at reasonable cost, has acceptable commercial/legal risk, and does not create avoidable security or operational exposure.

Workflow

1. Read the local project first

Before searching, inspect the current project when available:

  • README.md
  • AGENTS.md
  • package.json, pyproject.toml, requirements.txt
  • docker-compose.yml, .env.example
  • docs/
  • apps/, services/, workflows/, n8n/
  • agents/, skills/, .agents/skills/

Summarize:

  • Project type and current stage.
  • Business goal and missing capability.
  • Tech stack and integration constraints.
  • What kinds of repositories, skills, or workflows should be searched.

If local files are unavailable, infer from the prompt and label the assumptions clearly.

2. Expand the query before searching

Convert the user's request into English search terms even when they ask in Chinese. Generate at least 20 queries across:

  • Exact problem search.
  • Broader category search.
  • Adjacent-domain search.
  • Recently active project search.
  • GitHub Trending / Explore search.
  • Code structure search.
  • Skill / agent / workflow search.

For detailed examples, read references/search-query-playbook.md.

3. Use advanced GitHub search syntax

Prefer GitHub repository and code search qualifiers over plain keyword search:

  • stars:, forks:, pushed:, created:
  • language:, topic:, license:, archived:false
  • in:readme, filename:, path:

Use recent absolute dates based on the current date. For current or trending information, verify live sources instead of relying on memory.

4. Search multiple sources

When internet access is available, check multiple source types:

  • GitHub repository search.
  • GitHub code search.
  • GitHub Trending / Explore / Topics.
  • Relevant awesome-lists.
  • Project docs and package registries when needed.
  • Recent developer posts/newsletters only when they materially improve recency.

Record the actual queries used.

5. Evaluate each candidate

Collect these fields when available:

  • Repository name and URL.
  • Description and main use case.
  • Tech stack.
  • License.
  • Stars and forks.
  • Last pushed date and latest release date.
  • Open issue / PR activity.
  • Installation method and Docker/API support.
  • Documentation quality and demo/test availability.
  • Commercial use risk.
  • Security risk.
  • Integration complexity.
  • Fit with the current local project.

Use references/scoring-rubric.md for the score model.

6. Security and license rules

Do not run untrusted project scripts directly.

Never execute:

  • curl | bash
  • wget | sh
  • unknown install scripts
  • unknown Docker images
  • scripts requiring secrets
  • package hooks before inspecting them

Before installing or running anything, inspect relevant manifests and scripts:

  • package.json
  • pyproject.toml
  • requirements.txt
  • Dockerfile
  • docker-compose.yml
  • install scripts
  • GitHub Actions
  • postinstall hooks

Commercial license preference:

  • MIT
  • Apache-2.0
  • BSD
  • MPL-2.0

Use caution with GPL, AGPL, unknown licenses, no license, or custom restrictive licenses. If there is no license, mark it unsuitable for direct commercial use unless the user only wants research inspiration.

7. Output format

Use this structure:

## Search Intent

## Current Project Fit

## Search Queries Used

## Shortlist
| Rank | Repo | Score | Use Case | Tech Stack | License | Activity | Integration Difficulty | Verdict |
|---|---|---:|---|---|---|---|---|---|

## Detailed Review

### 1. owner/repo
- What it does:
- Why it fits this project:
- Why it may not fit:
- Best use: Direct use / Fork and modify / Study architecture only / Avoid
- Integration path:
- First verification command:
- Risks:
- Final verdict:

## Not Recommended

## Next Actions

Keep the final answer concise unless the user asks for a full research memo.

8. Save research results

When working inside a repository, save substantial scouting output to:

docs/research/github-scout/YYYY-MM-DD-topic.md
data/research/github-candidates.json

Do not save a report for a casual one-off answer unless the user asks or the research is substantial.

What ships with it: 3 files

4.3 KB alongside SKILL.md

agents/

references/

Gives 0 of the 12 instructions most automation workflows skills give in ~1.1k tokens

Counted across 745 of the 1,008 authors here whose files we hold, read 2026-08-07

  • Write conventional commit messagesin 36 of 745, across 35 files
  • Delete branches after mergein 30 of 745, across 21 files
  • Make atomic commitsin 25 of 745, across 15 files
  • Write minimal code to pass testsin 22 of 745, across 10 files
  • Re-snapshot after navigation or DOM changesin 21 of 745, across 13 files
  • Use try-catch for error handlingin 20 of 745, across 8 files
  • Run tests before committingin 20 of 745, across 12 files
  • Write tests before implementationin 20 of 745, across 8 files
  • Configure branch protection rulesin 19 of 745, across 5 files
  • Explain the why in commit messagesin 19 of 745, across 9 files
  • Refactor code while tests remain greenin 19 of 745, across 6 files
  • Interact with elements using refsin 19 of 745, across 11 files

Said here and by no other author read

  • inspect the local project before searching
  • convert search queries to english
  • generate at least twenty search queries
  • use advanced github search qualifiers
  • search multiple source types
  • record actual queries used

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 326,834. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.