一键导入
repo-analysis
Analyze GitHub repositories for architecture, patterns, and code quality. Use when user asks to analyze, review, or understand a GitHub repository.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Analyze GitHub repositories for architecture, patterns, and code quality. Use when user asks to analyze, review, or understand a GitHub repository.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
Persistent memory system with .memory.md, compaction, and cross-project sync
Analyzes sessions using ACE framework to generate prompt improvement suggestions focused on durable patterns.
Database technology selection and architecture - choose between SQL vs NoSQL, PostgreSQL vs MySQL vs MongoDB, scaling strategies, migration planning. Use for database DECISIONS. For PostgreSQL implementation use postgresql skill.
Analyze feature flows for completeness, preconditions, and branch coverage using reusable flow-analyzer tools.
Automated post-phase validation workflow for GSD phases with deterministic gates and HITL controls.
Full workflow orchestration with config-driven routing and phase-based execution
基于 SOC 职业分类
| name | repo-analysis |
| description | Analyze GitHub repositories for architecture, patterns, and code quality. Use when user asks to analyze, review, or understand a GitHub repository. |
| license | MIT |
| compatibility | opencode |
| metadata | {"author":"OpenCode Community","version":"1.0.0"} |
Analyze GitHub repositories using gh CLI for cloning and local analysis.
Use this skill when the user asks:
systematic-debugging or test-driven-development skillsread tool directly, no cloning neededopencode-mastery skill or ExternalScout for library docswebfetch tool for non-GitHub URLs1. Call repo-analyze tool with repository name
- repo: "owner/repo" (required)
- depth: 1 (default, shallow clone)
- focus: optional directory to focus on
- cleanup: false (keep for deeper analysis)
2. Review tool output:
- Repository structure
- Languages used
- Package managers
- Test frameworks
- Key files
Architecture Analysis:
# Entry points
grep -r "export.*main\|export.*App\|createServer" /tmp/repo/src/
# Dependencies
cat /tmp/repo/package.json | grep -A 50 "dependencies"
# Module structure
find /tmp/repo/src -type d | head -20
Pattern Discovery:
# Design patterns
grep -r "Factory\|Singleton\|Observer\|Strategy" /tmp/repo/src/
# Code conventions
grep -r "eslint\|prettier" /tmp/repo/.* 2>/dev/null
cat /tmp/repo/.prettierrc 2>/dev/null
Quality Assessment:
# Test coverage indicators
find /tmp/repo -name "*.test.*" -o -name "*.spec.*" | wc -l
# TypeScript strictness
cat /tmp/repo/tsconfig.json | grep "strict"
# Documentation
find /tmp/repo -name "*.md" | head -10
History & Contributors:
# Recent activity
cd /tmp/repo && git log --oneline -20
# Top contributors
cd /tmp/repo && git shortlog -sn | head -10
# Commit patterns
cd /tmp/repo && git log --format="%s" -50 | grep -E "^[a-z]+:"
Structure your analysis:
## Repository Analysis: owner/repo
### Overview
- **Description**: [from tool output]
- **Stars**: [count]
- **Primary Language**: [language]
- **Package Manager**: [manager]
### Architecture
- **Structure**: [key directories and their purposes]
- **Entry Points**: [main files/modules]
- **Patterns Used**: [identified patterns]
### Quality Indicators
- **Tests**: [framework + coverage estimate]
- **Linting/Formatting**: [tools used]
- **TypeScript**: [strictness level]
- **Documentation**: [quality assessment]
### Key Findings
1. [Finding 1]
2. [Finding 2]
3. [Finding 3]
### Recommendations
- [If user asked for recommendations]
### Permalinks
- Key files: https://github.com/owner/repo/blob/[sha]/path
rm -rf /tmp/repo-nameUser: "Analyseer de repo van sveltejs/svelte"
# Step 1: Call the tool (ALWAYS start here)
→ repo-analyze({ repo: "sveltejs/svelte", depth: 1, cleanup: false })
# Step 2: Tool returns foundation
← {
"path": "/tmp/svelte",
"languages": ["TypeScript", "JavaScript"],
"packageManager": "pnpm",
"structure": { "packages/": ["svelte", "svelte-motion"], "sites/": 2 }
}
# Step 3: Targeted deep dive (focus on what user might want)
→ ls /tmp/svelte/packages/svelte/src/
→ cat /tmp/svelte/packages/svelte/package.json
→ grep -r "export function" /tmp/svelte/packages/svelte/src/ | head -10
# Step 4: Report with permalinks (use SHA from tool output)
→ Report: "Svelte is a TypeScript monorepo with pnpm..."
→ Permalink: https://github.com/sveltejs/svelte/blob/[sha]/packages/svelte/src/index.ts
# Step 5: Cleanup when analysis complete
→ rm -rf /tmp/svelte
User: "Is zod geschikt voor form validatie?"
# Step 1: Analyze the repo
→ repo-analyze({ repo: "colinhacks/zod", depth: 1 })
# Step 2: Focus on relevant parts
→ cat /tmp/zod/README.md | grep -A 10 "validation"
→ find /tmp/zod/src -name "\*.test.ts" | wc -l # Check test coverage
# Step 3: Answer the specific question
← "Yes, Zod is suitable. It has 500+ tests, TypeScript-first design..."
# WRONG: Manual clone bypasses tool benefits
gh repo clone owner/repo /tmp/repo
# RIGHT: Use the tool for structured analysis
repo-analyze({ repo: "owner/repo" })
# WRONG: Reading every file
grep -r "." /tmp/repo/src/ # Huge output, slow
# RIGHT: Targeted analysis
grep -r "export.*function" /tmp/repo/src/ | head -20
# WRONG: Leaving repos in /tmp
# (fills disk over time)
# RIGHT: Always cleanup
rm -rf /tmp/repo-name
# WRONG: Cloning a repo you already have locally
repo-analyze({ repo: "my-org/my-local-project" })
# RIGHT: Analyze local codebase directly
grep -r "pattern" ./src/
# WRONG: Full analysis when user asked a simple question
User: "What language is React written in?"
→ [runs 20-minute full analysis]
# RIGHT: Quick answer
→ repo-analyze({ repo: "facebook/react", depth: 1 })
→ Check languages in output
← "JavaScript and TypeScript"
src/plugin/repo-analyzer/index.ts - Implementationopencode.config.yaml → features.repoAnalyzer - Settingsopencode-mastery (docs), systematic-debugging (local analysis)gh repo clone --help - Clone options