init repo

.opencode/skills/bevy-architecture/SKILL.md

@@ -0,0 +1,32 @@
+---
+name: bevy-architecture
+description: Review and improve Bevy project structure, plugin boundaries, and feature isolation
+license: MIT
+compatibility: opencode
+metadata:
+  stack: bevy
+  concern: architecture
+---
+
+## What I do
+
+- review plugin boundaries
+- spot ECS smells
+- suggest module split
+- suggest state/event/resource boundaries
+- keep project workshop-fast
+
+## Smells to flag
+
+- giant systems
+- state hidden in many places
+- UI mixed with gameplay
+- direct coupling across features
+- asset logic spread everywhere
+
+## Deliverable
+
+- top strengths
+- top risks
+- concrete refactor order
+- verify commands

.opencode/skills/bevy-debug/SKILL.md

@@ -0,0 +1,31 @@
+---
+name: bevy-debug
+description: Debug common Bevy runtime, ECS, asset, input, and scheduling problems
+license: MIT
+compatibility: opencode
+metadata:
+  stack: bevy
+  mode: debug
+---
+
+## What I do
+
+- narrow likely root causes
+- map symptom to file and system
+- suggest smallest probe first
+- suggest smallest safe fix
+- give exact verify commands
+
+## Use when
+
+- app opens but scene blank
+- movement or input broken
+- UI not updating
+- panic or borrow conflict appears
+- schedule/state confusion happens
+
+## Rules
+
+- quote exact compiler/runtime error if present
+- do not jump to big refactor first
+- check camera, assets, queries, states, and schedules

.opencode/skills/bevy-ecs/SKILL.md

@@ -0,0 +1,41 @@
+---
+name: bevy-ecs
+description: Design clean Bevy ECS layouts with components, resources, events, systems, and states
+license: MIT
+compatibility: opencode
+metadata:
+  stack: bevy
+  language: rust
+---
+
+## What I do
+
+- turn game idea into ECS parts
+- split data across components, resources, and events
+- propose system boundaries
+- suggest state flow
+- keep Bevy code idiomatic and small
+
+## When to use me
+
+Use when:
+- new mechanic starts
+- code feels like one giant system
+- feature needs plugin split
+- event vs resource choice unclear
+
+## Output shape
+
+1. goal
+2. ECS map
+3. file plan
+4. patch order
+5. verify commands
+
+## Rules
+
+- prefer Bevy built-ins before extra crates
+- keep `main.rs` thin
+- prefer events for loose coupling
+- prefer states for app flow
+- keep names specific

.opencode/skills/bevy-ui/SKILL.md

@@ -0,0 +1,23 @@
+---
+name: bevy-ui
+description: Build and debug Bevy UI flows for HUD, score, menus, and state-driven screens
+license: MIT
+compatibility: opencode
+metadata:
+  stack: bevy
+  area: ui
+---
+
+## What I do
+
+- propose HUD/menu structure
+- map UI state to resources/events/states
+- keep gameplay logic out of UI systems
+- suggest update flow for score and status text
+
+## Use when
+
+- adding score counter
+- adding pause/menu/game over screen
+- fixing stale UI text
+- separating HUD from gameplay