repo-discovery
Automated GitHub repository discovery and monitoring - scraping, scoring, and integration patterns
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
القائمة
Automated GitHub repository discovery and monitoring - scraping, scoring, and integration patterns
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
Run AI coding agents on disposable repo clones. The agent works on a clone — it can't touch your real repo. An optional container (Podman or Docker) provides build/test isolation. You review the diff and decide what (if anything) to apply.
Create Deezer playlists programmatically from any query — similar artists, genre mixes, festival lineups, mood-based collections. Four-tier data pipeline: Deezer public REST API + Last.fm scrobble data for discovery, GQL Pipe API for smart mixes and playlist creation, web search for subjective curation. Uses ARL cookie auth — no OAuth app required.
Generate compact AI-readable context maps from codebases — tools like codesight, repomix, agentic-context that pre-compute project structure to save tokens in AI coding sessions.
Research-focused query handling with multi-source synthesis, citations, and Obsidian persistence. Like a self-hosted Perplexity/Vane but CLI-native. Best for quick-to-medium lookups using Kagi. Use when the user asks factual questions, needs citations, or wants a direct answer — not a full research report (use deep-research) or social sentiment (use last30days). Triggers on: research, look into, what's the latest on, compare, explain, investigate.
Write articles, guides, blog posts, tutorials, newsletter issues, research reports, and deep research outputs in a distinctive voice derived from supplied examples or brand guidance. Use when the user wants polished written content longer than a paragraph, deep research on a topic, or a research report — especially when voice consistency, structure, and credibility matter. Triggers on: 'write an article', 'research report', 'deep research', 'long-form', 'blog post', 'guide', 'newsletter', 'white paper', 'research paper'.
Systematic research methodology for major consumer durables (appliances, HVAC, power tools, outdoor equipment) and smart garden/outdoor devices (bird feeder cameras, bird baths, smart outdoor gadgets). Emphasis on real reliability data, failure mode analysis, and head-to-head comparison. Use when the user asks to research, review, compare, or evaluate major purchases where longevity and repair risk matter, or when researching smart bird feeders, bird bath cameras, and similar connected outdoor devices. Triggers on: washer/dryer, refrigerator, dishwasher, HVAC, furnace, AC, generator, power tool, appliance reviews, appliance reliability, which [appliance] to buy, compare models, bird feeder camera, bird bath camera, smart garden devices.
استنادا إلى تصنيف SOC المهني
| name | repo-discovery |
| version | 1.0.0 |
| description | Automated GitHub repository discovery and monitoring - scraping, scoring, and integration patterns |
| summary | Build and operate repo discovery pipelines (GitRadar, etc.) with proper metadata enrichment, scoring, and feedback loops |
| triggers | ["github scraping","repo discovery","trending repos","gitradar","monitor github","find repositories"] |
| layer | session |
| requires | {"binaries":["python3"]} |
Automated GitHub repository discovery involves scraping trending/search results, enriching metadata, scoring relevance, and optionally learning from user feedback. Common tools: GitRadar, custom scripts, GitHub API integration.
Problem: Scraping GitHub Trending or similar pages typically yields only repository names (e.g., owner/repo), not full metadata (stars, description, topics, license).
Consequence: Repos with 0 stars/metadata fail quality filters (e.g., dead_repo filter requiring min 10 stars), causing all trending repos to be filtered out.
Solution: Two-phase collection with API enrichment:
def enrich_trending_repos(trending_repos):
"""Fetch metadata from GitHub API for scraped repos (otherwise they have 0 stars/metadata)."""
enriched = []
failed = 0
for repo_info in trending_repos:
full_name = repo_info["full_name"]
url = f"https://api.github.com/repos/{full_name}"
try:
wait_for_rate_limit() # Respect 60 req/hr unauthenticated, 5000 authenticated
req = urllib.request.Request(url, headers={
"Accept": "application/vnd.github+json"
})
with urllib.request.urlopen(req, timeout=15) as resp:
data = json.loads(resp.read().decode("utf-8", errors="replace"))
enriched_repo = extract_repo_metadata(data)
enriched_repo["source"] = repo_info.get("source", "trending")
enriched.append(enriched_repo)
except Exception as e:
failed += 1
if failed > 0:
print(f"WARN: Failed to enrich {failed}/{len(trending_repos)} repos")
return enriched
Key points:
GET /repos/{owner}/{repo} endpoint for individual repo metadataAccept: application/vnd.github+json header for v3 APIUnauthenticated: 60 requests/hour (harsh penalty for exceeding)
Authenticated: 5000 requests/hour (set GITHUB_TOKEN or GH_TOKEN env var)
Search API: 30 requests/minute (stricter limit)
def wait_for_rate_limit():
"""Throttle to avoid hitting GitHub rate limits."""
# Track timestamps of recent calls
# Sleep if limit would be exceeded
pass
Authentication fallback: Don't crash if gh CLI isn't installed — handle FileNotFoundError gracefully and continue unauthenticated.
Structure queries as templates with {stars} placeholder:
QUERY_TEMPLATES = [
{"q": "topic:llm stars:>{stars}", "sort": "stars", "order": "desc", "star_base": 5},
{"q": "topic:ai-agents stars:>{stars}", "sort": "stars", "order": "desc", "star_base": 5},
# ...
]
Dynamic threshold application:
star_base directly (allow low thresholds like 5)star_threshold as minimum floorScoring components (typical weights):
Classification labels (adjust thresholds to taste):
Store user ratings (useful/noise/duplicate) and apply to scoring:
{
"ratings": {
"owner/repo": {
"rating": "useful",
"timestamp": "2026-06-23T01:30:00Z"
}
}
}
Apply feedback bonuses:
useful: +15 pointsnoise: -20 pointsduplicate: -10 pointsLearning opportunity: Track which topics/languages correlate with high ratings for semantic similarity boosting (advanced).
For top-scored repos, fetch README and generate one-line summary via LLM:
def generate_summary(description, readme_excerpt):
prompt = f"""Write ONE clear sentence summarizing what this tool does.
Repository Description: {description}
README Excerpt: {readme_excerpt[:3000]}
One-sentence summary:"""
# Call LLM API
pass
NanoGPT enrichment (if NANOGPT_API_KEY set):
https://nano-gpt.com/api/v1/chat/completions (NOT api.nanogpt.co — that domain has TLS issues)gpt-4o-mini works; Qwen models are not supported on the /v1/chat/completions endpoint (returns 400)Accept: application/vnd.github.v3.raw to get raw textUse cases:
Trending scraping without enrichment: All repos filtered as "dead" due to 0 stars
Hard-crashing on missing gh CLI: Use try/except around subprocess.run
Counting enriched repos as "new": Track which repos were actually added (not in cache), not just enriched
Sequential API calls: Use asyncio + aiohttp for 5-10x speedup on large scans
No deduplication: Trending + search can return same repos — dedupe by full_name
Wrong function name in collect_weekly(): The weekly collection function calls scrape_trending() with no args, but the actual function signature is scrape_trending(url, label). This crashes with TypeError: missing 2 required positional arguments. The correct call is scrape_all_trending() which iterates all trending pages internally. Fix applied 2026-07-06 in ~/workspace/gitradar-hermes/scripts/gitradar-discover.py line 851.
403 on one query aborts entire run: GitHub's search API has both a primary limit (30 req/min) and a secondary "computed" rate limit that can return 403 even when the 30/min counter is fine. The original code bails out of the entire query loop on any 403, abandoning all remaining queries. Fix: wait 30s and continue to the next query instead of breaking. Also check the Retry-After header for GitHub's secondary rate limit and retry once after waiting.
Daily mode pagination blowup — subprocess timeout: Daily mode was using MAX_PAGES=10 per query across 19 query templates. With the 30 req/min search API throttle, that's ~190 potential API calls at 2s each = 6+ minutes, exceeding the 300s subprocess timeout in the cron wrapper (gitradar_daily.py). The run gets killed before scoring even starts. Fix has three layers:
DAILY_PAGES = 2 (daily only needs new finds, not exhaustive scan). Weekly keeps WEEKLY_PAGES = 5.DAILY_TIME_BUDGET = 180 (3 min soft limit inside collect_daily()). If elapsed time exceeds budget, bail out of the API loop gracefully and proceed to scoring with whatever was collected. Don't hard-abort — partial results are still useful.gitradar_daily.py subprocess timeout=600 as a safety net (was 300).
Result: runtime dropped from 5m9s to ~2m10s, same top repos discovered.Daily mode: Lightweight new-find scan
Weekly mode: Full re-evaluation
pushed_at timestamps to detect new activity{
"collected_at": "2026-06-23T01:30:00Z",
"mode": "daily",
"stats": {
"total_collected": 31,
"after_filter": 30,
"noise": 1
},
"repos": [
{
"full_name": "owner/repo",
"description": "...",
"stars": 73281,
"score": 95.0,
"label": "ADOPT",
"llm_summary": "Provides..."
}
]
}
# Daily scan at 8am, post to Discord
0 8 * * * cd ~/workspace/gitradar-hermes && ./run.sh daily
python3 scripts/gitradar-feedback.py rate owner/repo useful
python3 scripts/gitradar-feedback.py list
python3 scripts/gitradar-feedback.py stats
export NANOGPT_API_KEY="your...en"
python3 scripts/gitradar-enrich.py --top 20
references/enrichment-code.md — Full enrichment pattern with error handlingreferences/gitradar-fork-structure.md — Hermes-specific GitRadar fork details