Vibecosystem code-knowledge-graph
Codebase'i knowledge graph olarak analiz et. Dependency, call graph, hotspot analizi.
git clone https://github.com/vibeeval/vibecosystem
T=$(mktemp -d) && git clone --depth=1 https://github.com/vibeeval/vibecosystem "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/code-knowledge-graph" ~/.claude/skills/vibeeval-vibecosystem-code-knowledge-graph && rm -rf "$T"
skills/code-knowledge-graph/SKILL.mdCode Knowledge Graph - Codebase Graph Analysis
Codebase'i knowledge graph olarak modeller. Dosya, modul, fonksiyon ve class'lar node; import, call, inheritance ve composition iliskileri edge olur. Sonuc: Mermaid diagram + JSON graph data.
Neden Knowledge Graph?
Kod text degil, graph'tir. Her dosya diger dosyalara baglidir. Bu baglantilari anlamadan:
- Refactoring yaparken neyi kiracagini bilemezsin
- Dead code'u guvenle silemezsin
- Yeni feature'in nereye oturacagini gormezsin
- Circular dependency'lerin kokunu bulamazsin
Knowledge graph tum bu iliskileri gorsellestirir ve olculebilir yapar.
Kullanim
/code-knowledge-graph [hedef-dizin] [--focus module] [--depth N] [--format mermaid|json|both]
Ornekler
# Tum codebase analizi /code-knowledge-graph src/ # Belirli module odaklan /code-knowledge-graph src/ --focus auth # Sadece circular dependency kontrolu /code-knowledge-graph src/ --focus circular # Hotspot analizi /code-knowledge-graph src/ --focus hotspots # Orphan/dead code tespiti /code-knowledge-graph src/ --focus orphans
Graph Olusturma Adimlari
Adim 1: Node Discovery
# Dosya agaci tldr tree ${PATH:-src/} --ext .py # Kod yapisi: fonksiyonlar, class'lar, export'lar tldr structure ${PATH:-src/} --lang python
Her dosya, class, fonksiyon ve export bir node olur.
Adim 2: Edge Extraction
# Dosyanin import'lari (outgoing edges) tldr imports ${FILE} # Modulu kim import ediyor? (incoming edges) tldr importers ${MODULE} ${PATH:-src/} # Cross-file call graph tldr calls ${PATH:-src/}
Her import ve fonksiyon cagrisi bir directed edge olur.
Adim 3: Layer Detection
# Architectural layer analizi tldr arch ${PATH:-src/}
Node'lar 3 katmana ayrilir:
| Katman | Tanim | Ornekler |
|---|---|---|
| Entry | Disaridan cagirilan, ici cagirmayan | routes, cli, main, handlers |
| Middle | Hem cagrilan hem cagirir | services, business logic |
| Leaf | Cagirilan ama baskasini cagirmayan | utils, helpers, constants |
Adim 4: Impact Analysis
# Bu fonksiyona kim bagimli? tldr impact ${FUNCTION} ${PATH:-src/} --depth 3 # Dead code: hicbir yerden cagrilmayan fonksiyonlar tldr dead ${PATH:-src/}
Adim 5: codebase-memory MCP Entegrasyonu
codebase-memory MCP kuruluysa, persistent graph sorgusu yap:
mcp: index_status -> Repo index durumu mcp: index_repository -> Repo'yu indexle (yoksa) mcp: query_graph -> Graph sorgusu (iliskiler) mcp: search_graph -> Pattern arama mcp: get_architecture -> Mimari genel bakis mcp: trace_call_path -> Fonksiyonlar arasi cagri yolu
MCP, session'lar arasi kalici graph verisi saglar. tldr ise anlik taze analiz verir. Ikisini birlikte kullan.
Dependency Analysis Pattern'leri
Direct Dependencies
A dogrudan B'yi import ediyor:
A --import--> B
Transitive Dependencies
A, B'yi import ediyor, B de C'yi import ediyor. A, C'ye transitif bagimli:
A --import--> B --import--> C A ....transitif....> C
Transitive dependency chain'i uzadikca risk artar.
tldr impact ile transitif zincirleri gor.
Fan-In vs Fan-Out
| Metrik | Yuksek Degerin Anlami | Risk |
|---|---|---|
| Fan-In (in-degree) | Cok modul buna bagimli | Fragile - degisiklik cascade yapar |
| Fan-Out (out-degree) | Bu modul cok seye bagimli | Unstable - disaridan kirilabilir |
Hedef: Leaf node'larda yuksek fan-in (iyi - utility), entry node'larda yuksek fan-out (kotu - god module).
Circular Dependency Cozme Stratejileri
Circular dependency = A imports B, B imports A (dogrudan veya transitif).
Strateji 1: Extract Interface
ONCE: A <--> B (circular) SONRA: A --> IB <-- B (interface ile decouple)
Her iki modul de bir interface'e bagimli olur, birbirine degil.
Strateji 2: Dependency Inversion
ONCE: A --> B --> A (circular) SONRA: A --> B, A <-- C (C yeni modul, B'nin A'ya ihtiyac duydugu kismi tasir)
Strateji 3: Extract Shared Module
ONCE: A <--> B (ortak kod paylasiyor) SONRA: A --> Shared <-- B (ortak kod ayri module)
Strateji 4: Event-Based Decoupling
ONCE: A --> B --> A (geri cagri) SONRA: A --> EventBus <-- B (event ile haberlesme)
Hangi Stratejiyi Sec?
| Durum | Strateji |
|---|---|
| Type/interface paylasimi | Extract Interface |
| Fonksiyon geri cagrisi | Dependency Inversion |
| Ortak utility kodu | Extract Shared Module |
| Async bildirim ihtiyaci | Event-Based Decoupling |
Hotspot Analizi ve Refactoring Onceliklendirme
Hotspot = Graph'ta en cok baglantisi olan node.
Hotspot Skorlama
hotspot_score = (in_degree * 2) + out_degree + (change_frequency * 3)
: Bagimli modul sayisi (en onemli - cascade risk)in_degree * 2
: Bagimlilik sayisi (kirilganlik)out_degree
: Git log'dan degisiklik sikligi (degisen hotspot = en tehlikeli)change_frequency * 3
Refactoring Oncelik Matrisi
| Hotspot Tipi | Oncelik | Aksiyon |
|---|---|---|
| Yuksek in-degree + sik degisen | P0 CRITICAL | Hemen split et, test ekle |
| Yuksek in-degree + stabil | P2 MEDIUM | Test ekle, dikkatli degistir |
| Yuksek out-degree | P1 HIGH | Dependency'leri azalt, facade pattern |
| Yuksek her ikisi | P0 CRITICAL | God module - parcala |
Change Frequency Analizi
# Git log'dan en cok degisen dosyalar git log --format=format: --name-only --since="6 months ago" | sort | uniq -c | sort -rn | head -20
Cok degisen + cok baglantili = en yuksek risk.
Mermaid Diagram Ornekleri
Dependency Graph (Layered)
graph TD subgraph Entry["Entry Layer (Red)"] routes[routes.py] cli[cli.py] end subgraph Middle["Middle Layer (Orange)"] auth[auth_service.py] user[user_service.py] end subgraph Leaf["Leaf Layer (Green)"] utils[utils.py] validators[validators.py] end routes --> auth routes --> user cli --> user auth --> utils auth --> validators user --> utils style routes fill:#e74c3c,color:#fff style cli fill:#e74c3c,color:#fff style auth fill:#f39c12,color:#fff style user fill:#f39c12,color:#fff style utils fill:#27ae60,color:#fff style validators fill:#27ae60,color:#fff
Call Graph
graph LR handle_request --> validate handle_request --> authorize authorize --> check_token authorize --> check_role validate --> sanitize check_token --> decode_jwt
Circular Dependency (Highlighted)
graph LR A[module_a] -->|imports| B[module_b] B -->|imports| C[module_c] C -->|imports| A style A fill:#e74c3c,color:#fff style B fill:#e74c3c,color:#fff style C fill:#e74c3c,color:#fff linkStyle 0 stroke:#e74c3c,stroke-width:3px linkStyle 1 stroke:#e74c3c,stroke-width:3px linkStyle 2 stroke:#e74c3c,stroke-width:3px
Hotspot Visualization
graph TD A[utils.py<br/>in:12 out:1<br/>HOTSPOT] B[service.py<br/>in:3 out:8] C[routes.py<br/>in:0 out:5] D[models.py<br/>in:6 out:2] C --> B C --> A B --> A B --> D D --> A style A fill:#e74c3c,stroke:#c0392b,stroke-width:4px,color:#fff style D fill:#f39c12,stroke:#e67e22,stroke-width:2px,color:#fff
Graph-Based Code Review
Knowledge graph review'da su sorulari cevaplar:
-
Impact sorusu: "Bu degisiklik kac modulu etkiler?"
tldr impact changed_function src/ --depth 3 -
Coupling sorusu: "Bu yeni import cycle yaratir mi?"
- Mevcut graph'a yeni edge ekle, cycle kontrol et
-
Cohesion sorusu: "Bu modul cok mu fazla is yapiyor?"
- Out-degree > 8 ise muhtemelen evet
-
Dead code sorusu: "Bu fonksiyon gercekten kullaniliyor mu?"
tldr impact function_name src/
Onboarding Icin Graph Kullanimi
Yeni developer'a codebase'i tanitmak icin:
- Buyuk resim: Layer diagram'i goster (entry/middle/leaf)
- Kritik yollar: En onemli call chain'leri goster
- Hotspot'lar: "Bu dosyalara dokunurken dikkatli ol" listesi
- Moduller: Her modulu 1 cumle ile acikla + bagimliliklari goster
Architectural Decision Support
Graph verisi mimari kararlari destekler:
| Karar | Graph Verisi |
|---|---|
| "Bu modulu bolmeli miyiz?" | In-degree + out-degree + LOC |
| "Microservice siniri nerede?" | Cluster analizi (yuksek ic baglantilar, dusuk dis baglantilar) |
| "Hangi modulu once refactor edelim?" | Hotspot score siralamasina bak |
| "Yeni feature nereye oturur?" | Mevcut layer'a ve dependency pattern'ine bak |
| "Bu dependency guvenli mi?" | Transitif dependency chain'ine bak |
tldr CLI Komut Referansi
| Komut | Kullanim | Cikti |
|---|---|---|
| Dosya agaci | JSON |
| Kod yapisi (codemaps) | JSON |
| Cross-file call graph | JSON |
| Reverse call graph | JSON |
| Dead/orphan code | JSON |
| Layer detection | JSON |
| Dosyanin import'lari | JSON |
| Modulu kim import ediyor | JSON |
JSON Graph Data Formati
{ "metadata": { "project": "project-name", "analyzed_at": "2026-03-26T10:00:00Z", "total_nodes": 45, "total_edges": 128, "languages": ["python"] }, "nodes": [ { "id": "src/auth/service.py::AuthService", "type": "class", "file": "src/auth/service.py", "layer": "middle", "in_degree": 5, "out_degree": 3, "is_hotspot": true, "is_orphan": false } ], "edges": [ { "source": "src/routes.py::handle_login", "target": "src/auth/service.py::AuthService.authenticate", "type": "call" } ], "layers": { "entry": [], "middle": [], "leaf": [] }, "circular_dependencies": [], "hotspots": [], "orphans": [] }
Iliskili Araclar
| Arac | Ne Zaman |
|---|---|
agent | Tam graph analizi, otomatik rapor |
| Hizli layer detection |
| Hizli call graph |
| Persistent graph, session arasi sorgulama |
| Genel mimari kesfetme |
agent | Graph verisiyle mimari karar |
agent | Orphan/dead code temizligi |