code-knowledge-graph

Name: code-knowledge-graph
Author: vibeeval

519stars44forks

How to install code-knowledge-graph?

vibeeval/vibecosystem/code-knowledge-graph

$npx -y skills add vibeeval/vibecosystem --skill code-knowledge-graph

Installs into the current project.

Summary

--- name: code-knowledge-graph description: "Codebase'i knowledge graph olarak analiz et. Dependency, call graph, hotspot analizi." allowed-tools: [Bash, Read, Glob, Grep] keywords: [dependency graph, code graph, knowledge graph, codebase analysis, architecture analysis, circ

Files · 1

View on GitHub

SKILL.md

1	# Code Knowledge Graph - Codebase Graph Analysis
2
3	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.
4
5	## Neden Knowledge Graph?
6
7	Kod text degil, graph'tir. Her dosya diger dosyalara baglidir. Bu baglantilari anlamadan:
8	- Refactoring yaparken neyi kiracagini bilemezsin
9	- Dead code'u guvenle silemezsin
10	- Yeni feature'in nereye oturacagini gormezsin
11	- Circular dependency'lerin kokunu bulamazsin
12
13	Knowledge graph tum bu iliskileri gorsellestirir ve olculebilir yapar.
14
15	## Kullanim
16
17	```
18	/code-knowledge-graph [hedef-dizin] [--focus module] [--depth N] [--format mermaid\|json\|both]
19	```
20
21	### Ornekler
22
23	```bash
24	# Tum codebase analizi
25	/code-knowledge-graph src/
26
27	# Belirli module odaklan
28	/code-knowledge-graph src/ --focus auth
29
30	# Sadece circular dependency kontrolu
31	/code-knowledge-graph src/ --focus circular
32
33	# Hotspot analizi
34	/code-knowledge-graph src/ --focus hotspots
35
36	# Orphan/dead code tespiti
37	/code-knowledge-graph src/ --focus orphans
38	```
39
40	## Graph Olusturma Adimlari
41
42	### Adim 1: Node Discovery
43
44	```bash
45	# Dosya agaci
46	tldr tree ${PATH:-src/} --ext .py
47
48	# Kod yapisi: fonksiyonlar, class'lar, export'lar
49	tldr structure ${PATH:-src/} --lang python
50	```
51
52	Her dosya, class, fonksiyon ve export bir node olur.
53
54	### Adim 2: Edge Extraction
55
56	```bash
57	# Dosyanin import'lari (outgoing edges)
58	tldr imports ${FILE}
59
60	# Modulu kim import ediyor? (incoming edges)
61	tldr importers ${MODULE} ${PATH:-src/}
62
63	# Cross-file call graph
64	tldr calls ${PATH:-src/}
65	```
66
67	Her import ve fonksiyon cagrisi bir directed edge olur.
68
69	### Adim 3: Layer Detection
70
71	```bash
72	# Architectural layer analizi
73	tldr arch ${PATH:-src/}
74	```
75
76	Node'lar 3 katmana ayrilir:
77
78	\| Katman \| Tanim \| Ornekler \|
79	\|--------\|-------\|---------\|
80	\| Entry \| Disaridan cagirilan, ici cagirmayan \| routes, cli, main, handlers \|
81	\| Middle \| Hem cagrilan hem cagirir \| services, business logic \|
82	\| Leaf \| Cagirilan ama baskasini cagirmayan \| utils, helpers, constants \|
83
84	### Adim 4: Impact Analysis
85
86	```bash
87	# Bu fonksiyona kim bagimli?
88	tldr impact ${FUNCTION} ${PATH:-src/} --depth 3
89
90	# Dead code: hicbir yerden cagrilmayan fonksiyonlar
91	tldr dead ${PATH:-src/}
92	```
93
94	### Adim 5: codebase-memory MCP Entegrasyonu
95
96	codebase-memory MCP kuruluysa, persistent graph sorgusu yap:
97
98	```
99	mcp: index_status -> Repo index durumu
100	mcp: index_repository -> Repo'yu indexle (yoksa)
101	mcp: query_graph -> Graph sorgusu (iliskiler)
102	mcp: search_graph -> Pattern arama
103	mcp: get_architecture -> Mimari genel bakis
104	mcp: trace_call_path -> Fonksiyonlar arasi cagri yolu
105	```
106
107	MCP, session'lar arasi kalici graph verisi saglar. tldr ise anlik taze analiz verir. Ikisini birlikte kullan.
108
109	## Dependency Analysis Pattern'leri
110
111	### Direct Dependencies
112	A dogrudan B'yi import ediyor:
113	```
114	A --import--> B
115	```
116
117	### Transitive Dependencies
118	A, B'yi import ediyor, B de C'yi import ediyor. A, C'ye transitif bagimli:
119	```
120	A --import--> B --import--> C
121	A ....transitif....> C
122	```
123
124	Transitive dependency chain'i uzadikca risk artar. `tldr impact` ile transitif zincirleri gor.
125
126	### Fan-In vs Fan-Out
127
128	\| Metrik \| Yuksek Degerin Anlami \| Risk \|
129	\|--------\|----------------------\|------\|
130	\| Fan-In (in-degree) \| Cok modul buna bagimli \| Fragile - degisiklik cascade yapar \|
131	\| Fan-Out (out-degree) \| Bu modul cok seye bagimli \| Unstable - disaridan kirilabilir \|
132
133	Hedef: Leaf node'larda yuksek fan-in (iyi - utility), entry node'larda yuksek fan-out (kotu - god module).
134
135	## Circular Dependency Cozme Stratejileri
136
137	Circular dependency = A imports B, B imports A (dogrudan veya transitif).
138
139	### Strateji 1: Extract Interface
140	```
141	ONCE: A <--> B (circular)
142	SONRA: A --> IB <-- B (interface ile decouple)
143	```
144
145	Her iki modul de bir interface'e bagimli olur, birbirine degil.
146
147	### Strateji 2: Dependency Inversion
148	```
149	ONCE: A --> B --> A (circular)
150	SONRA: A --> B, A <-- C (C yeni modul, B'nin A'ya ihtiyac duydugu kismi tasir)
151	```
152
153	### Strateji 3: Extract Shared Module
154	```
155	ONCE: A <--> B (ortak kod paylasiyor)
156	SONRA: A --> Shared <-- B (ortak kod ayri module)
157	```
158
159	### Strateji 4: Event-Based Decoupling
160	```
161	ONCE: A --> B --> A (geri cagri)
162	SONRA: A --> EventBus <-- B (event ile haberlesme)
163	```
164
165	### Hangi Stratejiyi Sec?
166
167	\| Durum \| Strateji \|
168	\|-------\|----------\|
169	\| Type/interface paylasimi \| Extract Interface \|
170	\| Fonksiyon geri cagrisi \| Dependency Inversion \|
171	\| Ortak utility kodu \| Extract Shared Module

People who liked this also viewed

6 picks

Type

code-knowledge-graph

519stars44forks

View on GitHub

How to install code-knowledge-graph?

vibeeval/vibecosystem/code-knowledge-graph

$npx -y skills add vibeeval/vibecosystem --skill code-knowledge-graph

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Code Knowledge Graph - Codebase Graph Analysis
2
3	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.
4
5	## Neden Knowledge Graph?
6
7	Kod text degil, graph'tir. Her dosya diger dosyalara baglidir. Bu baglantilari anlamadan:
8	- Refactoring yaparken neyi kiracagini bilemezsin
9	- Dead code'u guvenle silemezsin
10	- Yeni feature'in nereye oturacagini gormezsin
11	- Circular dependency'lerin kokunu bulamazsin
12
13	Knowledge graph tum bu iliskileri gorsellestirir ve olculebilir yapar.
14
15	## Kullanim
16
17	```
18	/code-knowledge-graph [hedef-dizin] [--focus module] [--depth N] [--format mermaid\|json\|both]
19	```
20
21	### Ornekler
22
23	```bash
24	# Tum codebase analizi
25	/code-knowledge-graph src/
26
27	# Belirli module odaklan
28	/code-knowledge-graph src/ --focus auth
29
30	# Sadece circular dependency kontrolu
31	/code-knowledge-graph src/ --focus circular
32
33	# Hotspot analizi
34	/code-knowledge-graph src/ --focus hotspots
35
36	# Orphan/dead code tespiti
37	/code-knowledge-graph src/ --focus orphans
38	```
39
40	## Graph Olusturma Adimlari
41
42	### Adim 1: Node Discovery
43
44	```bash
45	# Dosya agaci
46	tldr tree ${PATH:-src/} --ext .py
47
48	# Kod yapisi: fonksiyonlar, class'lar, export'lar
49	tldr structure ${PATH:-src/} --lang python
50	```
51
52	Her dosya, class, fonksiyon ve export bir node olur.
53
54	### Adim 2: Edge Extraction
55
56	```bash
57	# Dosyanin import'lari (outgoing edges)
58	tldr imports ${FILE}
59
60	# Modulu kim import ediyor? (incoming edges)
61	tldr importers ${MODULE} ${PATH:-src/}
62
63	# Cross-file call graph
64	tldr calls ${PATH:-src/}
65	```
66
67	Her import ve fonksiyon cagrisi bir directed edge olur.
68
69	### Adim 3: Layer Detection
70
71	```bash
72	# Architectural layer analizi
73	tldr arch ${PATH:-src/}
74	```
75
76	Node'lar 3 katmana ayrilir:
77
78	\| Katman \| Tanim \| Ornekler \|
79	\|--------\|-------\|---------\|
80	\| Entry \| Disaridan cagirilan, ici cagirmayan \| routes, cli, main, handlers \|
81	\| Middle \| Hem cagrilan hem cagirir \| services, business logic \|
82	\| Leaf \| Cagirilan ama baskasini cagirmayan \| utils, helpers, constants \|
83
84	### Adim 4: Impact Analysis
85
86	```bash
87	# Bu fonksiyona kim bagimli?
88	tldr impact ${FUNCTION} ${PATH:-src/} --depth 3
89
90	# Dead code: hicbir yerden cagrilmayan fonksiyonlar
91	tldr dead ${PATH:-src/}
92	```
93
94	### Adim 5: codebase-memory MCP Entegrasyonu
95
96	codebase-memory MCP kuruluysa, persistent graph sorgusu yap:
97
98	```
99	mcp: index_status -> Repo index durumu
100	mcp: index_repository -> Repo'yu indexle (yoksa)
101	mcp: query_graph -> Graph sorgusu (iliskiler)
102	mcp: search_graph -> Pattern arama
103	mcp: get_architecture -> Mimari genel bakis
104	mcp: trace_call_path -> Fonksiyonlar arasi cagri yolu
105	```
106
107	MCP, session'lar arasi kalici graph verisi saglar. tldr ise anlik taze analiz verir. Ikisini birlikte kullan.
108
109	## Dependency Analysis Pattern'leri
110
111	### Direct Dependencies
112	A dogrudan B'yi import ediyor:
113	```
114	A --import--> B
115	```
116
117	### Transitive Dependencies
118	A, B'yi import ediyor, B de C'yi import ediyor. A, C'ye transitif bagimli:
119	```
120	A --import--> B --import--> C
121	A ....transitif....> C
122	```
123
124	Transitive dependency chain'i uzadikca risk artar. `tldr impact` ile transitif zincirleri gor.
125
126	### Fan-In vs Fan-Out
127
128	\| Metrik \| Yuksek Degerin Anlami \| Risk \|
129	\|--------\|----------------------\|------\|
130	\| Fan-In (in-degree) \| Cok modul buna bagimli \| Fragile - degisiklik cascade yapar \|
131	\| Fan-Out (out-degree) \| Bu modul cok seye bagimli \| Unstable - disaridan kirilabilir \|
132
133	Hedef: Leaf node'larda yuksek fan-in (iyi - utility), entry node'larda yuksek fan-out (kotu - god module).
134
135	## Circular Dependency Cozme Stratejileri
136
137	Circular dependency = A imports B, B imports A (dogrudan veya transitif).
138
139	### Strateji 1: Extract Interface
140	```
141	ONCE: A <--> B (circular)
142	SONRA: A --> IB <-- B (interface ile decouple)
143	```
144
145	Her iki modul de bir interface'e bagimli olur, birbirine degil.
146
147	### Strateji 2: Dependency Inversion
148	```
149	ONCE: A --> B --> A (circular)
150	SONRA: A --> B, A <-- C (C yeni modul, B'nin A'ya ihtiyac duydugu kismi tasir)
151	```
152
153	### Strateji 3: Extract Shared Module
154	```
155	ONCE: A <--> B (ortak kod paylasiyor)
156	SONRA: A --> Shared <-- B (ortak kod ayri module)
157	```
158
159	### Strateji 4: Event-Based Decoupling
160	```
161	ONCE: A --> B --> A (geri cagri)
162	SONRA: A --> EventBus <-- B (event ile haberlesme)
163	```
164
165	### Hangi Stratejiyi Sec?
166
167	\| Durum \| Strateji \|
168	\|-------\|----------\|
169	\| Type/interface paylasimi \| Extract Interface \|
170	\| Fonksiyon geri cagrisi \| Dependency Inversion \|
171	\| Ortak utility kodu \| Extract Shared Module

People who liked this also viewed

6 picks

Type