repo-analysis

Analyzes cloned GitHub repositories to extract tech stack, architecture, and reusable patterns.

Updated May 19, 2026
One-click install
npx skills add https://github.com/richardnguyen0715/agent-sharing --skill repo-analysis-richardnguyen0715
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: repo-analysis
Source: https://github.com/richardnguyen0715/agent-sharing/tree/main/.github/skills/repo-analysis
Command: npx skills add https://github.com/richardnguyen0715/agent-sharing --skill repo-analysis-richardnguyen0715

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Cloning an interesting repository is easy, but turning it into actionable knowledge is not. This Skill provides a systematic workflow for analyzing a cloned codebase so you extract transferable patterns, architecture decisions, and adoption candidates instead of just reading code aimlessly. ## Core Features & Use Cases - Stack Identification: Automatically detect languages, dependencies, CI/CD configuration, and infrastructure from manifests and config files. - Architecture & Pattern Extraction: Map top-level modules, data flow, and test structure, then document notable patterns with file references and code snippets. - Assessment & Adoption Planning: Score code quality dimensions and convert findings into a prioritized list of what to adopt, where, and at what effort level. - Use Case: You cloned a popular FastAPI project and want to know how it structures dependency injection. Run the workflow to produce an analysis.md with the pattern documented, scored, and mapped to where it fits in your own system. ## Quick Start Analyze the repository I cloned to ~/references/my-repo and produce a full analysis.md covering its stack, architecture, key patterns, and what I should adopt.

Frequently Asked Questions about repo-analysis

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I analyze a cloned GitHub repository systematically?▼

Clone the repo to ~/references/{repo-name}, then follow the six-step workflow: identify the stack from manifests, map the architecture, extract notable patterns with code snippets, score quality dimensions, and plan adoptions. The output is saved as analysis.md in the repo directory.

How to identify a project's tech stack without reading all the code?▼

Inspect dependency manifests like requirements.txt, pyproject.toml, and package.json, count file extensions for language breakdown, and check .github/workflows, Dockerfile, and docker-compose.yml for CI/CD and infrastructure details.

What should I look for when reviewing another project's architecture?▼

Focus on top-level modules and their responsibilities, where data enters and exits the system, whether tests mirror the source structure, and separation of concerns. Skim entry points, core domain logic, and infrastructure adapters rather than reading everything.

Can this workflow analyze a repository that is not cloned locally?▼

No, the workflow expects the repository to be cloned locally first, typically to ~/references/{repo-name}. If it is not cloned yet, the pre-flight step provides the git clone command to fetch it before analysis begins.

What are the limitations of manual repository analysis?▼

The workflow deliberately skims for the most interesting 20 percent of code, so it may miss edge-case logic or deeply nested modules. It is designed for extracting transferable patterns, not for exhaustive audits or security reviews.