repo-analyst

name	repo-analyst
description	Use when the user shares a GitHub URL and wants to understand, evaluate, or extract useful techniques from a repository — triggers on "研究這個 repo", "這個對我們有沒有用", "分析這個專案", or any GitHub link with evaluation intent

Repo Analyst

Overview

Analyze a GitHub repository to extract useful techniques AND evaluate adoption fit. The key insight: a repo you won't adopt can still teach you something worth keeping.

Workflow

1. Fetch — Read the repo's README, directory structure, and key source files
2. Run classify (prompts/classify.md) — determine repo type, tag content sections
3. Run process (prompts/process.md) — extract techniques + evaluate adoption per project
4. Run validate (prompts/validate.md) — verify recommendations are grounded
5. Present findings to user with structured action items

Phase 1: Fetch

URL Parsing

Accept any of these formats and extract owner and repo:

• Full URL: https://github.com/owner/repo or https://github.com/owner/repo/tree/main/...
• Short form: owner/repo

Parsing logic:

1. Strip https://github.com/ prefix if present
2. Split on / — first segment is owner, second is repo
3. Discard any trailing path segments (e.g. /tree/main/src)

Fetch Commands

# Fetch repo metadata
gh repo view <owner/repo> --json description,url,stargazerCount,primaryLanguage

# Fetch README content
gh api repos/<owner/repo>/readme -q .content | base64 -d

# Fetch directory structure
gh api repos/<owner/repo>/git/trees/HEAD?recursive=1 -q '.tree[].path' | head -100

# Read key source files (based on classify results)
gh api repos/<owner/repo>/contents/<path> -q .content | base64 -d

Input

• A GitHub URL (required)
• User's project context (from memory or CLAUDE.md)

Output

Two-part deliverable:

Part 1 — Technique Extraction (always, even if repo isn't adoptable)

• Transferable patterns, design ideas, architectural decisions worth learning
• Each with: what it is, why it's interesting, where it could apply

Part 2 — Adoption Evaluation (per applicable project)

• Feature-by-feature comparison with current tools/workflow
• Cost/benefit analysis
• Decision: adopt / defer / reject, with timeline if adopt

Quick Reference

Principle	Rule
Always extract before evaluating	A "not adoptable" repo can still have valuable patterns
Classify first	Repo type determines analysis path
Compare, don't just describe	Every feature needs a "vs what we have now" column
Recommendations need actions	"Not recommended" is not an action — state what to do instead
Record decisions	Update project memory with adopt/defer/reject and why
Validate honestly	Same agent runs validate — err on the side of FAIL when borderline