dependency-graph

Name: dependency-graph
Author: girijashankarj

27stars3forks

How to install dependency-graph?

girijashankarj/cursor-handbook/dependency-graph

$npx -y skills add girijashankarj/cursor-handbook --skill dependency-graph

Installs into the current project.

Summary

Map and visualize module dependencies, detect circular imports, and identify coupling hotspots. Use when the user asks to analyze dependencies, find circular imports, or understand module relationships.

Files · 1

View on GitHub

SKILL.md

1	# Skill: Dependency Graph
2
3	Analyze module import relationships to detect circular dependencies, identify coupling hotspots, and visualize the dependency structure.
4
5	## Trigger
6	When the user asks to analyze dependencies, find circular imports, map module relationships, or reduce coupling.
7
8	## Prerequisites
9	- [ ] Source directory identified
10	- [ ] Language/module system known (ESM, CommonJS, Python imports)
11
12	## Steps
13
14	### Step 1: Scan Imports
15	- [ ] Parse all source files for import/require statements
16	- [ ] Build adjacency list: `module A → [module B, module C, ...]`
17	- [ ] Categorize imports:
18
19	\| Category \| Examples \|
20	\|----------\|---------\|
21	\| External \| `express`, `lodash`, `zod` \|
22	\| Internal package \| `@myorg/shared`, `@myorg/utils` \|
23	\| Relative \| `./service`, `../models/user` \|
24	\| Type-only \| `import type { X }` (TypeScript) \|
25
26	### Step 2: Detect Circular Dependencies
27	- [ ] Run DFS (depth-first search) on the dependency graph
28	- [ ] Report all cycles found with the full chain:
29	```
30	CIRCULAR: A → B → C → A
31	CIRCULAR: X → Y → X
32	```
33	- [ ] Classify severity:
34	- Runtime circular (actual `import`/`require`) — must fix
35	- Type-only circular (`import type`) — usually safe
36
37	### Step 3: Calculate Metrics
38
39	\| Metric \| Formula \| Healthy Threshold \|
40	\|--------\|---------\|-------------------\|
41	\| Fan-out \| Number of modules this module imports \| < 10 \|
42	\| Fan-in \| Number of modules that import this module \| High = shared utility \|
43	\| Instability \| Fan-out / (Fan-in + Fan-out) \| 0 = stable, 1 = unstable \|
44	\| Depth \| Longest import chain from entry point \| < 8 \|
45
46	### Step 4: Identify Hotspots
47	- [ ] God modules: Fan-in > 20 (too many things depend on it)
48	- [ ] Spaghetti modules: Fan-out > 15 (imports too many things)
49	- [ ] Unstable shared modules: High fan-in AND high instability
50	- [ ] Deep chains: Import depth > 8 levels
51
52	### Step 5: Generate Visualization
53
54	#### Mermaid Diagram
55	```mermaid
56	graph TD
57	A[controllers] --> B[services]
58	B --> C[models]
59	B --> D[utils]
60	C --> D
61	A --> E[middleware]
62	E --> D
63	style A fill:#4CAF50
64	style C fill:#FF9800
65	```
66
67	#### Text Summary
68	```
69	Module Dependency Report
70	========================
71	Total modules: 45
72	External dependencies: 23
73	Circular dependencies: 2
74	Max depth: 6
75
76	Top Fan-In (most imported):
77	1. src/utils/logger.ts (imported by 28 modules)
78	2. src/types/common.ts (imported by 22 modules)
79	3. src/config/index.ts (imported by 18 modules)
80
81	Top Fan-Out (most imports):
82	1. src/handlers/order/create/handler.ts (imports 12 modules)
83	2. src/services/order.service.ts (imports 10 modules)
84
85	Circular Dependencies:
86	⚠ src/services/user.ts → src/services/order.ts → src/services/user.ts
87	⚠ src/models/product.ts → src/utils/pricing.ts → src/models/product.ts
88	```
89
90	### Step 6: Suggest Improvements
91	- [ ] For circular deps: suggest dependency inversion, event-based communication, or extracting shared module
92	- [ ] For god modules: suggest splitting into focused modules
93	- [ ] For deep chains: suggest flattening with direct imports
94	- [ ] For high coupling: suggest introducing interfaces or facade patterns
95
96	### Step 7: Validate Boundaries
97	- [ ] Check that dependency direction follows architecture rules:
98	- Controllers → Services → Models (not reverse)
99	- No direct database access from controllers
100	- Shared types only from `common/` or `types/`
101
102	## Rules
103	- ALWAYS distinguish runtime imports from type-only imports
104	- ALWAYS report circular dependencies with full cycle path
105	- ALWAYS include actionable suggestions, not just problems
106	- Exclude `node_modules`, `dist`, `coverage`, and test files from analysis
107	- Group results by directory/module for readability
108	- Use Mermaid diagrams for visual output when helpful
109
110	## Completion
111	Dependency report with metrics, circular dependency detection, hotspot analysis, and improvement suggestions.
112
113	## If a Step Fails
114	- Too many modules (>200): Analyze at directory level first, drill into hotspots
115	- Dynamic imports: Flag `import()` calls as "dynamic — not fully trackable"
116	- Re-exports: Follow re-export chains to find actual source
117	- Monorepo: Analyze per-package first, then cross-package dependencies

People who liked this also viewed

6 picks

Type

dependency-graph

27stars3forks

View on GitHub

How to install dependency-graph?

girijashankarj/cursor-handbook/dependency-graph

$npx -y skills add girijashankarj/cursor-handbook --skill dependency-graph

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Skill: Dependency Graph
2
3	Analyze module import relationships to detect circular dependencies, identify coupling hotspots, and visualize the dependency structure.
4
5	## Trigger
6	When the user asks to analyze dependencies, find circular imports, map module relationships, or reduce coupling.
7
8	## Prerequisites
9	- [ ] Source directory identified
10	- [ ] Language/module system known (ESM, CommonJS, Python imports)
11
12	## Steps
13
14	### Step 1: Scan Imports
15	- [ ] Parse all source files for import/require statements
16	- [ ] Build adjacency list: `module A → [module B, module C, ...]`
17	- [ ] Categorize imports:
18
19	\| Category \| Examples \|
20	\|----------\|---------\|
21	\| External \| `express`, `lodash`, `zod` \|
22	\| Internal package \| `@myorg/shared`, `@myorg/utils` \|
23	\| Relative \| `./service`, `../models/user` \|
24	\| Type-only \| `import type { X }` (TypeScript) \|
25
26	### Step 2: Detect Circular Dependencies
27	- [ ] Run DFS (depth-first search) on the dependency graph
28	- [ ] Report all cycles found with the full chain:
29	```
30	CIRCULAR: A → B → C → A
31	CIRCULAR: X → Y → X
32	```
33	- [ ] Classify severity:
34	- Runtime circular (actual `import`/`require`) — must fix
35	- Type-only circular (`import type`) — usually safe
36
37	### Step 3: Calculate Metrics
38
39	\| Metric \| Formula \| Healthy Threshold \|
40	\|--------\|---------\|-------------------\|
41	\| Fan-out \| Number of modules this module imports \| < 10 \|
42	\| Fan-in \| Number of modules that import this module \| High = shared utility \|
43	\| Instability \| Fan-out / (Fan-in + Fan-out) \| 0 = stable, 1 = unstable \|
44	\| Depth \| Longest import chain from entry point \| < 8 \|
45
46	### Step 4: Identify Hotspots
47	- [ ] God modules: Fan-in > 20 (too many things depend on it)
48	- [ ] Spaghetti modules: Fan-out > 15 (imports too many things)
49	- [ ] Unstable shared modules: High fan-in AND high instability
50	- [ ] Deep chains: Import depth > 8 levels
51
52	### Step 5: Generate Visualization
53
54	#### Mermaid Diagram
55	```mermaid
56	graph TD
57	A[controllers] --> B[services]
58	B --> C[models]
59	B --> D[utils]
60	C --> D
61	A --> E[middleware]
62	E --> D
63	style A fill:#4CAF50
64	style C fill:#FF9800
65	```
66
67	#### Text Summary
68	```
69	Module Dependency Report
70	========================
71	Total modules: 45
72	External dependencies: 23
73	Circular dependencies: 2
74	Max depth: 6
75
76	Top Fan-In (most imported):
77	1. src/utils/logger.ts (imported by 28 modules)
78	2. src/types/common.ts (imported by 22 modules)
79	3. src/config/index.ts (imported by 18 modules)
80
81	Top Fan-Out (most imports):
82	1. src/handlers/order/create/handler.ts (imports 12 modules)
83	2. src/services/order.service.ts (imports 10 modules)
84
85	Circular Dependencies:
86	⚠ src/services/user.ts → src/services/order.ts → src/services/user.ts
87	⚠ src/models/product.ts → src/utils/pricing.ts → src/models/product.ts
88	```
89
90	### Step 6: Suggest Improvements
91	- [ ] For circular deps: suggest dependency inversion, event-based communication, or extracting shared module
92	- [ ] For god modules: suggest splitting into focused modules
93	- [ ] For deep chains: suggest flattening with direct imports
94	- [ ] For high coupling: suggest introducing interfaces or facade patterns
95
96	### Step 7: Validate Boundaries
97	- [ ] Check that dependency direction follows architecture rules:
98	- Controllers → Services → Models (not reverse)
99	- No direct database access from controllers
100	- Shared types only from `common/` or `types/`
101
102	## Rules
103	- ALWAYS distinguish runtime imports from type-only imports
104	- ALWAYS report circular dependencies with full cycle path
105	- ALWAYS include actionable suggestions, not just problems
106	- Exclude `node_modules`, `dist`, `coverage`, and test files from analysis
107	- Group results by directory/module for readability
108	- Use Mermaid diagrams for visual output when helpful
109
110	## Completion
111	Dependency report with metrics, circular dependency detection, hotspot analysis, and improvement suggestions.
112
113	## If a Step Fails
114	- Too many modules (>200): Analyze at directory level first, drill into hotspots
115	- Dynamic imports: Flag `import()` calls as "dynamic — not fully trackable"
116	- Re-exports: Follow re-export chains to find actual source
117	- Monorepo: Analyze per-package first, then cross-package dependencies

People who liked this also viewed

6 picks

Type