phaser-analyze

Name: phaser-analyze
Author: Yakoub-ai

62installs0forks

How to install phaser-analyze?

yakoub-ai/phaser4-gamedev/phaser-analyze

$npx -y skills add Yakoub-ai/phaser4-gamedev --skill phaser-analyze

Installs into the current project.

Summary

This skill should be used when the user asks to "analyze my game", "review my Phaser project", "audit project health", "find bottlenecks", "refactor my game", "improve my code", "optimize my project", "what's wrong with my game", "code review Phaser", or "assess architecture".

Files · 1

View on GitHub

SKILL.md

1	# Phaser 4 Brownfield Project Analysis
2
3	Perform a comprehensive analysis of an existing Phaser 4 project to assess architecture quality, identify performance risks, flag API correctness issues, and produce a prioritized improvement roadmap.
4
5	## Analysis Process
6
7	Follow all five phases in order. Do not skip phases — each builds on the previous.
8
9	### Phase 1 — Discovery
10
11	Gather raw facts about the project before making any judgments.
12
13	- Read `package.json` for dependencies and Phaser version
14	- Glob for all `.ts`/`.js` files in `src/`
15	- Read `main.ts` for `GameConfig`
16	- Identify all scenes: `grep "extends Phaser.Scene"` across `src/`
17	- Map scene graph: `grep` for `this.scene.start`, `this.scene.launch`, `this.scene.stop`
18	- Identify all custom game objects: `grep "extends Phaser.Physics"` or `grep "extends Phaser.GameObjects"`
19	- Count total source files and lines of code
20
21	### Phase 2 — Architecture Assessment
22
23	Evaluate the structural quality of the codebase.
24
25	- Scene count and organization — Are scenes in `src/scenes/`? Are there too many or too few for the game's complexity?
26	- State management pattern — Registry vs globals vs module state. Search for `window.`, module-level `let`/`var` declarations.
27	- Asset loading strategy — Centralized `PreloaderScene` vs scattered `preload()` methods across scenes.
28	- Code organization — Does the project follow `scenes/`, `objects/`, `managers/` conventions?
29	- Cross-scene coupling analysis — Direct references vs event bus vs Registry. Search for `this.registry`, `this.events.emit`, `this.scene.get`.
30
31	Rate the architecture A through F based on findings:
32	- A — Clean separation, centralized loading, event-driven communication
33	- B — Minor organizational gaps, mostly well-structured
34	- C — Some coupling issues, mixed patterns, functional but messy
35	- D — Significant structural problems, globals, scattered loading
36	- F — No discernible architecture, everything in one file or deeply entangled
37
38	### Phase 3 — Performance Audit
39
40	Identify runtime performance risks.
41
42	- Object pooling: Search for `classType`/`maxSize` in group declarations. Flag physics groups created with `this.physics.add.group()` that lack `maxSize` — these leak objects.
43	- Particle emitter caps: Search for particle emitters missing `maxParticles`. Uncapped emitters can spike frame time.
44	- Static vs dynamic groups: Check if platforms, walls, and other immovable bodies use `staticGroup()` (correct) vs `group()` (wastes physics cycles).
45	- Update loop weight: Read each scene's `update()` method. Flag complex logic, object allocations (`new`), or heavy iteration inside `update()`.
46	- Texture atlas usage: Count individual `this.load.image()` calls vs `this.load.atlas()` calls. More than 15 individual image loads is a red flag — should be packed into atlases.
47	- Physics body count: Estimate total active physics bodies from group declarations and individual `this.physics.add.*` calls.
48
49	### Phase 4 — API Correctness
50
51	Check for deprecated, removed, or misused APIs.
52
53	- v3 API scan: Search for removed APIs — `Geom.Point`, `Math.PI2`, `Phaser.Structs`, `Camera3D`, `Layer3D`, `FacebookInstant`, `Create.GenerateTexture`, `TileSprite.setCrop`.
54	- TypeScript strictness: Grep for `as any`, `@ts-ignore`, untyped function parameters. These hide real bugs.
55	- Asset key consistency: Cross-reference `this.load.` keys with `this.add.`/`this.physics.add.*` keys. Mismatched keys cause silent texture-missing errors.
56	- Scene key registration: Verify all scene classes appear in the `GameConfig` scene array in `main.ts`.
57	- Physics body creation: Flag `this.add.sprite()` calls that should be `this.physics.add.sprite()` (sprites expected to have physics but created without a body).
58	- DynamicTexture/RenderTexture: Check for missing `.render()` calls after drawing operations.
59
60	### Phase 5 — Best Practice Check
61
62	Verify the project follows Phaser 4 best practices.
63
64	- Lifecycle discipline: `preload()` should only load assets, `create()` should only build the scene, `update()` should be lean (no asset loading, no object creation).
65	- Cleanup on shutdown: Scenes should clean up — look for `this.events.off`, `this.sound.stopAll()`, timer destruction, `this.events.on('shutdown', ...)`.
66	- Camera bounds: Camera bounds should match world or tilemap bounds. Search for `this.cameras.main.setBounds` and compare with world/map dimensions.
67	- Input keyboard null assertions: `this.input.keyboard` can be null in Phaser 4. Check for `this.input.keyboard!` or proper null guards.
68	- Physics debug flag: `debug: true` in physics config shoul

People who liked this also viewed

6 picks

Type

phaser-analyze

62installs0forks

View on GitHub

How to install phaser-analyze?

yakoub-ai/phaser4-gamedev/phaser-analyze

$npx -y skills add Yakoub-ai/phaser4-gamedev --skill phaser-analyze

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Phaser 4 Brownfield Project Analysis
2
3	Perform a comprehensive analysis of an existing Phaser 4 project to assess architecture quality, identify performance risks, flag API correctness issues, and produce a prioritized improvement roadmap.
4
5	## Analysis Process
6
7	Follow all five phases in order. Do not skip phases — each builds on the previous.
8
9	### Phase 1 — Discovery
10
11	Gather raw facts about the project before making any judgments.
12
13	- Read `package.json` for dependencies and Phaser version
14	- Glob for all `.ts`/`.js` files in `src/`
15	- Read `main.ts` for `GameConfig`
16	- Identify all scenes: `grep "extends Phaser.Scene"` across `src/`
17	- Map scene graph: `grep` for `this.scene.start`, `this.scene.launch`, `this.scene.stop`
18	- Identify all custom game objects: `grep "extends Phaser.Physics"` or `grep "extends Phaser.GameObjects"`
19	- Count total source files and lines of code
20
21	### Phase 2 — Architecture Assessment
22
23	Evaluate the structural quality of the codebase.
24
25	- Scene count and organization — Are scenes in `src/scenes/`? Are there too many or too few for the game's complexity?
26	- State management pattern — Registry vs globals vs module state. Search for `window.`, module-level `let`/`var` declarations.
27	- Asset loading strategy — Centralized `PreloaderScene` vs scattered `preload()` methods across scenes.
28	- Code organization — Does the project follow `scenes/`, `objects/`, `managers/` conventions?
29	- Cross-scene coupling analysis — Direct references vs event bus vs Registry. Search for `this.registry`, `this.events.emit`, `this.scene.get`.
30
31	Rate the architecture A through F based on findings:
32	- A — Clean separation, centralized loading, event-driven communication
33	- B — Minor organizational gaps, mostly well-structured
34	- C — Some coupling issues, mixed patterns, functional but messy
35	- D — Significant structural problems, globals, scattered loading
36	- F — No discernible architecture, everything in one file or deeply entangled
37
38	### Phase 3 — Performance Audit
39
40	Identify runtime performance risks.
41
42	- Object pooling: Search for `classType`/`maxSize` in group declarations. Flag physics groups created with `this.physics.add.group()` that lack `maxSize` — these leak objects.
43	- Particle emitter caps: Search for particle emitters missing `maxParticles`. Uncapped emitters can spike frame time.
44	- Static vs dynamic groups: Check if platforms, walls, and other immovable bodies use `staticGroup()` (correct) vs `group()` (wastes physics cycles).
45	- Update loop weight: Read each scene's `update()` method. Flag complex logic, object allocations (`new`), or heavy iteration inside `update()`.
46	- Texture atlas usage: Count individual `this.load.image()` calls vs `this.load.atlas()` calls. More than 15 individual image loads is a red flag — should be packed into atlases.
47	- Physics body count: Estimate total active physics bodies from group declarations and individual `this.physics.add.*` calls.
48
49	### Phase 4 — API Correctness
50
51	Check for deprecated, removed, or misused APIs.
52
53	- v3 API scan: Search for removed APIs — `Geom.Point`, `Math.PI2`, `Phaser.Structs`, `Camera3D`, `Layer3D`, `FacebookInstant`, `Create.GenerateTexture`, `TileSprite.setCrop`.
54	- TypeScript strictness: Grep for `as any`, `@ts-ignore`, untyped function parameters. These hide real bugs.
55	- Asset key consistency: Cross-reference `this.load.` keys with `this.add.`/`this.physics.add.*` keys. Mismatched keys cause silent texture-missing errors.
56	- Scene key registration: Verify all scene classes appear in the `GameConfig` scene array in `main.ts`.
57	- Physics body creation: Flag `this.add.sprite()` calls that should be `this.physics.add.sprite()` (sprites expected to have physics but created without a body).
58	- DynamicTexture/RenderTexture: Check for missing `.render()` calls after drawing operations.
59
60	### Phase 5 — Best Practice Check
61
62	Verify the project follows Phaser 4 best practices.
63
64	- Lifecycle discipline: `preload()` should only load assets, `create()` should only build the scene, `update()` should be lean (no asset loading, no object creation).
65	- Cleanup on shutdown: Scenes should clean up — look for `this.events.off`, `this.sound.stopAll()`, timer destruction, `this.events.on('shutdown', ...)`.
66	- Camera bounds: Camera bounds should match world or tilemap bounds. Search for `this.cameras.main.setBounds` and compare with world/map dimensions.
67	- Input keyboard null assertions: `this.input.keyboard` can be null in Phaser 4. Check for `this.input.keyboard!` or proper null guards.
68	- Physics debug flag: `debug: true` in physics config shoul

People who liked this also viewed

6 picks

Type