mirror of
https://github.com/Donchitos/Claude-Code-Game-Studios.git
synced 2026-10-16 01:37:05 +00:00
DonchitosandClaude Opus 5.5
be8993bbc5
Fix release for 1.1.2: the 14 longest skills keep their later phases after a compaction, a question nobody answered is never taken as an answer, settings read the same from a subfolder, the commit check works for a project in a subfolder of a larger repository, every skill opens with a title, and the shipped allow rules no longer approve deleting a branch or writing files without asking. Details in CHANGELOG.md; upgrade steps in UPGRADING.md (v1.1.2 → v1.1.3). Refs #83 Refs #133 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0185en4t76fPn7315q4c3nko
25 lines
990 B
Markdown
25 lines
990 B
Markdown
# /create-architecture — Phase 3: Data Flow
|
|
|
|
> Part of `/create-architecture`. `SKILL.md` names when to read this file; the settings it
|
|
> resolved and the rules under its later headings still apply here.
|
|
|
|
## Phase 3: Data Flow
|
|
|
|
Define how data moves between modules during key game scenarios. Cover at minimum:
|
|
|
|
1. **Frame update path**: Input → Core systems → State → Rendering
|
|
2. **Event/signal path**: How systems communicate without tight coupling
|
|
3. **Save/load path**: What state is serialised, which module owns serialisation
|
|
4. **Initialisation order**: Which modules must boot before others
|
|
|
|
Use ASCII sequence diagrams where helpful. For each data flow:
|
|
- Name the data being transferred
|
|
- Identify the producer and consumer
|
|
- State whether this is synchronous call, signal/event, or shared state
|
|
- Flag any data flows that cross thread boundaries
|
|
|
|
Get user approval on each scenario, then record it in
|
|
`production/session-state/active.md`; it is written at Phase 7.
|
|
|
|
---
|