Vibecosystem code-knowledge-graph

Codebase'i knowledge graph olarak analiz et. Dependency, call graph, hotspot analizi.

install
source · Clone the upstream repo
git clone https://github.com/vibeeval/vibecosystem
Claude Code · Install into ~/.claude/skills/
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"
manifest: skills/code-knowledge-graph/SKILL.md
source content

Code 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:

KatmanTanimOrnekler
EntryDisaridan cagirilan, ici cagirmayanroutes, cli, main, handlers
MiddleHem cagrilan hem cagirirservices, business logic
LeafCagirilan ama baskasini cagirmayanutils, 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

MetrikYuksek Degerin AnlamiRisk
Fan-In (in-degree)Cok modul buna bagimliFragile - degisiklik cascade yapar
Fan-Out (out-degree)Bu modul cok seye bagimliUnstable - 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?

DurumStrateji
Type/interface paylasimiExtract Interface
Fonksiyon geri cagrisiDependency Inversion
Ortak utility koduExtract Shared Module
Async bildirim ihtiyaciEvent-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)
  • in_degree * 2
    : Bagimli modul sayisi (en onemli - cascade risk)
  • out_degree
    : Bagimlilik sayisi (kirilganlik)
  • change_frequency * 3
    : Git log'dan degisiklik sikligi (degisen hotspot = en tehlikeli)

Refactoring Oncelik Matrisi

Hotspot TipiOncelikAksiyon
Yuksek in-degree + sik degisenP0 CRITICALHemen split et, test ekle
Yuksek in-degree + stabilP2 MEDIUMTest ekle, dikkatli degistir
Yuksek out-degreeP1 HIGHDependency'leri azalt, facade pattern
Yuksek her ikisiP0 CRITICALGod 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:

  1. Impact sorusu: "Bu degisiklik kac modulu etkiler?"

    tldr impact changed_function src/ --depth 3
    
  2. Coupling sorusu: "Bu yeni import cycle yaratir mi?"

    • Mevcut graph'a yeni edge ekle, cycle kontrol et
  3. Cohesion sorusu: "Bu modul cok mu fazla is yapiyor?"

    • Out-degree > 8 ise muhtemelen evet
  4. Dead code sorusu: "Bu fonksiyon gercekten kullaniliyor mu?"

    tldr impact function_name src/
    

Onboarding Icin Graph Kullanimi

Yeni developer'a codebase'i tanitmak icin:

  1. Buyuk resim: Layer diagram'i goster (entry/middle/leaf)
  2. Kritik yollar: En onemli call chain'leri goster
  3. Hotspot'lar: "Bu dosyalara dokunurken dikkatli ol" listesi
  4. Moduller: Her modulu 1 cumle ile acikla + bagimliliklari goster

Architectural Decision Support

Graph verisi mimari kararlari destekler:

KararGraph 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

KomutKullanimCikti
tldr tree [path]
Dosya agaciJSON
tldr structure [path] --lang X
Kod yapisi (codemaps)JSON
tldr calls [path]
Cross-file call graphJSON
tldr impact <func> [path]
Reverse call graphJSON
tldr dead [path]
Dead/orphan codeJSON
tldr arch [path]
Layer detectionJSON
tldr imports <file>
Dosyanin import'lariJSON
tldr importers <module> [path]
Modulu kim import ediyorJSON

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

AracNe Zaman
graph-analyst
agent
Tam graph analizi, otomatik rapor
tldr arch
Hizli layer detection
tldr calls
Hizli call graph
codebase-memory MCP
Persistent graph, session arasi sorgulama
/explore architecture
Genel mimari kesfetme
architect
agent
Graph verisiyle mimari karar
janitor
agent
Orphan/dead code temizligi